Re: PROV-ISSUE-374 (member-membership-indirection): indirection for Dictionary members [Ontology]

This was worked out with the latest prov-o Dictionary rework (to suit the Qualified pattern), which is now ending up as a Note.
I am closing this issue.

Tim

On Jun 1, 2012, at 1:40 PM, Stephan Zednik wrote:

> 
> On May 25, 2012, at 2:30 AM, Stian Soiland-Reyes wrote:
> 
>> This is to match the DM signature:
>> 
>>> A membership relation, written memberOf(id, c, {(key_1, e_1), ..., (key_n, e_n)}, cplt, attrs), has:
>>> 
>>> id: an optional identifier identifying the relation;
>>> after: an identifier (c) for the dictionary whose members are asserted;
>>> key-entity-set: a set of key-entity pairs (key_1, e_1), ..., (key_n, e_n) that are members of the dictionary;
>>> complete: an optional boolean Value (cplt); if true, it indicates that no other member belongs to the dictionary; if false, it indicates that other members belong to the dictionary; if unspecified, other members may belong to the dictionary.
>>> attributes: an optional set (attrs) of attribute-value pairs representing additional information about this relation.
>> 
>> The prov:Membership intermediate class is thus the anchor point for
>> the id, attributes, and indication of complete membership (by use of
>> subclass of prov:CompleteMembership - however that is not currently in
>> PROV-O as it was uncertain at the time if it would make it into DM).
> 
> 
> ++
> 
> It's a usage of the qualified relation linked data pattern (http://patterns.dataincubator.org/book/qualified-relation.html) to support optional attributes on memberOf relation as defined in the DM.  
> 
> In the DM memberOf currently has a 1 to many relationship of dictionary to key-entity pairs.  This is a little cumbersome.  We can support it with a qualified relationship (linked data definition), but do we want to?
> 
> Actually, the more I look at this the more I agree that it's current modeling in the DM off.
> 
> On the after qualified:
> 
> Dictionaries are Entities.  An update to a Dictionary is the result of an Activity which used the previous version of the Dictionary.  A derivedFrom relationship can then be determined between the updated and previous dictionary entities.
> 
> I think we can model updates to and creation of dictionaries using existing core prov relations.  Membership seems redundant when we can just use an activity to create and update dictionaries.
> 
> On the complete attribute:
> 
> What is the justification for being able to say that a Dictionary membership is incomplete?
> 
> Why say that a dictionary membership is complete?  A Dictionary's membership should be simply what is stated.  With RDF, the only way I can think of to make membership a closed set would be to use a rdf:List or similar pattern. Setting an attribute or creating a class type will not enforce complete and final membership.
> 
> On the optional set of attribute-value pairs:
> 
> What optional attributes would apply to Membership that could not be applied to the Dictionary entity?
> 
> --Stephan
> 
>> 
>> Although this is not a qualified relationship (there is appropriate
>> binary relationship version) it follows the same style as other
>> relationships with regards to matching DM identifier and attributes.
>> 
>> It can be argued if DM really needs the id and attributes here - but I
>> guess for consistency reason it's better to keep them here as well.
>> 
>> 
>> On Tue, May 15, 2012 at 2:03 PM, Provenance Working Group Issue
>> Tracker <sysbot+tracker@w3.org> wrote:
>>> 
>>> PROV-ISSUE-374 (member-membership-indirection): indirection for Dictionary members [Ontology]
>>> 
>>> http://www.w3.org/2011/prov/track/issues/374
>>> 
>>> Raised by: Timothy Lebo
>>> On product: Ontology
>>> 
>>> What is the purpose of prov:membership [ a prov:Membership ] in the Dictionary Modeling?
>>> Would it not be more straightforward to use prov:member to describe the Dictionary directly?
>>> 
>>> Currently, the 2WD PROV-O uses:
>>> 
>>> :c1 a prov:Dictionary;
>>>  prov:membership [
>>>     a prov:Membership;
>>>     prov:member [
>>>        a prov:KeyValuePair;
>>>        prov:key   "k1"^^xsd:string;
>>>        prov:value :e1
>>>     ], [
>>>        a prov:KeyValuePair;
>>>        prov:key   "k2"^^xsd:string;
>>>        prov:value :e2
>>>     ];
>>>  ];
>>> .
>>> 
>>> Why could it not be simply:
>>> 
>>> 
>>> :c1 a prov:Dictionary;
>>>  prov:member [
>>>     a prov:KeyValuePair;
>>>     prov:key   "k1"^^xsd:string;
>>>     prov:value :e1
>>>  ], [
>>>     a prov:KeyValuePair;
>>>     prov:key   "k2"^^xsd:string;
>>>     prov:value :e2
>>>  ];
>>> .
>>> 
>>> 
>>> Thanks,
>>> Tim
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> 
>> --
>> Stian Soiland-Reyes, myGrid team
>> School of Computer Science
>> The University of Manchester
>> 
>> 
> 
> 
>

Received on Sunday, 1 July 2012 14:01:44 UTC