jsled: A thoughful analysis of why using RDF in real, production code is hard.
jsled: and, what to do about it.
jsled: "One thing you can say about RDF is that it is highly flexible. Another thing you can say is that it consequently lacks clarity, especially when you have a lot of it. Never mind domain specific entities, just picking out domain archetypes (persons, items, invoices, events) is difficult enough. Even where there is a good knowledge of the vocabularies involved, for all its formality, collated RDF data tends to be messy."
jsled: "It turns out that RDF is surprisingly cheap stuff to generate. The downside was that for purposes of communicating intent, ongoing maintenance and adding functionality against the collected data, RDF is not very pleasant to work with, at least not compared to SQL/Objects. This is especially so at the presentation layer."
jsled: Very true based on my limited experience. The article also outlines some good ways to help attenuate the pain.
jsled: The biggest thing is going to be trad.-relational- and object- mapping technologies.
jsled: There's also generic relation here to the recent Adam Bosworth request + Danny Ayers response for "agile databases".
jsled: Though another part of the pain that Bill's expressing is -- as he says in the article -- just the pain of developing systems, especially with software development processes that expect the creation of bricks, not clay...
jsled: and, what to do about it.
jsled: "One thing you can say about RDF is that it is highly flexible. Another thing you can say is that it consequently lacks clarity, especially when you have a lot of it. Never mind domain specific entities, just picking out domain archetypes (persons, items, invoices, events) is difficult enough. Even where there is a good knowledge of the vocabularies involved, for all its formality, collated RDF data tends to be messy."
jsled: "It turns out that RDF is surprisingly cheap stuff to generate. The downside was that for purposes of communicating intent, ongoing maintenance and adding functionality against the collected data, RDF is not very pleasant to work with, at least not compared to SQL/Objects. This is especially so at the presentation layer."
jsled: Very true based on my limited experience. The article also outlines some good ways to help attenuate the pain.
jsled: The biggest thing is going to be trad.-relational- and object- mapping technologies.
jsled: There's also generic relation here to the recent Adam Bosworth request + Danny Ayers response for "agile databases".
jsled: Though another part of the pain that Bill's expressing is -- as he says in the article -- just the pain of developing systems, especially with software development processes that expect the creation of bricks, not clay...
KjetilK: "This is an effort to produce free (CC licensed) streetmaps of the world."
KjetilK: I figured this may be interesting for the many open data folks here
KjetilK: I figured this may be interesting for the many open data folks here
danbri: Homepage, wiki and RAA archive entries have been updated to acknowledge that this package is not being maintained, and to point to other efforts deserving of more attention.
danbri: I'm also despamming the public-rdf-ruby lists, and trying to fix the config to avoid future spam.
danbri: See also RubyRDF library "retired" / collaboration possibilities note to public-rdf-ruby list. Hmm I might've mentioned possible common APIs w/ other more dynamic languages, such as Python.
danbri: Where are things up to w.r.t. shared APIs in the Python semweb scene?