I’ve been mulling over this alternate way of thinking about RDF, one that is resource-oriented rather than triple-oriented. This is what I came up with:
~~~~
The Resource Description Framework (RDF) is a framework for representing information in the Web. RDF has a simple data model that is easy for applications to process and manipulate. The data model is independent of any specific serialization syntax.
RDF provides information about resources through Resource Descriptions. A Resource Description consists of:
- A subject resource identified by a URI
- Zero or more relationships to other resources
- Zero or more properties having literal values
A relationship comprises a pair of URIs: the first URI denotes the type of relationship, the second identifies the related resource.
A property comprises a pairing of a URI with a literal value. The URI denotes the type of property. The literal value is a string with an optional datatype (denoted by a further URI) or language tag (as defined by RFC-3066)
~~~~
Nothing technically different from the existing formulation (I omitted mention of blank nodes for brevity only – they would still be present) but perhaps a lot easier for developers used to resource-oriented systems to grok.
Note: in the original version of this post I used the term document-oriented, but switched to resource-oriented on the suggestion of Niklas Lindström
Note2: this formulation bears a striking resemblance to the HAL linking scheme for JSON
I agree that the triple-centric approach is very painful for developers to both grasp the concepts initially and then implement something useful on top once they understand the concepts.
The Resource / Attributes-Value / Relationship formulation is much more intuitive and maps well to pervasively implemented modeling schemes such as ORMs where objects have properties and references to other objects or tas document oriented databases like Riak, CouchDB and MongoDB. Riak explicitly features “links” while other require application level intepretation of some attibute values as references to other documents to model relationships.
I generally describe RDF in two very different ways depending on the audience.
If the audience is already versed in data structures, I just tell them it’s effectively akin to a 3 column database (skipping graph, datatype and lang as these are not needed to grasp the basic structure). I often refer to URIs as a ‘globally unique id for something’, and only later explain that we use URIs ‘to make it easy to create unique strings’ (and explain resolvable URIs later, depending on the length of the talk)
It’s very important to stress that RDF/XML is a serialisation of a very very simple data structure. I usually show programmers N-Triples first, then when their “isn’t that verbose” concern kicks in, I show them turtle, and explain in apologetic terms about RDF/XML.
A really key fact that helps people get their ‘aha’ moment is when they understand that you can combine two piles of triples and get a pile of triples. You can’t do that in JSON, XML or any other structured data format.
For non-techie audiences, I explain that I take databases, or spreadsheets, and chop them into the smallest possible facts which are individually true, like “The Ball is Red”, “Building 59 has latitude 54.13414″ etc. I then explain we take each set of facts and put them in one big pot (the triple store) and can then recombine them with new structures to produce new spreadsheets, web pages, maps etc, all built from facts which we’ve already approved for publication.
I’ve been working on a page to point people at to help them get started and find useful references, http://openorg.ecs.soton.ac.uk/wiki/Linked_Data_Guide_for_Newbies
It’s specifcally aimed at techies who don’t really believe the hype and don’t want to go on a training course. It’s a constant work in progress, but I mostly take ideas from people learning rather than the experts, as it’s useful to see where the cognitive gaps are.
In any case, the goal is to build a simple model in people’s brains which will help them understand the more complex explanations and documentation already out there — much of it is written for software tool/library implementors not web devs.
Yeah, I agree that the resource-centric (or node-centric) view is more practical, and that’s the direction we took in Needle, too.
I think the relationship/property distinction is actually pretty tricky, though, and one of the biggest sources of modeling errors. The formulation I’m thinking about now is more like this:
- Each logical piece of data is a Thing.
- Things connect to each other with Relationships.
- A Thing can have various representations in Symbols.
RDF’s relationship to “literals” is, in my opinion, a huge and embarrassing mess. Datatypes, language tags, the weird insistence that literals can only appear in object position: these are all symptoms of a poor grounding. So instead of saying that a person has a name “property”, whose value is the literal “glenn mcdonald”, I want us to say that a Person thing has a relationship to a Name thing, and that Name thing has a symbol representation as “glenn mcdonald” (and might also have a symbol representation as the node ID 45704). This is less spreadsheet-like, and thus arguably harder, but I don’t think it’s really very helpful to make things seem enticingly traditional and then have everything interesting fall apart because you can’t assign types to literals and hope to keep making sense of your world.
The only issue I perceive with this description is that grokking triples is still useful when learning about SPARQL. Of course, SPARQL isn’t used by everyone when creating linked data apps, they may use an abstraction layer, or store in something other than a triple store, but knowing about triples and how that maps into a graph representation made having that “lightbulb” moment when first learning SPARQL a bit easier.
This formulation would lend itself to alternate types of querying, such as templated “fill in the blanks of a resource”.
I like it, and an additional sentence or two about what RDFS and maybe even OWL add to this arrangement would be a natural fit to what you have here.
What kind of RDFS/OWL do you think would be appropriate?
How’s this: “While RDF does not require that resource classes, relationships, or properties be declared somewhere before you use them, doing so using the RDFS or OWL standards can provide additional metadata about your resources that aids interoperability between different applications using similar data”.
The tripliness of SPARQL is, to me, part of the overall awkwardness of doing real data apps with the current stack, and why in Needle we did a resource-oriented query language, too!
I think the above description has a flaw in that it is forward relationship biased. Maybe also needs …
Zero or more relationships to it, coming from other resources.
I disagree. They arise from other resource descriptions having relationships with this one. Technically there is not difference, but it’s much easier to understand that you are describing a resource, its properties and its relationships _to_ other things.
But the unidirectionality of relationship assertions in the current formulation of RDF is ANOTHER significant difficulty in use! I continue to believe that a better abstraction would present relationships in both directions interchangeably and transparently.
A shorter version:
RDF (Resource Description Framework) is used for describing various things. A thing can be described with properties that have literal values or by relationships to other things. It is used on the Web, so it’s important that names of both things and relations have globally unique names, i.e. URIs.
Pingback: A Different Way to Think about RDF - semanticweb.com
Great post; something I find frustrating sometimes in discussions about RDF/Linked Data being worthwhile or not, is the focus on the technology, to the neglect of its purpose: connecting data.