[
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
matter.
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
identifier.
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?
Shelley
|
