Re: Reification of Sets (of RDF Statement, for Queries)

Hi Sandro,


Sandro Hawke wrote:
> 
> Issue 1: RDF M&S Does Not Provide Sets

Hmmm, that looks more like an observation than an issue :)

Seriously though, I'm happy to capture this in the issues list.  It
would be helpful to know why the absence of a set construct is a
problem.  There are many things that can be added to RDF.  What is the
argument that sets should be built in to the core?  Or is the problem
that you feel that RDF as it stands cannot be used to describe sets?

Brian



> 
> The argument against them I've heard is "we don't have an enforcement
> mechanism" (for duplicates, so use bags) or "we have to provide them
> in some order" (so use lists).
> 
> I think those arguments against defining a vocabulary for
> communicating information about set membership are, to put it mildly,
> weak.
> 
> On the first point, you don't need to provide an enforcement
> mechanism.  If someone says "X contains 3" and then "X contains 3"
> again, well, you know "X contains 3".  No problem.
> 
> On the second: it doesn't matter if you have extraneous data.  In set
> theory, people say "x={3,4}" and they know it's the same as "x={4,3}".
> Yes, syntacticly the elements appear as a list, but the set whose
> elements were enumerated by the list is the name no matter what order
> of enumeration is used.  The extraneous ordering information is simply
> ignored.
> 
> Issue 2: Completeness of Knowledge  ("Closed" collections)
> 
> There is a significant difference between "The set X contains the
> numbers 3 and 4" and "The set X contains *only* the numbers 3 and 4."
> Given only the information in the first form, you cannot answer
> whether 5 is in X.
> 
> RDF collections at present only provide incomplete knowledge, so
> people have to frame their queries as being about a different set.
> "Is 5 in X?" cannot ever be answered negatively, so you have to ask
> "Is 5 in the set of things you currently know to be in X?"  I think
> this is broken.
> 
> This is different from the rdfms-seq-representation issue, althought
> the LISP-style list solution solves both problems.
> 
> More generally, here are some solutions:
> 
> For List Completeness:
> 
>    1)  Use predicates _1, _2, _3, ... and also a max_index predicate
> 
>        - needs integer sequence generation
>        - needs integer comparison
> 
>    2)  Use predicates _1, _2, _3, ... with a special object "-99"
>        which marks the end
> 
>        - needs integer sequence generation
>        - this is odd; that flag cannot be in any list
> 
>    3) Use predicates _1, _2, _3, ... with a special arbitrary end
>       marking object related to the list by a list_end_flag
>       predicate (ie, you pick the end object on a per-list basis).
> 
>        - needs integer sequence generation
>        - a little complicated
> 
>    4) LISP-style lists: predicates First and Rest, object TheEmptyList.
> 
>        - a little complicated
> 
>    5) ...?  anything else?
> 
> It's tempting to think in terms of the syntax where it looks like the
> list is complete:
> 
> <list id=foo>
>   <li>a
>   <li>b
> </list>
> 
> but in the abstract systax (think of the graph) that closing
> information is lost as the RDF parsers seem to handle it.  (As is the
> ordering, if you don't turn the "li" predicate into "_1"...)
> 
> For making Sets from Lists:
> 
>    1)  an Emumeration predicate, relating a set to a list which
>        contains all the same elements at least once
> 
>    2)  an ElementSet predicate, the inverse of Enumeration
> 
>    3)  ...?  anything else?
> 
> To bring this together in an example, I'm trying to represent RDF
> queries in RDF (ie to reify them).  I think the right approach looks
> in n3 like:
>    :myQuery q:statements { ... bunch of statements ... };
>             q:variables ( ... list of terms in the statements
>                               which are variables ...).
> but the conversion of the "bunch of statements" and "list of terms"
> into proper RDF Sentences is subject to a resolution to the issues
> raised here.  My current vote is for (4) lisp-lists and (1) a set
> enumeration predicate.   If anyone has any objection to these, I'd be
> interested in hearing it.
> 
>    -- sandro

Received on Friday, 13 April 2001 07:59:22 UTC