- markup (76)
- xml (11)
- xslt (23)
- pipelines (8)
- atom (9)
- overlapping markup (6)
- schema (11)
- creole (5)
- dtll (1)
- xforms (1)
- xpath (1)
- xquery (2)
- coding (2)
- datagovuk (1)
- genealogy (4)
- hardware (1)
- linked data (16)
- modelling (1)
- named graphs (1)
- opendata (1)
- provenance (1)
- psi (3)
- skos (1)
- sparql (4)
- Talis (7)
- unicode (1)
- uri (4)
- versioning (1)
- visualisation (6)
- web (78)
- google (4)
- html5 (5)
- jQuery (2)
- rdf (46)
- ontologies (2)
- rdfa (8)
- rdfQuery (5)
- rest (6)
- wikis (1)
- work (3)
- legislation (2)
- xmlsummerschool09 (2)
- life (28)
- children (5)
- equality (6)
- gtd (1)
- environment (4)
- gadgets (5)
- software (3)
- xlinq (2)
- conferences (11)
- ukgc09 (1)
- xtech (9)
- xtech2008 (3)
- blog (8)
- drupal (3)
Re: Creating Linked Data - Part IV: Developing RDF Schemas
These are obviously important and complex issues. I’m just going to put the counter arguments down for balance, not because I particularly disagree with your points.
Regarding return on investment, there’s no denying that modelling, analysis and publishing of linked data all take much more time and effort than simply putting a zipped Excel spreadsheet on the web, and that the benefits of doing it are much harder for people to see than a flashy web page. If you instead take as your baseline the development of a RESTful API on to your data, I don’t think the RDF-ness actually adds much overhead. This is a point that the /programmes developers such as Tom Scott at the BBC make very well. If you’ve got a decent website (by which I mean one with clean, persistent URIs for different kinds of resources) then you’re really through the stages that take the most work.
Regarding bugs in visualisations, I don’t think that there’s much difference here between visualisations based on RDF data and visualisations based on CSV (or XML, or any other kind of) data. The programs that you write to perform the analysis that you need to create your visualisation might be buggy, or it might be a problem with the underlying data, and tracking that down is always hard. It comes down to confidence in and familiarity with the technologies and the data that you’re using, so the way we can help here is to make it easier to do things like explore data and generate queries to help people gain the experience they need.
Name a technology in which change is easy to handle! This is an issue that deserves a lot more than a paragraph in a comment, but basically linked data has exactly the same characteristics as the web when it comes to change over time, so you could view it as incredibly robust or irretrievably broken :) The only thing that really needs to remain constant is that a URI always has the same meaning (whatever that meaning was when you minted it), and even then URIs can fail or redirect without anything actually breaking… Hmm, I’ll have to write more on this another time.