W3C home > Mailing lists > Public > public-lod@w3.org > July 2008

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

From: Tom Heath <Tom.Heath@talis.com>
Date: Mon, 14 Jul 2008 19:18:19 +0100
Message-ID: <DD5E887552496241BC701548837A282F0703C572@nemo.talis.local>
To: "Richard Cyganiak" <richard@cyganiak.de>, "Mark Birbeck" <mark.birbeck@webbackplane.com>
Cc: <public-lod@w3.org>, <semantic-web@w3.org>

Hi all,

> -----Original Message-----
> From: Richard Cyganiak [mailto:richard@cyganiak.de] 
> Sent: 14 July 2008 11:15
> To: Mark Birbeck
> Cc: Tom Heath; Kingsley Idehen; public-lod@w3.org; semantic-web@w3.org
> Subject: Re: RDFa + RDF/XML Considered Harmful? (was RE: 
> Ordnance Survey data as Linked Data)
> 
> 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.
> 
> 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.

Mark, before the claim is completely withdrawn I can't help but add my
2p worth... ;) I've got to agree broadly that there are some compelling
usage scenarios for RDFa, but lets not fall into the trap of assuming
that RDFa is easy and that RDF/XML is hard. Hugh's scenario, or a RDB
with D2R server, are nice examples of where simply pumping out RDF/XML
is nice and straightforward.

As always it's a case of the right tool for the right job. Regarding
your other (admittedly unfounded) claim, there may be many more people
who end up publishing RDF as RDFa, but collectively they may end up
publishing far fewer triples in total than a small number of publishers
with very large data sets who choose to use RDF/XML to expose data from
backend DBs.

> > 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 also forgot to mention obvous use of RDFa in the HTML doc which 
> >>> broadens the range of rdf aware user agents tha commence RDF 
> >>> discovery from HTML
> >
> >> Does it not
> >> also complicate the picture of making provenance statements using 
> >> named graphs, if the subject of the triple could be both an HTML 
> >> document and an RDF graph?
> >
> > Is it possible to distinguish a graph URI? I hadn't 
> realised that. It 
> > would certainly be a good idea to  have an rdf:Graph type, but I 
> > hadn't realised that there was one.
> 
> There is no rdf:Graph type, and Tom didn't say there is one. 
> Tom used the words "RDF document" and "RDF graph" 
> synonymously, which is a bit sloppy.

Cough. Not strictly true, Richard, although you interpreted my meaning
correctly; RDF document would have been a better term to use.

What I was getting at in my original message was the question of whether
there are different statements we might wish to make about an HTML-only
document compared to a straight RDF/XML document.

I don't know if this is the case or not, although OTTOMH I can imagine
an app where people rate the accessibility of documents on the Web;
these kind of ratings could have vastly different meaning depending on
whether the consumer consumed the document using an HTML browser, an RDF
browser, or some kind of hybrid.

As I say, I don't know if this is really an issue or not...

<snip/>

Tom.
Received on Monday, 14 July 2008 18:19:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:20:40 UTC