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

From: Sandro Hawke <sandro@w3.org>
Date: Tue, 10 Apr 2001 12:44:20 -0500
Message-Id: <200104101644.MAA09221@tux.w3.org>

```
>> 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

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:29 UTC