prov-links review

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

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....

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.

- "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?


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?

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...

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.

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

-- 
-----------  ~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