Re: "Simple Lists" (was Re: ISSUE-77: Should we mark rdf:Seq as archaic (cf ISSUE-24))

On Sun, 2011-10-16 at 20:19 -0500, Pat Hayes wrote:
> On Oct 16, 2011, at 3:28 PM, Steve Harris wrote:
> 
> > On 16 Oct 2011, at 19:26, Sandro Hawke wrote:
> > 
> >> On Sun, 2011-10-16 at 19:13 +0100, Steve Harris wrote:
> >>> On 15 Oct 2011, at 23:35, Sandro Hawke wrote:
> >>> 
> >>>> On Sat, 2011-10-15 at 19:35 +0100, Andy Seaborne wrote:
> >>>>> 
> >>>>> On 15/10/11 19:09, Jeremy Carroll wrote:
> >>>>>> 
> >>>>>> I think both the Seq and the List constructs present technical issues.
> >>>>>> Basically it is because both present the possibility of 'bad' data and
> >>>>>> no clarity about what one should do in the face of it.
> >>>>> 
> >>>>> +1
> >>>>> 
> >>>>>> We can easily form ill-formed lists with rdf:first or rdf:rest either
> >>>>>> missing or multiple.
> >>>>>> We can easily form ill-formed sequences with duplicate or missing rdf:_2
> >>>>> 
> >>>>> although Seq are very fragile and lists are merely fragile.  The 
> >>>>> duplicate rdf:_2 by merging is really nasty.
> >>>>> 
> >>>>>> The consumer of such ill-formed data is in a bind
> >>>>>> And what's worse is that formally the ill-formed data is not ill-formed,
> >>>>>> it is just triples.
> >>>>>> 
> >>>>>> We could label both with a health warning ...
> >>>>> 
> >>>>> Sandro said that:
> >>>>>> I think Turtle makes RDF Collections seem quite
> >>>>>> nice, and hopefully that will quickly set the tone (perhaps with a
> >>>>>> little help from us) for APIs and SPARQL 1.2 (?) having nice list
> >>>>>> handling functions that are as efficient as native (non-destructive)
> >>>>>> list handling functions. (I hope some APIs do this already.)
> >>>>> 
> >>>>> and the point about Turtle syntax, and the convenience of writing, is 
> >>>>> important.
> >>>>> 
> >>>>> Jena has container and collection APIs to make working with containers, 
> >>>>> collections easier but the details leak out if you can take a triple view.
> >>>> 
> >>>> Thinking about it today, I wonder if we can define a "Simple List" (or
> >>>> "Proper List", or something) as a list that can be losslessly
> >>>> transmitted via turtle's (...) syntax.  That means its structure is
> >>>> b-nodes, with no extra arcs, etc.   (Interestingly, it also means you
> >>>> can't include rdf:type rdf:List arcs....)   Then, we encourage tools to
> >>>> read/write simple lists, and to work with them efficiently.
> >>> 
> >>> To be honest, I think the ref:Collection structure is just a dead duck.
> >>> 
> >>> It works OK for lists on the order of 10 items, but is pretty impractical for thousands, or tens of thousands.
> >> 
> >> My claim is that in the typical or best cases, Simple Lists can be
> >> handled as efficiently as any general List structure, using your choice
> >> of single-linked list, doubly-linked lists, arrays, or possibly even
> >> something more complicated.
> > 
> > That sounds good…
> 
> Hmm. I thought that the whole point of the RDF Collection vocabulary was to allow what are basically LISP S-expressions to be stored and transmitted as triples, so that everything can be send down a 'RDF pipe'.  Changing a triples-based version of Sexpressions into some other kind of Sexpression representation doesnt seem to gain anything much in utility or performance, but destroys the compatibility (or requires the whole world to invent new ways to transmit RDF from place to place.) What is being gained here? 

It's a wave *and* a particle.

I'm picturing something that can fit into plain triples but can also be
treated as a decent list type.   The best of both worlds, although with
some costs.   

I think just adding a decent list type -- that can't be viewed as
triples -- might be too big a change for some people to accept, and
might not be so good for the model.  But I'm not sure, and I'm in favor
of exploring the idea further.    There's also the idea Andy mentioned,
which sounded like this but more so ... something more than lists ...
but I'm not sure what that might be.    Dictionaries?

   -- Sandro

Received on Monday, 17 October 2011 03:20:24 UTC