On Fri, Feb 1, 2013 at 12:21 PM, Andy Seaborne <[email protected]> wrote:
> On 01/02/13 16:51, Paul Gearon wrote: > >> >> On Fri, Feb 1, 2013 at 10:38 AM, Andy Seaborne <[email protected] >> <mailto:[email protected]>> wrote: >> >> Nasty things RDF alt/bag/seq from the POV of a database. >> >> >> Could I get your perspective on this please? I accept that best practice >> abandoned them long ago, and RDF 1.1 is deprecating them. I also >> appreciate the mathematical elegance of the list structure. However, I >> don't understand why Containers are considered nasty... with the >> exception of the rdf:_nnn properties. Is that what you're referring to? >> Or is it something else? >> >> Regards, >> Paul Gearon >> > > (on list?) > Seemed a little off-topic, but sure... > It's the DB implications, not the modelling issues, I was poking at. > > ?x rdfs:member ?o > > is basically a whole DB scan looking for rdf:_NNN > > Yuk. > I've always dealt with it in one of 2 ways.: a) Look for rdfs:member (often not possible, but useful when available) b) Use an index that orders by IRI. Since most indexes are tree based, then this is easy enough. In Mulgara's case I created a "magic" predicate that could match IRIs by some prefix, then looked for the prefix of http://www.w3.org/1999/02/22-rdf-syntax-ns#_. We have a few range lookups in the literals, and IRIs are stored similarly, so the code to find and join this data to the triples already existed. > Even with ?x, need to scan for rdf:_1, rdf:_2, etc rdf:_99186 > Could specially handle ... but Jena does not (ditto lists) > Well at least lists now have support with property paths in SPARQL. While property paths give you the tools you need to read and manipulate lists, there's still some work to be done for the programmer who uses them. We probably need to get out a tutorial on common list operations in SPARQL, since I find that to be a very common question. A trie on IRIs? > The IRIs here all start with the same prefix, so I find that a simple ordered index is enough. > There are modelling-wise issues: > > Can add rdf:_1 to have two of them. In a Seq ??!!? > Merge two seqs with the same URI and you get ... a mess. Lists at least > will be bnodes. > Not easy at the modeling level no. Programming in the guts of the DB is easy enough, since you can just append one container to another, or whatever approach you choose. However, once the operations get abstracted up the stack (in SPARQL, for instance), then it becomes something between hard and intractable. Practically: > > No Turtle support > You/app writer see the horrible encoding. > I've started dropping RDF/XML support, so that's certainly an issue. I do like Turtle list syntax. > Really RDF needs a list-ish thing as a first class data type, not encoded > as triples. If triples, when you work with the data, you see triples and > the app or library has to reconstruct. But you can also have mal-formed > encodings in triples and the code has to cope. James Leigh proposed this before the new RDF WG was started. Working with Datomic right now (a non-RDF triple-store, which has no support for this either) has made it very clear how important first class collections would be. I ended up adopting RDF-like practices in that case. Paul
