Raw

Richard, I can't deny that the spec stack is pretty overwhelming, and RDF Semantics in particular is very hard work. But I don't believe this is a barrier to implementation, quite the opposite. If I want to use a relational database, I won't try to decipher and implement Codd's formal description, I'll download MySQL. If I want an RDF store/API I'll use Jena or Redland or one of the many other available toolkits. That the developers of these have had the formalisms to work against means that, aside from individual language idioms, the tools behave in the same predictable fashion.



When you say "Let's figure out which parts of it are fit for the purpose and which are not", I can't disagree, because in practice I've repeatedly found myself doing exactly that, but in a different way than you suggest.



Jena is *huge* (I won't hold this against it's developers, Java does seem to lead to pretty Baroque APIs generally), that can be confusing, and virtually every time I've used it I've ended up creating interfaces that represent a tiny subset of what's available. Redland's Python binding exposes a relatively small number of classes/methods, which happen to be the ones that tend to be needed most often. But if more sophisticated access/processing is needed it can be written on top, you aren't restricted by an overly simple underlying model.



Re. your suggestion that RDF itself is too "SGML", there I differ. The model itself is conceptually simple, and most difficulties I've had with working from that point of view have been related to its fairly non-intuitive "looseness" (largely due to the OWA), not to any inherent complexity. RDF/XML isn't an issue for me because all the tools have built in parsers/serializers.

@en