# Re: Collections vs Containers

From: Sandro Hawke <sandro@w3.org>
Date: Wed, 12 Nov 2003 02:27:46 -0500
Message-Id: <200311120727.hAC7Rkdb027687@roke.hawke.org>
To: David Menendez <zednenem@psualum.com>

```

>     2. Adding a statement to a graph containing a well-formed collection
> cannot change that collection *and* leave it well-formed.

Um, sure it can, it just implies some equalities.   But your basic
point is essentially right, yes.

>     { A rdf:_1 B. } <-> { A rdf:first B. }
>     { A rdf:_2 B. } <-> exists X. { A rdf:rest X. X rdf:first B. }
...>
>     { A rdf:_3 B. } <-> exists X. { A rdf:rest X. X rdf:_2 B. }

Yes, very nicely put.

>     { S rdf:first A;
>         rdf:rest [
>           rdf:first B;
>           rdf:rest [ rdf:first C; rdf:rest rdf:nil ]
>         ]
>     } -> { S rdf:_1 A; rdf:_2 B; rdf:_3 C }
>
> *but*
>
>     { S rdf:_1 A; rdf:_2 B; rdf:_3 C } ->
>     { S rdf:first A;
>         rdf:rest [ rdf:first B ], [ rdf:rest [ rdf:first C ]] }.
>
> Even if S is known to be a well-formed list (in which case rdf:first and
> rdf:rest are functional), we still can't infer the rdf:nil.

The essential difference could be made up by
S rdf:length "3"^^xsd:int.

That may look ugly to RDF eyes, but any OWL reasoner has to handle
integer values like that, so it'll get nicer (in our heads or our
computers; I don't know which :-).

I'm pretty sure I could then write the general  <->  formula,
given a predicate linking rdf:_<n> to rdf:_<n+1>.

Alas, this is probably too late to make it into this current unnamed
version of RDF.  (RDF Core seemed unwilling to consider the seemingly
obvious fact that {<a> rdf:_1 <b>.  <a> rdf:_1 <c>.} implies {<b>
owl:sameAs <c>.} and I never got around to trying to understand why.)

> Perhaps this idea is already obvious to the community, but I hadn't seen
> it in any of the literature, and it seemed neat, so here you go.

If it's been spelled out so clearly before (which is totally
possible), I missed it, too.

-- sandro
```
Received on Wednesday, 12 November 2003 02:25:16 UTC

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