W3C home > Mailing lists > Public > public-prov-wg@w3.org > April 2013

Re: Review of prov-dc

From: Daniel Garijo <dgarijo@delicias.dia.fi.upm.es>
Date: Thu, 18 Apr 2013 18:52:29 +0200
Message-ID: <CAExK0Df_QzGV4aEiS=kOB0m=0Oz5CUvqZSTq8zz4_JO3-TzTbA@mail.gmail.com>
To: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>
Cc: "<public-prov-wg@w3.org>" <public-prov-wg@w3.org>
Hi Stian,


2013/4/18 Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>

>
> On Thu, Apr 18, 2013 at 2:28 AM, Daniel Garijo <
> dgarijo@delicias.dia.fi.upm.es> wrote:
> > Thanks Stian for your review.
> > I have addressed most of the changes and answered your comments here:
> > http://www.w3.org/2011/prov/wiki/Stian_Soiland-Reyes
> > The document has now changes a lot since the last WD, so it would be
> great
> > if you could have a quick look before the next telecon.
> > Link:
> >
> https://dvcs.w3.org/hg/prov/raw-file/tip/dc-note/releases/NOTE-prov-dc-20130430/Overview.html#dct-rightsHolder
>
> Thanks for revising (!) the document. The figures looks really nice now,
> specially on a high-density screen.
>
> As a quick summary of my response (due to the meeting starting in 3
> minutes) : The suggested changes look good, and I have no blockers. Some
> little tweaks in the new material is suggested below.
>
>
>
> Apologies to the formatting of this email, it is a bit difficult to
> respond to a wiki page...
>
> 1) Outdated citations:
> > [DCTERMS] Dublin Core Terms Vocabulary. 8 December 2010. URL: http://dublincore.org/documents/dcmi-terms/
> Should be:
> > Dublin Core Terms Vocabulary. 14 June 2012. URL: http://dublincore.org/documents/2012/06/14/dcmi-terms/
>
> > I'm not sure about this change, since Thomas Baker (CIO of DCMI)
> proposed to use the current one.
>
> In Baker's review, it was the title of the document that was corrected:
>
>      Currently reads:
>
>         [DCTERMS]
>             Dublin Core Terms Vocabulary. 8 December 2010. URL:
> http://dublincore.org/documents/dcmi-terms/
>
>      Should read:
>         [DCTERMS]
>             DCMI Metadata Terms. 8 December 2010. URL:
> http://dublincore.org/documents/dcmi-terms/
>
> but I don't think he checked the dates, because if you follow the link you
> get the http://dublincore.org/documents/2012/06/14/dcmi-terms/ version,
> not the http://dublincore.org/documents/2010/10/11/dcmi-terms/ version
> (note, October, not December).
>
> I think we should use the version IRI here, so that future readers are not
> confused by the missing mapping of any DCMI terms that are added/modified
> in a later version.
>
> Thus:
>    [DCTERMS] DCMI Metadata Terms. 14 June 2012. URL:
> http://dublincore.org/documents/2012/06/14/dcmi-terms/
>
Added

>
> > Unfortunately I can't put text in italics in the figures, it would
> require me to redo them again. I think that this suggestion is not really
> necessary since with capital letter reads fine. I have looked other
> documents and they don't even introduce the class.
>
> It's not ideal, but as the classnames (except prov:Publish) should all be
> fairly well known I'll let it pass. ;-)
>
:)

>
> > Added table with the mappings. Added rationale for those not mapped.
>
> Very good. Some small typos in the new table:
>
> intelectual -> intellectual
>
It had been already fixed :). Note that now I have separated the mapping in
classes and properties to improve readability.

