Re: Some issues around RDF Collections and containers

I agree with these points wholeheartedly, but I have concern over the
difficulty and scalability issues of implementing anything to handle RDF
collections. Are there any large-ish RDF stores that handle these
intelligently or as a special case?

It would be possible to eg. get the first N members of a collection with
BRQL's OPTIONAL subgraph feature, something like:

	SELECT ?i0, ?i1, ?i2
	WHERE    (?car,  <rdf:first>, ?i0)
	OPTIONAL (?car,  <rdf:rest>, ?cdr)
	OPTIONAL (?cdr,  <rdf:first>, ?i1)
	OPTIONAL (?cdr,  <rdf:rest>, ?cddr)
	OPTIONAL (?cddr, <rdf:first>, ?i2)

But, I also have concerns over chained OPTIONALs.

The collection parsing I do in the manifest->HTML testcase code, is done
with a recursive function at the application level, which is what I've
always done up to now. Its inefficient, but not the end of the world.

- Steve

On Wed, Jul 28, 2004 at 10:11:21AM +0100, Andy Seaborne wrote:
> 
> Collections:
> 
> 1/ Getting the whole list
> 
> Getting the whole list requires traversing an arbitrary, unknown length 
> structure of RDF graph nodes.  Fixed conjunctive/disjunctive patterns 
> can't express this.  See also (3).
> 
> This is compounded by lists often being comprised of bNodes.
> 
> 2/ Asking if something is contained in a list
> 
> Testing whether some resource/literal is in a list is hard with fixed 
> patterns because you need to enumerate the possibilities.
> 
> 3/ Unusual structures
> 
> While most RDF collections are regular rdf:first/rdf:rest/rdf:nil 
> cons-cell structures, there is no restriction imposed for, say two 
> rdf:first's on one slot, or multiple tails to the list, or tails that 
> join up (well - OK - all tails join up at rdf:nil!)
> 
> Containers:
> 
> RDF containers are easier to deal with if there is the inference support 
> to provide rdfs:member.  But they still can have unusual structures like 
> two rdf:_1 elements or gaps in their numbering.
> 
> 	Andy
>