- From: Daniel Garijo <dgarijo@delicias.dia.fi.upm.es>
- Date: Sun, 14 Apr 2013 23:26:16 +0200
- To: Thomas Baker <tom@tombaker.org>
- Cc: DC-PROVENANCE@jiscmail.ac.uk, "<public-prov-wg@w3.org>" <public-prov-wg@w3.org>, Kai Eckert <kai@informatik.uni-mannheim.de>
- Message-ID: <CAExK0Dc9-CNaHOKi_JYdY6sAd_pXyWVPx0huqsdRT8RNWQ1jqA@mail.gmail.com>
Hi Tom, did you manage to see our response? Are you ok with the changes? Thanks, Daniel 2013/4/9 Daniel Garijo <dgarijov@gmail.com> > 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 Sunday, 14 April 2013 21:26:44 UTC