W3C home > Mailing lists > Public > public-prov-wg@w3.org > November 2012

Re: prov-links review

From: Luc Moreau <l.moreau@ecs.soton.ac.uk>
Date: Tue, 27 Nov 2012 12:07:38 +0000
Message-ID: <EMEW3|0f9f497db805b743265bdf9c076109b2oAQC7g08l.moreau|ecs.soton.ac.uk|50B4AD0A.9070603@ecs.soton.ac.uk>
To: public-prov-wg@w3.org
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

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

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?

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


> -- 
> -----------  ~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
Received on Tuesday, 27 November 2012 12:08:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 November 2012 12:08:12 GMT