Re: RDFa + RDF/XML Considered Harmful? (was RE: Ordnance Survey data as Linked Data)

Richard Cyganiak wrote:
> 
> Hi Mark,
> 
> On 14 Jul 2008, at 10:22, Mark Birbeck wrote:
>> I would say that RDFa has made the situation an order of magnitude
>> _less_ complicated, since authors and developers now have an easier
>> way to publish metadata;
> 
> Well, RDFa has made life simpler for those publishers whose requirements 
> are met well by RDFa. It has made life more complicated for client 
> developers, since they have to support yet another RDF syntax.

If clients can rely on a solid RDF parsing toolkit for each language, I 
think this is a bearable (and perhaps healthy) division of labour. We've 
a way to go before that's achieved yet (eg. a 'just use x' answer for 
each of Ruby, Perl, Prolog ..., where x has rdfa, grddl, rdfxml, turtle 
etc support).

http://en.wikipedia.org/wiki/Postel%27s_law seems pertinent:

  "Be conservative in what you do; be liberal in what you accept from 
others."


> I think RDFa is an important piece of the SemWeb technology puzzle, but 
> your claim that it “makes the situation an order of magnitude less 
> complicated” is unfounded, IMO.

Talk of 'orders of magnitude' without a clear metric for what we're 
comparing, ... worries me. RDFa is a good thing. A very good thing. But 
don't ask me to put numbers on that.


>> as Kinglsey said, increasing the number of
>> ways to publish metadata increases the number of possible clients that
>> might consume the data:
> 
> Kingsley was talking about a situation where the publisher offers *all* 
> different methods of publishing RDF. Sure this increases the number of 
> theoretically possible clients, but it also increases the cost of 
> publishing RDF.

I think we'll see recipies around eg. OAuth whereby someone publishes in 
RDFa (or RDF/XML) and a helper service periodically converts and reposts 
(via OAuth/AtomPub) the derrived data back to the site. Perhaps after 
doing a bit of OWL reasoning, identity reasoning (smushing) etc.


> Depends on how you squint at it. Technically speaking, a graph, as a 
> mathematical entity, is a fixed, immutable thing. An information 
> resource, on the other hand, can (and often does) vary over time. That 
> is, tomorrow it might have a different representation than today.

Not sure I'd even go that far. RDF formally has very little to say about 
changes over time. It's like trying to talk to residents of 
http://en.wikipedia.org/wiki/Flatland about the mythical 3rd dimension. 
Of course RDF-based information systems do need this notion; hence 
various graph and named graph constructs.

> One could say that, in the case where we look at the Web through RDF 
> goggles, the concrete representation that we get back at any time from 
> an information resource is an RDF graph. The information resource itself 
> is not an RDF graph, but rather a function that returns an RDF graph.
> 
> Now, if we ignore time and pretend that we just deal with a static, 
> frozen-in-time snapshot of the Web, then it's probably okay to pretend 
> that information resources are RDF graphs (because the function is 
> constant). This is what the RDF browsers out there do in practice, they 
> treat the Web as a set of named graphs, where the URIs of RDF documents 
> are the graph names.

Yup. When the world stops moving, we can use RDF to describe it. And we 
can use RDF to manage the descriptions of the world from different 
points in time and perspectives too. And we can sometimes flatten these 
diverse descriptions into a single one. Throughout all of this the word 
'graph' gets bandied about in slightly different ways, which can make it 
very confusing. In parallel, the notion of 'Document' also kinda melts 
between our fingers when we try to pin it down (the FRBR work is this 
communities best narrative for what's going on there, I think).



>> but we have chosen to ignore that in the RDF architecture; it's
>> not possible to say 'this graph was published by', in RDF/XML, i.e.,
>> to talk about the information resource itself, because you will always
>> be talking about whatever the RDF/XML itself is about.
> 
> Huh? Of course it is possible to talk about information resources in 
> RDF. Assume that this is the content of an RDF document published at 
> http://example.com/my_rdf_document.rdf :
> 
> <rdf:Description rdf:about="http://example.com/my_rdf_document.rdf">
>     <dc:publisher>Richard</dc:publisher>
>     <dc:date>2008-07-14</dc:date>
>     ...
> </rdf:Description>
> 
> This is an RDF document talking about itself. This is standard practice, 
> you can find examples like this in the RDF spec, and everywhere in the 
> wild.

Yup. It might be clearer if the .rdf on the URI was missing and the 
thing was conneg'd HTML vs XHTML/RDFa vs RDF/XML etc. dc:publisher is 
stretchy enough to work in either case.

> (Note that in the example, I could have used rdf:about="", because an 
> empty URI is expanded to the URI of the document.)

Yup. Again a common idiom.

Note that some such styles do work better when it's a distinct 
bag-of-bits that's being talked about. For example the wot:assurance 
construct,
http://web.archive.org/web/20070814001334/http://usefulinc.com/foaf/signingFoafFiles
http://xmlns.com/wot/0.1/ etc
...
I used to use this to sign the FOAF spec RDF, but it got a bit confusing 
  when trying to also use conneg.

cheers,

Dan

>> But there is no reason that we could not enable this, and if we wanted
>> to go this route, RDFa+HTML allows it.
> 
> It's equally possible in RDFa and RDF/XML, today.
> 
> Best,
> Richard
> 
> 
>>
>>
>> Regards,
>>
>> Mark
>>
>> -- 
>> Mark Birbeck, webBackplane
>>
>> mark.birbeck@webBackplane.com
>>
>> http://webBackplane.com/mark-birbeck
>>
>> webBackplane is a trading name of Backplane Ltd. (company number
>> 05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
>> London, EC2A 4RR)
>>
> 
>

Received on Monday, 14 July 2008 15:51:11 UTC