Re: Few comments on the constraints

On Aug 6, 2012, at 19:39 , James Cheney wrote:

> 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])

Ok. I *think*:-) I understand what you say, having re-read the part on uniqueness. 

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

Heh:-) It certainly does not look like being broken. Maybe a succinct note saying what you say above, eg, in the top level of section 4, before section 4.1 would help laypersons like me...

Thanks

Ivan

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


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

Received on Tuesday, 7 August 2012 10:04:09 UTC