- From: Provenance Working Group Issue Tracker <sysbot+tracker@w3.org>
- Date: Wed, 28 Nov 2012 12:03:43 +0000
- To: public-prov-wg@w3.org
PROV-ISSUE-607 (dc-smiles-review): Review of the Dublin Core mapping document [Mapping PROV-O to Dublin Core]
http://www.w3.org/2011/prov/track/issues/607
Raised by: Simon Miles
On product: Mapping PROV-O to Dublin Core
Please find comments on the current draft below. I hope they are helpful.
General
=======
- The document is dated 28 October 2012.
- I think the document would benefit from being clearer how you apply the information contained in it. That is, I'd argue it should be clearly a methodological document from the start, explaining to the reader how to map their data. At the moment, the document discusses and presents information, but without a context of how and when the reader should take it into account. If an overall methodology was articulated at the start of the document, the reader could better understand the mapping and discussion in that context.
Abstract
========
- "prov" should be "PROV" in the final line.
- "here here" in the final line.
- I don't think readers will know what "direct mappings" or "prov refinements" mean by this point in the document.
Status of This Document
=======================
- Missing space before [DCTERMS] citation.
1. Introduction
===============
- Paragraph 1: "The Dublin Core Metadata Initiative provides a core metadata vocabulary..." - A vocabulary about what? The first two paragraphs provide lots of minor details about DC, but don't give context explaining what it is for, which seems inconsistent.
- Paragraph 4: "A classification... is provided in Table 1. This classification is... conservative" - I think we should say what the classification is before talking about its characteristics, otherwise the reader can get lost. What is the classification for?
- Paragraph 4: "can be considered as provenance related" - Delete "as".
- Why do the categories in the text not follow the order of the categories in the table? This makes it harder to follow. Similarly, it would be good to have a headed paragraph on the first category, Descriptive, so that it is clear you are explaining the table contents.
- I don't think the purpose of the paragraphs on the categories ("Dates and Time terms" etc.) is clear. It seems to be a discussion about provenance, but without much context beforehand. This should be clarified.
- The paragraph about each category talks about just a few of the terms in the category, and it is not clear why. Could we be more rigorous and talk about every term one by one?
- "Dates and Time terms" - should be "Date and Time terms"
- Why is "terms" in lowercase for "Dates and Time" but capitalised for the other categories, "Terms"?
- "Dates typically belong to the provenance record of a resource." - As opposed to belonging to what? Not clear what you are trying to convey.
- "the publication can be seen as an action" - Delete "the".
- In Agency Terms, the sentence starting "All properties that have..." is not grammatically meaningful. Maybe you need to delete "that"?
- In Derivation Terms, put "and" before the "dct:source" in the list of derivations.
- "dct:references is a weaker relation" - Why? Surely it is a form of derivation like the others? If A references B, then part of A's content (the reference) is specifically determined by B. I don't understand how it could be weaker than derivation.
- Paragraph under Table 1: "Despite being relevant for provenance..." - This is confusing, as you are currently talking about provenance. I assume you need to distinguish between dct:provenance and applicability for mapping to PROV.
- What is the conclusion of the discussive paragraph about dct:provenance?
- Paragraph under Example 1: "ex:doc2 which had probably" - Should be "which probably had"
1.1 Namespaces
==============
- Shouldn't this table come before the introduction text, as that uses dct: plenty of times.
- Where is it explained what the ex: namespace is?
2.1 Basic considerations
========================
- Point 1): "can be expressed in form" - Missing "the".
2.2 What is ex:doc1? Entities in Dublin Core
============================================
- Paragraph 1: "As a dc metadata record describes the resulting document as a whole." - Resulting from what?
- "According to the PROV ontology, the activity of issuing a document involves two different states of the document" - I don't think PROV-O says this or requires it. It is more that, if you want to use PROV to model an acitivity affecting a document or any other thing, then this is most naturally done using one entity for the state before and one entity for the state after being affected.
- "Each of these states corresponds to a different specialization of the document" - Be clear that this is "specialization" in the PROV sense. Maybe there should be a font style used to show when PROV vocabulary is being used in the text?
- Paragraph 2: "somehow find some activity and agent" - Delete (or explain) "somehow". What activity? I don't think it is necessarily clear to the reader.
- I think Figure 1 needs more explanation. What does it show and why?
- I think you need to explain what the bold arrow towards the top of the figures mean.
- It seems confusing to use the same notation in the figures for both RDF resources and PROV entities. The top of Figure 1 seems to show ex:publisher to be an entity, but that isn't shown in the mapped PROV (and probably shouldn't be).
2.3 Direct mappings
===================
- Paragraph 1: "The direct mappings provide basic interoperability" - Interoperability of what? Basic in what way?
- "By means of OWL 2 RL reasoning, any PROV application can at least make some sense from Dublin Core data." - This seems too vague to mean much. What are you specifically trying to convey?
- Paragraph under Table 3: "a metadata record such as example 1 will infer that" - A record cannot infer.
- I still find the prov:wasRevisionOf-dct:isVersionOf mapping strange, even though it may well be correct. This is not necessarily for the mapping document itself, but I'd be interested to see an example of an assertion that was expressible in dct:isVersionOf but not in prov:wasRevisionOf.
- The column headings in Table 5 are wrong (PROV Term and DC Term need to be switched).
2.4 PROV refinements
====================
- Why is "Activity" or "Role" part of the names? Why not just "prov:Creation" or "prov:Modification"? This does not seem consistent with the other documents.
- Is it correct that the namespace of these new terms is prov: and not a separate namespace for the mapping? I assume it is correct, but just checking.
- The final paragraph uses "should" a couple of times. It is unclear who this obligates, and might be read as an instruction to the reader/implementer, as this is how "should" is used in the other PROV documents.
2.5 Complex Mappings
====================
- Paragraph 1: "consist on a set" - Should be "consist of a set"
- Figure 4: We need to say, in the figure caption and possibly the accompanying text, which activity is before which other activity (as this is the key point of the conflation).
B.2 Informative references
==========================
- The dates for PROV-CONSTRAINTS, PROV-DM and PROV-O are not correct for the forthcoming release.
Received on Wednesday, 28 November 2012 12:03:45 UTC