Re: prov-xml review for release as a FPWD

Hi prov-xml team,


To me the document is ready to be published as a first public working draft.

I would like the following issues, as minimum flagged in the document or
addressed by the time we release the FPWD (Some may already be in the 
tracker).


1. It is unclear to me what the type of prov:id should be.
   The schema indicates QName.
   prov-dm/prov-n allow for entity(ex:001)
   where ex:001 is not a QName.
   Instead prov-n defines the type prov:QualifiedName.
   Should we encode it in the schema?

2.  Do we keep an xsd:choice for PROV attributes,  or do we go for 
xsd:sequence.

     For those mapping the xml schema to other technologies SQL/Java, I
     think the latter is easier, and potentially leads to easier
     queries.

     What is the benefit of choice?

3. In Prov-dm, prov:values are typed. The PROV-XML document does not 
show how they
    should be encoded.  We should use xsi:type

   e.g. <prov:value xsi:type="xsd:int">4</prov:value>


4. PROV-DM uses Qualified Names but is very clear that these QUalified
Names can be mapped to URIs by concatenating namespace and local name.
That's common practice in RDF land, it is not in XML-land. So we need
to make this convention explicit in the document.

   To check: the document has lots of idnetifier without prefix (nor
   default namespace), and therefore, they don't give a valid url.



----------------------------------------------------------------------

Minor comments:

1. Introduction: needs trimming


2. Table 1 (mapping of types and relations to XML)
    I would add an extra column, showing the element name,
    in particular for names such as prov:wasGeneratedBy

3. Same table, and across doucment <prov:type>prov:Revision</prov:type>
    is understood by a parser as

<prov:type xsi:type"xsd:string">prov:Revision</prov:type>
    when really we want
<prov:type xsi:type"xsd:QName">prov:Revision</prov:type>
    or
<prov:type xsi:type"prov:QualifiedName">prov:Revision</prov:type>


4. intro of section 2.1 nees updating to the correct relations.

5. Can we remove across the document the declaration of xs prefix, and
have it predefined in a table in section 1?

6. Can we check that namespaces+local name give a uri.
    For instance, the examples with bbc prefix should lead to a valid 
uri pointing to page on bbc web site.
    There is a missing / at the end of some namespaces for bbc.


7. What is normative? in particular, when we have repeat of definitions.


On 06/11/2012 01:57, Stephan Zednik wrote:
> Thanks Paul.
>
> --Stephan
>
> On Nov 5, 2012, at 7:52 PM, Paul Groth <pgroth@gmail.com 
> <mailto:pgroth@gmail.com>> wrote:
>
>> Hello,
>>
>> I have reviewed prov-xml ( 
>> http://dvcs.w3.org/hg/prov/raw-file/default/xml/prov-xml.html_
>>
>> The document can be released as a first public working draft. Here 
>> are my detailed comments below many of which I now realize echo some 
>> of James' comments. The key issues being: leveraging xsd schema and 
>> explaining design decisions.
>>
>> Regards
>> Paul
>>
>> ---Detailed Comments--
>>
>> ==Abstract==
>>
>> The abstract could be shorter. Suggested revision:
>>
>> Provenance is information about entities, activities, and people 
>> involved in producing a piece of data or thing, which can be used to 
>> form assessments about its quality, reliability or trustworthiness. 
>> PROV-DM is the conceptual data model that forms a basis for the W3C 
>> provenance (PROV) family of specifications. It defines a concepts for 
>> expressing provenance information enabling interchange. This document 
>> introduces an XML schema for the PROV data model (PROV-DM), allowing 
>> instances of the PROV data model to be serialized in XML.
>>
>> ==Introduction==
>> I like the focused nature of the document, not lots of justification 
>> around design choices, etc.. However, this should be clearly stated 
>> in the introduction. I would add a sentence something like: "This 
>> specification goal is to provide a succinct definition of the XML 
>> form of PROV-DM, thus, we refer the reader to the PROV-DM to provide 
>> overall justification and context to the definitions presented here."
>>
>> Also, I would link out to each of the concepts in the DM when they 
>> are presented within the document.
>>
>> ==2.1.1 Entity==
>> In the example you have ex:version which I think may be confusing 
>> because we have revision in PROV.
>>
>> ==Use of prov:type for terms within the dataset==
>>
>> For all subtypes defined in prov the spec defines that one should use 
>> the prov:type construct. e.g. <prov:wasDerivedFrom> 
>> <prov:type>prov:Revision</prov:type></prov:wasDerivedFrom>. I was 
>> wondering what the rationale for that choice is. Why doesn't one see 
>> <prov:wasRevisionOf>?
>>
>> Clearly this is a pattern used throughout the document. I think this 
>> pattern deserves a small paragraph explaining why the approach was 
>> taken. This is especially true as XML Schema supports the definition 
>> of subtypes through xsd:extension
>>
>> ==Other Patterns==
>> I think there are a couple of other patterns used within the schema 
>> design. Maybe adding a section on those patterns would help the 
>> reader more easily understand the approach. The patterns I see are:
>> 1) use xml ids and refs to express the provenance graph (2) in type 
>> definitions required provenance elements are presented first, then 
>> optional provenance elements, then application specific elements
>> 3) prov:attributes are interpreted as extra non-provenance elements 
>> within complex types (e.g. <xs:any namespace="##other"/>). I assume 
>> this is why specialization and alternate do not have extensibility 
>> points.
>> 4) can you define the "salami slice XSD design pattern" in the text?
>>
>> ==prov:id==
>> I was a bit confused by prov:id. Can you give some examples of what 
>> can go in prov:id? It's defined as a QName so I can't put a full url 
>> in? Your example of prov:id (prov:id="tr:WD-prov-dm-20111215) uses 
>> tr: which is not defined in the namespace. Is this just a mistake? It 
>> would be good to see an an example linking out beyond the scope of 
>> one document.
>>
>>
>>
>>
>>
>>
>>
>>

-- 
Professor Luc Moreau
Electronics and Computer Science   tel:   +44 23 8059 4487
University of Southampton          fax:   +44 23 8059 2865
Southampton SO17 1BJ               email: l.moreau@ecs.soton.ac.uk
United Kingdom                     http://www.ecs.soton.ac.uk/~lavm