OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] RDF for unstructured databases, RDF for axiomaticsystems

[ Lists Home | Date Index | Thread Index ]

>>Tim Bray's RPV could be turned into a straightforward XML version of
>>N3. It look like that is the way RDF is going -- I'd bet that the current
>>RDF/XML gets deprecated at some point.
>No argument there.

I think you're all focusing on the syntax when the issue really is 
the model. If we were to create an example RDF document using Tim's 
quickly put together demonstration (note that Tim only put RPV 
together in an evening and only meant it as a demonstration, see 
http://weblog.burningbird.net/fires/000661.htm#comment3032) XML and 
the existing RDF/XML and bring in a naive user, the person would have 
just as much problem with Tim's syntax as he or she would with 
RDF/XML. The reason? Both require pre-knowledge of the RDF model, and 
no simplification of the syntax will allow one to avoid this -- 
unless you cut out essential aspects of the model.

In a comment at my web site, l.m. Orchard commented in reply to 
another comment about the difficulty of modifying a FOAF file:

'Okay, I took a peek at your FOAF profile, did the "view source" 
thing. It looks quite straightforward to me, and I can't imagine how 
adding that kind of metadata to my own as-yet-untouched FOAF file 
would be painful at all. In fact, my first impression of your FOAF 
file is along the lines of - this is what all the fuss is about?!'

(at http://weblog.burningbird.net/fires/000661.htm#comment3043)

Good question. My answer was:

'Leslie, since I'm one that doesn't find RDF/XML to be painful, I'm a 
_bad_ one to respond -- I'm one of the converted, so to speak. 
However, I think in some ways you've touched on the heart of the 

Most aspects of the RDF model when serialized to RDF/XML are very 
straight forward, very easy to both read and write. For instance, DC 
(Dublin Core) is very very uncomplicated, being nothing more than a 
resource with several properties attached, similiar to what you saw 
in Mark's FOAF.

However, speaking of FOAF, I remember that the problem the weblogging 
community had with it was the fact that no 'identifier' was given for 
the person -- it is what is known as a 'b node', or blank node. With 
bnodes, when the statements are processed with rdflib (or whatever), 
a machine-generated identifier is given instead; when people tried to 
re-capture the information, the identifier would be different, and 
multiple instances would be captured rather than just the 
modifications or new data for the first instance.

I access Mark's FOAF file one day, and have a resource id of 
"KJKJ41", and the next day when I go back to look for changes, the 
resource id is read in as "JJKHKH" -- my system would think I'm 
reading in two separate instances rather than the same instance with 
different resource identifiers. One has to have pre-knowledge of 
bNodes, and account for this when processing an RDF model. One way to 
account for this is to do what Mark did -- create a 'dummy' resource 

I imagine this was one of the painful things, though Mark will have to confirm.

The thing, though, is that this was more a matter of understanding 
how RDF works then the actual syntax. In the case of FOAF, a bnode is 
used because a resource identifier is considered irrelevant for this 
resource. When processing the data, one has to take this into 
account. This has nothing to do with the syntax, and everything to do 
with the model.

I think, in many ways, that's what many of the objectors have against 
RDF/XML -- you have to have some pre-knowledge of RDF in order to 
read it, write it, work with it, and truly understand it.

Unlike straight XML, which is a meta-language, RDF is a model of 
meta-data, truly a different beastie, and as such will always require 
some pre-knowledge in order to manually read, write, or even program 
it. Trying to work directly with RDF/XML -- in whatever format anyone 
could possibly want -- without having some basics of RDF will trip a 
person up. No way around this.

It's equivalent to going into a relational database and typing 
"select field1, field2 from a, b".

No matter how 'simplified' an XML we discover, we'll still have to 
have pre-knowledge of the model. To be honest, we have to have 
pre-knowledge of XML in order to read or write it, but so many of us 
have worked with it for so long, we've forgotten this fact.

There are other objections to RDF/XML (such as the whole 
URI/namespace/Qname thing), but in the case of FOAF, this is the one 
I particularly remembered. '

No matter how much we "simplify" the XML, we'll still need to 
understand the RDF model in order to effectively read it, write it, 
or work with it. And this will always prevent people from coming in 
and just working with it straight out of the box.

So then the question becomes: Is the issue really about the existing 
RDF/XML? Or is it about the complexity of the RDF model? I think we 
need to be very sure about this before we run off into alternative 
syntax tangents.

BTW, to digress: my interest in RDF has to do with its meta-data 
capabilities -- to my way of thinking, its equivalence to the 
relational data model but for XML  -- and the associated 
technologies; not inferences, not axioms, and not semantic web. I 
guess this makes me hopelessly pragmatic. However, it is, as Jonathan 
stated, these same inferences that provides a model that is 
consistent and reliable, just as it is the equivalent inferences in 
the relational model that allows one to trust it. Can one simplify 
the RDBMS? Not and be willing to put credit card info into it. How, 
then, can one simplify RDF?



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS