Rules for RDF Modelling
I saw this post from one of the Joost developers awhile back, but forgot about it. He talks about modeling choices they made in designing a scalable system. Summing up, he concludes by saying:
- Don’t use RDF collections. Use one-to-many properties that result in “collections” instead.
- If you need ordering, define the sorting algorithm instead of putting the ordering in your data.
- If you have (sort-of) one-to-one relationships in your model, and one or both sides of the relationship is identified by a bnode, merge the concepts into one and distinguish using properties.
Intuitively, this seems right to me. But I’m having a hard time solving one particular problem within these constraints: how to represent ordered contributors (authors, editors, and so forth).
I had been leaning towards using collections to represent this. For example:
<http://ex.net/1> dcterms:creator <http://ex.net/2> .
<http://ex.net/2> a foaf:Group ; vcard:sort-string "Doe, Jane; Smith, John" b:members ( <http://ex.net/3>, <http://ex.net/4> ) .
So I’m trying to wrap my head around how one would both preserve order and avoid collections and sequence properties (the define the sorting algorithm instead of putting the ordering in your data
bit).
Well, I think that posting misses a basic point. He seems to be assuming that the ordering can be computed somehow (eg lexical ordering or numerical ordering or ordering by date), but in your example it can’t. If the ordering is part of the actual data, you have to actually record it somehow in the actual data. No way around this. And I don’t think RDF collections are all that bad. Any other way is going to use a similar number of triples, for sure. If bnodes really bother you, you can just have an ordering property on the items directly:
b:member ex:net/3 b:member ex:net/4 ex:net/3 b:nextinorder ex:net/4
but this is dangerous if the same items can be in more than one collection. Or, you can have a whole lot of b:member properties which encode the ordering (rather like an RDF container)
b:memberOne ex:net/3 b:memberTwo ex:net/4
but then you have to make sure things don’t get pearshaped by having missing information.
Anyway, my advice is, use the collections already. They work, and whats a few extra triples. Moore’s law will fix that in a few months anyway.
Pat
Yeah, that makes sense Pat. So I think I’ll stay with the approach I use here (the explicit group modelling using a collection for the members) unless someone convinces me otherwise. It seems the simplest and also the most flexible.