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.

I know that (DanC made that remark a while ago)
The only difference I see is that the context is an in-line resource
(in-circle for an RDF graph)

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

:x is in a list if :x is the first element of that list
and that list is here {:x :list :b} which indeed has :x as first element
clear?
It is actually the power of (prolog) unification i.e. in(X,[X|_]).
The other rule for :in is similar i.e. in(X,[A|B]):-in(X,B).

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

I first have to digest my late evening food ... :-)

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

That is a very interesting point (that NOT-in)
I had a similar experience while avoiding :sibling1 :NOT-equals :sibling2.
(by assuming the sibling relation being irreflexive (at the ontology level))
any suggestion to avoid the NOT here too?

>
> >  [[[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.
>

True, lists are recursive datastructures.
Declaring rules making use of difference lists makes a big difference

>       -- sandro
>

--
Jos De Roo, AGFA http://www.agfa.com/w3c/jdroo/

Received on Tuesday, 10 April 2001 15:21:04 UTC