>
> > As we discussed in last week's telecon, dct:references is a subproperty
> of wasDerivedFrom. It might seem a bit strong, but after all the resource
> referencing the pre existing resource wouldn't have been the same if the
> preexisting resource didn't exist. No changes done.
>
> Just to confirm that I don't agree with this mapping (and would almost
> never use prov:wasDerivedFrom in such fashion), but I won't be blocking on
> this.
>
I know. We had a discussion about this in the WG with Simon and Paul. It
seems that if you look to the document strictly as an entity, any of the
references appearing on it determine its current state (they had to exist
for the document to be what it is). People normally use derivation to state
that a work was based on another, but maybe they can do so by specializing
derivation in a more restrictive way. At this stage I agree in that we
shouldn't reopen the issue.

>
>
> > I don't agee here. If you "publish" the entity you submit the text via
> a form, etc. to the wordpress platform to publish. That text would be the
> "usedEntity". The same thing applies for issued. You can contribute to
> create an entity that has not existed, but in order to make public some
> content (publish), you need some pre- existing content. Otherwise it
> wouldn't be a "publish" activity, but a "creation" activity...
>
> OK, I can buy into this.
>
> 30) dct:dateCopyrighted should NOT have a used_entity
>
> > I think that this is similar to my previous argument. You create a
> resource and then you copyright it. They are different activities. The
> input of the copyrightable activity could be the text you want to copyright.
>
> No, those are not distinct activities. You gain copyright simply by
> creating something of intellectual value. If I write here now a horrible
> haiku:
>
>   Daniel is great
>   He creates and fix and sing
>   To everyone's joy
>
> then I instantly gain copyright on that. There's no specific activity
> involved with gaining copyright - it's a right!
>
> http://en.wikipedia.org/wiki/Copyright#Obtaining_and_enforcing_copyright
>
> Due to time constraints, I won't block on this, but I think the current
> model with a prov:Copyright activity assumes too much about the legal
> processes. (As described in the article above, it is common in some
> countries (US) to REGISTER copyright - which certainly is an activity; but
> this is independend from (and after) actually gaining copyright.
>

>
> In all countries where the Berne Convention<http://en.wikipedia.org/wiki/Berne_Convention_for_the_Protection_of_Literary_and_Artistic_Works> standards
>> apply, copyright is automatic, and need not be obtained through official
>> registration with any government office. Once an idea has been reduced to
>> tangible form, for example by securing it in a fixed medium (such as a
>> drawing, sheet music, photograph, a videotape, or a computer file), the
>> copyright holder is entitled to enforce his or her exclusive rights.
>
>
> Hmm, ok, I didn't see it that way. I'll remove the _usedEntity in the
copyright complex mapping.

> I don't agree. If I have a catalog of books/products, etc. and I replace
> item 4 in the catalog (a travel guide of Madrid) with item 45 (a travel
> guide of paris), then they are not alternates of each other. However the
> specialized entities in the catalog MadridGuideAsItem4 and
> ParisGuideAsItem4 would be alternates of each other (and one is derived
> from the other). I'll add it in the complex mapping.
>
> OK, I think I understand your rationale for dct:replaces now. It is the
> "book as X" that is replaced by "anotherbook as X" - you consider it to be
> replaced in a certain context/role/collection.
>
> I think it becomes more clear if we flip the sentence around:
>
> There is a relation between two resources when the former replaces or
>> displaces the latter. However, we can't always assume the replacement is
>> derived from the former resource, because the replacement could have
>> existed and been generated independently from the original (for instance if
>> a "Introduction to provenance" book replaces the "Provenance in a nutshell"
>> book in a catalog). Therefore the "replace" Activity uses a specialization
>> of the replaced entity (_:oldEntity) and generated a specialization of
>> the replacement (_:newEntity). These specializations model the aspect of
>> the resource which is the subject of replacement, thus, _:newEntity was
>> derived from _:oldEntity.
>
>
> Fixed.
Thanks,
Daniel
Latest doc:
https://dvcs.w3.org/hg/prov/raw-file/default/dc-note/releases/NOTE-prov-dc-20130430/Overview.html#dct-replaces

>
>
> --
> Stian Soiland-Reyes, myGrid team
> School of Computer Science
> The University of Manchester
>
Received on Thursday, 18 April 2013 16:52:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:51:35 UTC