Fwd: Comments on "Dublin Core to PROV Mapping" - part 1 of 2

Dear Thomas.
I have just pushed the edits from your reviews (both parts). You can find a
detailed response here:
http://www.w3.org/2011/prov/wiki/Tom_Baker
The version with your edits:
https://dvcs.w3.org/hg/prov/raw-file/51a664e72cf6/dc-note/releases/NOTE-prov-dc-20130430/Overview.html

Thank you very much for your detailed review.
Please let me know if you have any further suggestion.
Best,
Daniel


2013/4/1 Daniel Garijo <dgarijov@gmail.com>

> Thanks for your detailed review, Tom!
> I'll create an issue and a detailed response in the next days.
>
> Best,
> Daniel
>
>
>
> 2013/3/30 Thomas Baker <tom@tombaker.org>
>
>> Daniel, Kai, other contributors,
>>
>> Attached is my review of "Dublin Core to PROV Mapping: W3C Working Draft
>> 12
>> March 2013" [1].  Bravo to the editors and contributors for a complex and
>> solid
>> piece of work!
>>
>> My comments are divided into two postings.  This posting addresses:
>>
>> 1. Status of the Turtle representations and the subclasses they declare
>> 2. Various points of substance
>> 3. Minor editorial points
>>
>> The next posting will continue with:
>>
>> 4. Issues in the Introduction re: Dublin Core and "DC Terms"
>>
>> I reviewed the Mapping primarily from the standpoint of Dublin Core.
>> Though I
>> am currently the CIO of DCMI, my review has not gone through DCMI process
>> so
>> should be considered my opinion.  I have also reviewed aspects of the
>> Mapping
>> from the standpoint of one who has been involved in various contexts with
>> W3C
>> process (e.g., Point 1 below).
>>
>> What I am not qualified to comment on in much detail are aspects related
>> to the
>> PROV model, which I have not studied in detail.  There were one or two
>> places,
>> flagged below, where I thought that deeper knowledge of the model was
>> really
>> necessary for understanding particular points.  However, it speaks well
>> for the
>> authors that I felt I could follow it without extensive knowledge of
>> PROV.  I
>> like it when the authors suggest that the Mapping could facilitate PROV
>> adoption by allowing users to use Dublin Core statements as a starting
>> point
>> for generating more complex PROV representations -- a very good idea and
>> one
>> that could inform a very instructive tutorial or primer.
>>
>> Tom
>>
>> [1] http://www.w3.org/TR/2013/WD-prov-dc-20130312/
>>
>> ======================================================================
>> 1. Status of the Turtle representations and the subclasses they declare
>>
>>    The Turtle representations of the mappings are buried in anchors to
>>    the hyperlink "here" in the Abstract but are not further mentioned.
>>    Generally speaking, the use of "here" as a hyperlink is not ideal in
>>    specifications such as this, which many people may read in the form
>>    of a printout, or offline, perhaps in Instapaper on an iPad.
>>
>>    I suggest:
>>    --  Create entries for the Turtle representations in the References
>>        section [3], then cite them in the specification.
>>
>>    --  Discuss the Turtle representations somewhere in the specification
>>        besides just the Abstract, and add some explanation clarifying
>> their
>>        status.  Do they fall under a W3C namespace policy?  Are they
>> linked to
>>        WD-prov-dc such that any future revisions in the Turtle
>> representations
>>        could only be undertaken in the context of a revision of
>> WD-prov-dc?
>>        Are they provided merely as a convenience for readers, or do the
>> editors
>>        intend them to be used (and how)?  I do not think a long text is
>>        required, but it would be good to clarify for the reader what
>> these are
>>        and how they fit into W3C publication and maintenace processes,
>> and to
>>        make their URIs visible in References.
>>
>>     -- In Section 3.2, I am puzzled about the status of "subclasses" such
>> as
>>        prov:Publish.  I see that these subclass declarations in Turtle are
>>        mirrored in [2], but I see no referece to prov:Publish in PROV-O.
>>        It is unclear, in other words, whether:
>>
>>             To properly reflect the meaning of the Dublin Core terms,
>> more specific
>>             subclasses are needed:
>>
>>        means
>>
>>             more specific subclasses would be needed (but haven't been
>> created)
>>
>>        or
>>
>>             more specific subclasses have been created
>>
>>         If the latter, then the text would need to point to PROV-O.  If
>> the
>>         former, then it would be doubly important to clarify the status
>> of the
>>         Turtle representations. Does [2] intend to encourage people to use
>>         prov:Publish in their data?
>>
>>     [1] http://www.w3.org/ns/prov-dc-directmappings.ttl
>>     [2] http://www.w3.org/ns/prov-dc-refinements.ttl
>>     [3]
>> http://www.w3.org/TR/2013/WD-prov-dc-20130312/#informative-references
>>
>> ----------------------------------------------------------------------
>> 2. Various points of substance
>>
>> --  1.1 Namespaces (and the term "namespace")
>>
>>     The term "namespace" is used a bit loosely here.  It is worth noting
>> that
>>     the current draft RDF 1.1 Concepts and Abstract Syntax spec, while
>> still
>>     just a Working Draft, concludes that [1]:
>>
>>         The term "namespace" on its own does not have a well-defined
>> meaning in
>>         the context of RDF, but is sometimes informally used to mean
>> "namespace
>>         IRI" or "RDF vocabulary".
>>
>>     I suggest changing the name of the section and tweaking a few things:
>>
>>         1.1 Namespace URIs
>>
>>         The namespace URIs used in this document can be seen in Table 2.
>>
>>         Table 2: Namespace URIs used in the document
>>
>>         prefix   Namespace IRI                           Used for
>>         owl      <http://www.w3.org/2002/07/owl#>        The OWL
>> vocabulary [OWL2-OVERVIEW].
>>         rdfs     <http://www.w3.org/2000/01/rdf-schema#> The RDFS
>> vocabulary [RDFS].
>>         prov     <http://www.w3.org/ns/prov#>            The PROV
>> vocabulary [PROV-DM].
>>         dct      <http://purl.org/dc/terms/>             The DCMI
>> /terms/ vocabulary [DCTERMS].
>>         ex       <http://example.org>
>>  Application-dependent URIs. Used in examples.
>>
>>     [1]
>> https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-concepts/index.html#vocabularies
>>
>> --  3.3.2
>>     The sentence:
>>
>>         It is important to note that since the range for dates in Dublin
>> Core is a
>>         rdfs:Literal and xsd:dateTime for the prov:atTime property, the
>> mapping is
>>         only valid for those literals that are xsd:dateTime.
>>
>>     is not very precise.  Perhaps you mean something like:
>>
>>         It is important to note that since the range for DC date
>> properties is
>>         rdfs:Literal, and the range of the prov:atTime property is the
>> class
>>         of literals with the datatype xsd:dateTime, the mapping is only
>> valid
>>         for those literals that have (or could be assigned?) the datatype
>>         xsd:dateTime.
>>
>>     ...assuming that "range... is the class of literals with the datatype
>>     xsd:dateTime" is a correct interpretation (I haven't checked the other
>>     specs).
>>
>> --  3.3.3
>>     The sentence:
>>
>>         In Dublin Core, most of the properties relating entities to other
>> entities
>>         don't describe the involvement of a specific activity (e.g.,
>> dct:format,
>>         dct:source or isVersionOf).
>>
>>     is awkwardly worded.  Do you perhaps mean:
>>
>>         In Dublin Core, most of the properties relating entities to other
>> entities
>>         do not imply activities related to provenance (e.g., dct:format,
>>         dct:source or isVersionOf).
>>
>> --  3.3.3.1
>>     I found the following sentence hard to understand:
>>
>>         The replacement is the result of a "search and replace" Activity,
>> which
>>         used a specialization of the replaced entity (_:old_entity) and
>> produced a
>>         specialization of the replacement (_:new_entity).
>>
>>     ...but I do not know the PROV model well enough to propose a clearer
>>     text.
>>
>> --  3.4 Cleanup
>>
>>     I wonder if "cleanup" is the best heading for this section.  After
>> using
>>     SPARQL, as described in the previous sections, one ends up with a PROV
>>     graph that has blank nodes for entities, and the process of assigning
>>     identifiers to those blank nodes could be thought of as "cleanup".
>>  So far,
>>     so good.
>>
>>     What the "suggestions" then discuss, however, are not methods for
>> cleaning
>>     up an existing generated graph, but different templates for generating
>>     _new_ and _different_ PROV graphs from the same DC statements.  As I
>> read
>>     it, this section has more to do with different possible ways to
>> generate
>>     graphs, starting with somewhat different assumptions (related to
>> different
>>     possible ways to model things using PROV), and resulting in different
>>     patterns.  If my reading is correct, then I would suggest saying this
>> more
>>     clearly in the introduction to the section and giving the section a
>> more
>>     specific name, such as "Generating PROV graphs using different
>> templates".
>>
>> --  Table 6 - dct:references
>>
>>     For most properties, the commentary says they have been "excluded"
>>     or "left out" of the mapping.  For dct:references, however, the text
>> says
>>     that dct:references "has been dropped from the mapping".  This wording
>>     makes it sound like there was an earlier, published mapping from which
>>     this was dropped -- more like a change note for a specification than
>> part
>>     of the specification itself.  I suggest using "excluded" or "left
>> out".
>>
>> --   Reference in "Reference" section
>>      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/
>>
>> --  In the sentence:
>>
>>         For example, when mapping dates only unqualified properties can
>> be extracted,
>>
>>     I was unsure what you mean by "unqualified".
>>
>> ======================================================================
>> 3. Minor editorial points
>>
>> --  s/don't/do not/ (3.3.3), also search/replace "couldn't", "doesn't",
>> and other contractions
>>
>> --  "cleanup" and "clean-up" are used inconsistently
>>
>> --  s/refering/referring/
>>
>> --  2.1 Provenance in Dublin Core: Section "Descriptive Terms": replace
>> ", etc."
>>     with a full stop because the sentence already starts with "Some
>> examples".
>>
>> --  3.3.  Change "We divide the queries in different categories" => "into
>> different
>>     categories".
>>
>> --
>> Tom Baker <tom@tombaker.org>
>>
>> ########################################################################
>>
>> To unsubscribe from the DC-PROVENANCE list, click the following link:
>> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=DC-PROVENANCE&A=1
>>
>
>

Received on Tuesday, 9 April 2013 16:59:34 UTC