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

Re: Outstanding Issues

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Wed, 13 Feb 2002 16:44:19 -0500
Message-Id: <p05101415b8908bf8699c@[]>
To: Brian McBride <bwm@hplb.hpl.hp.com>
Cc: w3c-rdfcore-wg@w3.org
>>>rdfms-seq-representation: The ordinal property representation of 
>>>containers does not support recursive processing of containers in 
>>>languages such as Prolog.
>>>Hmmm.  Anyone got a proposal for fixing this?
>>I don't think the ordinal property representation is a problem per 
>>se, but the lack of a maximum member indicator might be.
>True.  Hmmm, model theory question.  If we define a property of 
>containers, say rdfs:size which is the number of members, does:
>      _:a <rdfs:size> "10" .
>      _:a <rdf:_11>   <foo> .
>cause any theoretical problems?  Or is just an inconsistent model 
>with no interpretation.

Certainly the latter. But Im nervous about this. What determines the 
datatyping of that literal?? Does it even need to be datatyped?

A safer way might be to have a special last-element. Every container 
is required to 'contain' the item rdf:contLast, say, and if
_:a <rdf:_n> rdf:contLast .
then either its inconsistent to say
_:a <rdf:_m> bbb
for any m >n,

OR maybe easier, the end-of is optional, and you can say what you 
like, but things 'after' the Last arent 'really' in the container. 
That would enable Prolog-style guys to put an end-marker to terminate 
recursions without imposing any extra RDF content at all: we could 
even just suggest it as a coding style for people who want to do that.

If anyone objects that its hard to know how many items there are in 
the container, then tell them that if they object to finding that out 
by a recursive search, they shouldn't be using Prolog in the first 

I think we should just make this an official RDF non-issue.


IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
Received on Wednesday, 13 February 2002 16:44:23 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:53:55 UTC