Re: prov-links review

HI Luc

shortly: no blockers for release as FPWD

the issue below on completeness of RDF patterns is indeed general and not specific to this document, so it's fine not to address it.

regarding my comments on Ex.2 :  rendering attributes are relevant to display provenance, as they are relevant to display anything 
else -- my point is that the new attributes chosen in the example to justify the creation of the new bundle are not specifically 
provenance attributes and as such they may not be the most convincing. So Ex. 2 is a bit awkward for me, but certainly not a blocker.

--Paolo


On 27/11/2012 12:07, Luc Moreau wrote:
> HI Paolo,
>
> I am filing this under ISSUE-604.
>
> Response below.
>
> On 11/27/2012 12:02 AM, Paolo Missier wrote:
>> Hi,
>>
>> below are some notes for the prov-links ("mentionOf") note: http://dvcs.w3.org/hg/prov/raw-file/default/links/prov-links.html
>> (apologies for the verbosity)
>>
>> I haven't followed the threads on this for a while so I am reading with a rather fresh eye. Overall this reads well.
>>
>> - From the abstract in the very first paragraph, one gets an expectation that the document is about bundles and how they are used 
>> to express provenance of provenance, as this is how bundles are introduced. The second paragraph clarifies that it is about a 
>> relation.
>> I suggest:
>>  - to clarify that in this document bundles are instrumental to the definition of mentionOf (as the document doesn't really 
>> elaborate on the prov of prov idea)
>>  - to name the relation as mentionOf right away in the abstract.
>>  - to make a reference to bundle in PROV-DM, where they are defined; http://www.w3.org/TR/prov-dm/#component4
>
> Done
>>
>> sec 2: the fact that e2 belongs to the bundle appears to be the single distinguishing aspect of e2 that justifies it being a 
>> specialization of e1. Later it becomes clear that it is "one of" the new aspects of it.
>>   I suggest
>> -  to clarify upfront, i.e.
>> and which presents an additional aspect:- > and which presents at least an additional aspect:
>> - in ex. 1, where it says " The tool adds a domain-specific performance attribute to each of these specialized entities as 
>> follows:",
>>    to note that pref:rating is an example of an additional attribute of the specialized agent Bob-2011....
>
> Done
>>
>> a couple of places where explanations are a bit too quick:
>> - sec 2: "Thus, the mentionOf relation cannot be inferred from knowing that e2 is a specialization of e1 that appears in bundle 
>> b."  I think this deserves a separate space, to clarify that there are specializations amongst entities that exist in different 
>> bundles, which are not Mentions. What's a good example?
>>       Minimally, "thus" is odd here, i don't see any logical consequence.
>
> Rewrote paragraph.
>>
>> - "A mention is not, as defined here, an influence, and therefore does not have an id and attributes."
>>   ref to influence? http://www.w3.org/TR/prov-dm/#term-influence
>>   This statement calls for an example of a mention that is not an influence. But if the whole point is to say that mentionOf has 
>> got no ids and attributes, why not just say that. I guess it wouldn't follow logically anyways from it not being an influence?
>
> This was discussed at length last week, this sentence appears in prov-dm for non-influence terms.
>>
>>
>> Ex. 1:
>> I found myself wondering whether or not an entity can be mentionOf multiple other entities. This is clarified only later as a 
>> constraint (5). Perhaps mention (no pun intended) it here?
>>
> Done.
>
>> Ex. 2 was a bit puzzling, for two reasons.
>>     Firstly, as soon as I see  "entity(obs:bundle1, [ prov:type='prov:Bundle' ])", I think "provenance of provenance" but that is 
>> not the point.  In fact why add
>>        wasAttributedTo(obs:bundle1, ex:observer01)
>>       when ex:observer01 is never mentioned again, and this little PofP example is not carried forward (similarly for 
>> wasAttributedTo(tool:bundle2, viz:Visualizer) )
>>     Secondly, the example shows that if I want to systematically add attributes to existing entities, I must use a fairly 
>> heavyweight machinery that involves "mentioning" each of the elements that appear in  a bundle and which have the extra 
>> attribute, using a new bundle. This may be inevitable, but you must admit it is a bit of a work just to specify additional 
>> rendering attributes.
>>   Also, suppose I want to render elements of obs:bundle1.  One would expect to search for a bundle of type viz:Configuration, 
>> that is somehow related to obs:bundle1. However, there is nothing that says " tool:bundle2 contains rendering information about 
>> elements of obs:bundle1".   Instead that relationship is not between obs:bundle1 and tool:bundle2, but amongst its elements!
>>  So I would have to inspect all bundles of type viz:Configuration, and for each of them see if I find a mentionOf some elements 
>> in obs:bundle1 that carries its rendering attribute.
>> (one could index mentionOf for a quick search, but then it is not clear why we would need tool:bundle2 at all?)
>>   The fact that rendering attributes have little to do with provenance does not help...
>>
>
> Not relevant to display provenance ...???
>
> The problem you discuss is typical of open hypermedia systems where links are not embedded into the document  you are linking from.
>
>
>> sec 3
>> I have a general comment on how one can enforce an RDF pattern to be complete. When you say " the triple :x prov:asInBundle :b is 
>> also asserted to cite the Bundle in which :y was described.", I naturally ask "what happens if that I omit the assertion"? for 
>> example if I omit
>>   prov:asInBundle :run2;
>>  in ex. 3?
>> in PROV-N, it is clear that some arguments of a relation are mandatory, and this is enforced by the grammar, or by the parser's 
>> semantic analysis. What is the equivalent mechanism in RDF? Is there a SPARQL-based validator that determines that a required 
>> property is missing?  it may be worth clarifying.
>>
>
> We don't state this in PROV-O, and we shouldn't here. Essentially, prov-constraints is giving us the structure
> of well formed expressions.
>
>> sec 5
>>  An entity can be the subject of at most one mention relation. -> I mentioned above that this may come up earlier, eg in Ex. 1
>>
>>
>> minor suggestions:
>>
>> sec 1: provenance should be trusted,--> provenance itself should be trusted,
>>
>> sec 2: table mention-nonterminal a bit too heavyweight for its purpose?
>>
>>
>> Hope this helps,
>>   -Paolo
>
>
> Can you confirm you're happy with release as FPWD.
> Thanks,
>
> Luc
>
>>
>> -- 
>> -----------  ~oo~  --------------
>> Paolo Missier -Paolo.Missier@newcastle.ac.uk,pmissier@acm.org  
>> School of Computing Science, Newcastle University,  UK
>> http://www.cs.ncl.ac.uk/people/Paolo.Missier
>
> -- 
> 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 Kingdomhttp://www.ecs.soton.ac.uk/~lavm
>


-- 
-----------  ~oo~  --------------
Paolo Missier - Paolo.Missier@newcastle.ac.uk, pmissier@acm.org
School of Computing Science, Newcastle University,  UK
http://www.cs.ncl.ac.uk/people/Paolo.Missier