Re: Few comments on the constraints

Thanks!  I definitely agree it is heavy going, and sympathize - it wasn't any easier to write. The goal at this point is to get something that we are happy with at a technical level, and then work on making it more accessible - of course, this leads to the danger that it's still too inaccessible for people to be able to critique it confidently.  So your comments (as with the other reviews) are greatly appreciated.

To answer your question, yes, we do mean literally "[], the empty list of attributes".  I really wanted to avoid having existential variables for these lists, since that opens up a whole new can of worms that I really hope  we don't need to open.

Because we interpret uniqueness constraints as requiring merging all corresponding parameters, and because we define merging of attribute lists simply as "union" (as sets of key-value pairs), in effect we get the second interpretation: that is, when we don't know (or don't want to say) anything about the attributes something might have, we can just write [].  This especially simplifies inferences that conclude statements that have unknown attribute lists.

So really, an attribute list is a statement of partial knowledge of the attributes.  If we find out more about the described thing elsewhere (or through inference), merging allows us to staple the two lists together:

entity(e,[color=red])
entity(e,[height=42in])

==> {because of uniqueness}

entity(e,[color = red, height = 42in])

I was trying to stay close to what happens naturally if you translate the attribute lists to RDF properties (as we have been informally doing to align PROV_DM and PROV-O).  But if this still looks broken, it probably deserves more explanation, even if it's not actually broken; it took me a while to see (what seemed like) a good way to do it.

--James


On Aug 6, 2012, at 6:14 PM, Ivan Herman wrote:

> James,
> 
> I have not yet gone through the full document (and it is a heavy read for a newcomer:-). I have one notational question/issue on the notation. That is: what does '[]' means in the definitions/constraints? Does it mean 'a set of attributes whose content we do not know and care' or 'an empty set of attributes'. I have the impression that all the rules rely on the former case, essentially saying that we do not necessarily know about the attributes. Eg, in Inference 15 we infer a wasGeneratedBy and a wasAssociatedWith and, I presume, what we say there is that there might be attributes on those but we do not care (after all, attributes may be application dependent).
> 
> However, as a programmer, '[]' definitely associates with an empty list/array. 
> 
> I may be wrong in my understanding. In any case, it may deserve explicit definition (which I did not find…) 
> 
> More comments may come, but not today...
> 
> Ivan
> 
> Two mini buglets:
> 
> - Remark after the definition of optional placeholders: "wasAssociatedWith(id;a, ag,-,attr)" -> " wasAssociatedWith(id;a,ag,-,attr)
> 
> - Right before inference 8: "statemen,t" -> "statement,"
> 
> 
> ----
> Ivan Herman, W3C Semantic Web Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> FOAF: http://www.ivan-herman.net/foaf.rdf
> 
> 
> 
> 
> 
> 
> 


-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

Received on Monday, 6 August 2012 17:39:27 UTC