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

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 Friday, 1 June 2012 17:41:33 UTC