- From: Sandro Hawke <sandro@w3.org>
- Date: Wed, 23 Mar 2011 13:03:59 -0400
- To: nathan@webr3.org
- Cc: RDF WG <public-rdf-wg@w3.org>
On Wed, 2011-03-23 at 16:22 +0000, Nathan wrote: > Just wanted to capture something I don't think I've conveyed until now: > > Almost every developer I know, from enterprise to bedroom developers, > work primarily with OO oriented languages, or key/value data structures > in functional languages. > > The primary *huge* issue here, is that most people can't work with > triples and graphs without special tooling. Not to mention that it's > highly unfamiliar to them. > > Send an object with an id over the wire and people can use it, it's > familiar, they "get it", send them a triple, and they're lost - even if > they grok the graph and triple, they don't have the machinery to handle > it often. > > This is pretty much the sole reason that every developer I know outside > of the sem web community does not use RDF in any way, even though they > like the concepts and would like "linked data". Yes, good to name this elephant, even though I think we're already working around it. I think of this as a close cousin to the "object-relational impedance mismatch".... http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch ... and sometimes I just call it that. Many of the items listed on that page don't apply, so many just "impedance mismatch" in the RDF context is good enough. I think I first heard that term applied to this problem by Dave Reynolds. My sense is that it manifests most clearly in RDF allowing a single property of a single item can have multiple values at once. That's nonsense from an OO perspective. (In RDF we can say the foaf:name property of :Sandro has multiple values, simultaneously. In OO, that's nonsense, and instead we would have to say the foaf.name property of Sandro has a value which is some sort of collection of other values.) (As I recall, Dave Reynolds was also pointing out how different rdfs:domain and rdfs:range and rdfs:subClassOf are from what OO folks expect.) This is part of why I like presenting SPARQL result sets to the json folks. There are no multiple values, and in general I think it's clear to say that each object they get is a result from (or a match to) a particular query. They don't need to understand the query itself until they are ready to understand the modeling, which is a more advanced step that not everyone needs to take. -- Sandro
Received on Wednesday, 23 March 2011 17:04:11 UTC