Re: Requirements for a possible "RDF 2.0"

>2010/1/15 Jeremy Carroll <jeremy@topquadrant.com>:
>> Steve Harris wrote:
>>>
>>>> * an RDF/XML profile (as above) designed for maximum compatibility
>>>> with XPath/XSLT/XQuery
>>>
>>> That would be nice. I often thing that RDF/XML is not a terribly 
>good way
>>> to encode RDF in XML.

+1

I think there is the opportunity to go for an 80/20 update to RDF, 
analogous to the move from SGML to XML.

I support the "simplification" approach (triples only; no more complex 
structures), while agreeing with the proviso that there must be some 
means of making a statement about a statement or set of statements (for 
authority/trust/metadata purposes).

With such a simple approach, a new XML serialization of RDF can likewise 
be totally simple, and self-evident to human eyeballs.  This will have 
two positive benefits:

  - it finesses the need to proliferate alternative serialization formats 
(e.g. Turtle), each of which requires the development of a totally 
separate toolchain before data expressed in it can be used;

  - it makes the serialized RDF directly machine-processible using 
standard XML-based mechanisms, as suggested above.  For example, it 
would be easy using XSLT keys to grab all the statements with a certain 
URI as subject, and thereby represent one node in the RDF graph.

If we can stay with XML as the default RDF serialization, we can go 
further. At present, Linked Data resources allow you to put queries, and 
get a bit of Linked Data back.  In some cases, this query result will 
contain information that is directly useful in its own right, but 
frequently the enquirer will be after the URIs it contains.

For example, I might put a museum-oriented query, to find long case 
clocks made in London in the 1820s, and now in U.K. museums.  (I wish!) 
The result of this fictitious query will include the URIs of said 
clocks.  I can stay in Linked Data mode, e.g. with a SPARQL Describe 
request, and grab all the RDF statements about my result set.  The 
result would look like the output of most Linked Data browsers.

However ... What if I could use those URIs to access a rich textual 
description of each clock, expressed in XML and using that thing called 
natural language, which is so much more meaningful to readers than RDF 
statements?  This is to some extent possible now, with luck and a 
following wind, using the 303 strategy and suitable HTTP Accept headers. 
However, the 303 approach seems to want to equate "human-readable" with 
an HTML representation of the resource.  I want the resource to be in 
XML, so that I can continue machine-processing it, e.g. selecting 
relevant parts of each clock's description.

This direction of travel would be helped if RDF learned a lesson from 
Topic Maps, and made a proper distinction between subjects (=Topics) and 
resources (=Occurrences), e.g. by adding rdf:subject (which would have 
an IRI as value).  Then we could make statements such as "the Subject 
XXX is defined by the resource YYY" and "the Subject XXX is defined, in 
French, by the resource ZZZ", where YYY and ZZZ are XML resources. This 
also gets us round the current irritating limitation of having to use a 
single string to define any concept.

Developing this approach, it becomes possible to imagine publishing a 
subject as a self-contained chunk of XML containing both the RDF 
statements you currently get, but also one or more full-flavour XML 
resources defining that subject in machine-processible, human-readable 
form.  This would be both easier to produce and manage, and easier and 
more useful to consume, than the current approach.

>There was the clunky 1998/99ish RDF/XML stuff which had eyeballs from
>xml-dev on it, but until relatively recently it seemed like the XML
>world and the RDF world were completely different planets. Now with
>the likes of Jeni & Bob DuCharme jumping on board the RDF raft it
>seems there is real crossover. (Not to mention the OpenLink one store,
>many views approach).

Kudos to the Linked Data initiative for that ...

Richard (another one from XML-land)

-- 
Richard Light

Received on Friday, 15 January 2010 12:11:21 UTC