[BIF] BIF language (RDF or XML?)

Mon May 1 14:11:24 CDT 2006

Heh, I just typed the stuff below and realised I'd forgotted what
point I was trying to make...I guess it is that although IMHO the
format is secondary to the data it represents, it's still something
that needs a bit of thought, in particular how best to increase the
chances of widespread adoption.

> On 5/1/06, Alf Eaton <lists at hubmed.org > wrote:
>> I'm not necessarily recommending using RDF for a general interchange
>> format, as it's much harder to parse (you can't just use regular
>> expressions or XSLT/XPath, for example), but if the data model of a
>> bookmark interchange format could map easily to RDF that would be nice.

On 5/1/06, Rob Gonzalez <rob.gonzalez at gmail.com> wrote:
> I think that RDF is a very flexible data
> interchange format and would allow us to create a much more flexible and
> extensible bookmarking vocabulary than we would be able to using something
> like XML.

Personally I'd be perfectly happy with RDF/XML, but as Alf suggests
in_the_general_case it is harder to parse than most XML. There is a
strong possibility that by using general RDF/XML that many potential
adopters would be put off - the ones that have XML toolkits (and
expertise) without RDF support.

However, the situation is better than it may sound, there are at least
two places in the middle ground:

1. Constrained RDF/XML : if a subset of RDF/XML is used, then it *can*
be parsed as easily as any other XML format. RDF tools can still parse
it directly, but when serialising some extra effort will be needed to
ensure the output matches the constraints. DOAP is a good example of
this approach.

2. GRDDLable XML : if the format is associated with a standard
mapping, and documents can easily be identified as being in the
bookmark format, then RDF interpretation can take place automatically.
Microformats are the leading example of this approach.

For a new format, it's hard to think of a good reason *not* to allow
the data to be directly parseable as RDF/XML. If direct XML parsing is
needed, then the first approach here will allow it. The rationale is
put well here:
[[
Making your documents more "RDF-friendly" -- that is, more easily
digestible by RDF applications -- broadens the range of applications
that can use your documents, thereby increasing their value.
]]
http://www.xml.com/pub/a/2002/10/30/rdf-friendly.html

Having said that, where existing formats are involved the second
option is likely to be easier. With microformats, the target audience
are already authoring web pages in HTML, so for them to include
explicit data in those pages, the extra conventions of are a small
step. Because they're layered on top of HTML, the mime type can't be
used to tell the consumer that data is embedded. But the HTML specs
have a extension point designed especially for this kind of situation
- metadata profiles. If a profile URI is included in the <head> of a
HTML document, following the GRDDL technique the consumer can
automatically extract RDF from the page even if it hasn't encountered
the particular kind of data that's embedded (usually by picking up the
necessary XSLT from the identified profile document).
Frank Manola gave a nice insight into this:
[[
It seems to me that if you have a notation, and a well-defined
transformation from that notation to RDF, then what you've defined is,
whatever else it might be, simply a non-RDF/XML notation for RDF. 
After all, what's RDF/XML?  It's an XML notation with a defined
tranformation from that notation to RDF.  There just happens to be a
W3C spec for it.
]]
http://esw.w3.org/topic/MicroModels

For the RDF developer the need GRDDL is an additional complication,
but several of the RDF APIs already include support - Redland for
pretty much every language, RAP for PHP.

Cheers,
Danny.