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

>> Issue 1: RDF M&S Does Not Provide Sets
>
>Just to make sure that we talk about the same thing, I understand a set
>as defined in http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?query=set

Yes, exactly.

>>    5) ...?  anything else?
>
>Well, we have been using recursive lists with predicate :list and object :nil
>as you can find out at http://www.agfa.com/w3c/euler/lists.axiom.n3

I think you're using n3 curly-brace expressions to denote something
interesting but beyond the scope of n3 as I understand it.   Some
kind of an operator structure, I think.   My sense of n3 is that
curly-brace expressions simply denote sets of RDF sentences.

Can you turn the first line 
   {:x :in {:x :list :b}} a log:Truth; log:forAll :b, :x.
into English for me?  Actually, let's use an instantiation:
   :foo :in {:foo :list :bar}.
I read that as: ":foo" has an ":in" which is the mathematical set
containing only the RDF sentence which has the subject ":foo", the
predicate ":list", and the object ":bar".   That hardly seems like
what you meant.

Pending understand that, I can imagine two more list construction
mechanisms from your suggestions here:

    nil      (the empty list)
    append   (the three-way relation between a prefix list, 
              a suffix element, and the resulting list)

and

    list     (the relation between an element and a singleton list
              containing just that element)
    concat   (the three-way relation between a prefix list, a 
              suffix list, and the resulting list)
             [this is an interesting construction in that it 
              does NOT have a concept of the-empty-list.]

They both have the problem of involving a three-way relation.  In
decomposing them into the binary relations we want, we end up with
slightly different concepts.

    append(result, prefix, appended_element)

turns into binary relations via argument-labeling:

    append_result(append_action, result)
    append_prefix(append_action, prefix)
    append_appended_element(append_action, appended_element)

or if you're feeling adventerous via Currying:

    append(result, curry1)
    curry1(prefix, appended_element)


both of which seem more clumsy than First/Rest.  Is there some
elegance here I'm missing?


Ignore lists for the moment, I should certainly have added another
"set" mechanism:

     element   (the relation between a set and each of its elements)

but that doesn't help us answer NOT-in questions unless we have some
logic with negation to use with it.  And I think we'd want a set
structure mechanism to underly the logic mechanism.


>  [[[A difference list is a special kind of a list. Instead of being ended
>     by nil, a difference list has an uninstantiated tail so that new
>     elements can be appended to it in constant time. A difference list
>     is written as List - Tail where List is the beginning of the list
>     and Tail is its uninstantiated tail. Programs that use difference
>     lists are usually more efficient and always much less readable than
>     programs without them.]]]

Ha ha ha.  Very funny comment there.   I don't see how they are
different from list expressions involving variables -- a nice trick in
systems design, but not a fundamental mechanism for defining what
lists are.

      -- sandro

Received on Tuesday, 10 April 2001 12:44:27 UTC