W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > October 2002

Re: rdf:first/rest/nil/List: syntax-only at the RDF level

From: Jeremy Carroll <jjc@hpl.hp.com>
Date: Wed, 30 Oct 2002 20:37:43 +0100
To: <w3c-rdfcore-wg@w3.org>

a disgruntled Pat wrote:
>I would like to see a more detailed explanation of why the code could
>not be modified to accommodate to this,

I highlighted three features that I believe are in the list semantics that
you would like to include:

- infinity
- equality
- contradiction

Of these the most difficult is infinity.

Our typical API allows you to list the triples in a graph one by one, or the
triples that match some expression, one by one. We are extending this API to
support RDFS closure (compare with Ora Lassila's paper "Taking the RDF Model
Theory Out for a Spin" Sardinia ISWC 2002).
This method will produce highly surprising and unacceptable results if the
RDFS closure of a graph with a single triple in, has an infinite number of

The result would be that we would need to redesign our API so that the API
concepts much less clearly matched the RDF Semantic concepts - which would,
in my opinion, be too great a price to pay for supporting webont in their
list semantic problems. Doing list comprehension is not conceivably an RDF
Core problem. DAML+OIL didn't do it, it's new for OWL.

Equality is also difficult.

You say that Dan's entailment below does not hold.
>Consider this conjecture:
>   eg:myBrothers rdf:first eg:paul.
>   eg:paul eg:hairColor "brown".
>   eg:myBrothers rdf:first eg:jon.
>   eg:jon eg:height "tallish".
>   _:somebody eg:hairColor "brown".
>   _:somebody eg:height "tallish".
>I don't want that entailment to be justified by the RDF
>nor RDFS MTs;

Please explain why it doesn't.

If you have a neat trick for having only one first without Dan's entailment
then maybe that will be alright. The problems about the contradictoriness of
rdf:nil rdf:rest _:a . I can probably live with, although I would need to

Received on Wednesday, 30 October 2002 15:26:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:16 UTC