Re: prov-links review

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 Kingdom                     http://www.ecs.soton.ac.uk/~lavm