Re: Changes to prov:Dictionary

On Wed, Jun 6, 2012 at 3:57 PM, Timothy Lebo <lebot@rpi.edu> wrote:

> EmptyCollection remains in the latest PROV-O (so that is not an issue).

puh! ;-)



> Would this use case be handled if Taverna instead leveraged the "additional
> attributes" that DM already provides?
>
> memberOf(id; c, {(key_1, e_1), ..., (key_n, e_n)}, cplt, attrs)
>
> perhaps a property taverna:isComplete or class taverna:CompleteDictionary ?

Of course that would work for Taverna, but no other system looking at
that provenance would understand it ;)  But perhaps that will have to
be just good enough.


> If this can't be handled soundly and properly in PROV-O and OWA, then I
> don't think we should try (or, fake it).

RDF lists can handle it well, and should map easily to lists in XML,
JSON and PROV-N.

For instance, imagine a functional prov:completeMembers:

:todays-us-supreme-court a prov:Dictionary ;
    prov:completeMembers ( :k0, :k1 )

:k0 a prov:KeyValuePair;                                    # (Note:
this would not be done in addition to a simple Collection.)
        prov:pairKey   "chief";
        prov:pairValue <http://dbpedia.org/resource/John_Glover_Roberts,_Jr.> .


:k1 a prov:KeyValuePair;
        prov:pairKey   "seat 4";
        prov:pairValue <http://dbpedia.org/resource/Anthony_Kennedy> .

This expands to something like:

:todays-us-supreme-court prov:completeMembers _:list0 .

_:list0 a rdf:List ;
    rdf:first :k1 ;
    rdf:rest _:list1 .

_:list1 a rdf:List ;
  rdf:first :k1 ;
  rdf:rest rdf:nil .   # terminating the list



(The same list could be done for a straight prov:Collection directly
to the entities, however I have separate concerns about your mixing of
hadMember of the entities and the key-value pairs in
http://dvcs.w3.org/hg/prov/file/tip/examples/eg-34-us-supreme-court-membership/rdf/eg-34-us-supreme-court-membership.ttl
)


However it might not always be appropriate to have a closed list of
members, so if we adopt the above I think we should also keep a flat
prov:hadMember expression. You *can* express an open-ended list by not
specifying the "rdf:rest rdf:nil" - but neither the RDF/XML nor Turtle
syntactic sugar for lists supports this.


rdf:Lists can however be horrible to query from SPARQL as unless you
know the exact list position, you will have to do something recursive
to follow the rdf:rest chain.

This could be argued is rather a SPARQL issue -
http://www.w3.org/2009/sparql/wiki/Feature:AccessingRdfLists - but is
not addressed by SPARQL 1.1.





> With the use of a custom attribute and type ( taverna:isComplete or class
> taverna:CompleteDictionary ), can you accept removing the special optional
> parameter on DM's memberOf?

I can accept it if it is right as you say that the majority of the WG
dislikes it, but I view it as a reduction of interoperability.


I do however buy the argument that we don't want to go down the rabbit
hole of defining closed worlds. The rdf:Lists is one way to work
around this, but if this is not acceptable then I'm OK with removing
CompleteDictionary.



-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester

Received on Wednesday, 6 June 2012 15:55:42 UTC