Lists Home |
Date Index |
Michael Champion wrote:
> On 4/25/05, Bill de hÓra <email@example.com> wrote:
>>. However you could replace the
>>Atom above with RDF1.0 and let the entire feed pass straight through to
>>the RDF aware layer - nothing would break. This kind of flexibility is
>>worth keeping in mind the next time someone here dings RDF because it
>>can't describe Fahrenheit to Celsius conversions. It ain't pretty, but
>>it does have interesting properties, Turing completeness not being among
> I don't doubt that RDF logically could meet the use cases Bosworth was
> talking about, nor do I doubt that XQuery views of diverse data
> sources logically could meet those requirements. The question is
> whether they have those "S" attributes (simplicity, sloppiness,
> standardization, scalability) he asserts are necessary to thrive on
> the Web.
Oh sure, he's said before (more or less) that RDF doesn't have the
characteristics needed for web adoption. That's the world where XML
well-formedness is a nice to have. On the other hand, compared to the
kind of work that goes in relational database designs for enterprises,
RDF graphs counts as slop - I'll try to demonstrate that here.
> I don't really care which "wins" -- something RSS-like or something
> RDF-like -- to become the data format for the Web of Data (if such a
> thing ever exists). Both are at XML-ish. I believe Bosworth's
> analysis enough to bet on RSS, if I had to make a prediction:
> - It has proved simpler to actually use by ordinary mortals
> - The RSS culture and toolset is tolerant of error, ambiguity, and
> other human characteristics
> - RSS people can't agree on a formal standard but it is ubiquitous and
> interoperable in practice
> - Its growth curve indicates that it scales to the Web and leverages
> HTTP nicely.
> I don't think any of these can be said about RDF. Simplicity (for
> users), sloppiness (tolerance of error), and standardization (in the
> sense of ubiquity) are just not among RDF's virtues. I don't know
> about scalability one way or the other, and its relationship with HTTP
> seems a bit rocky.
That depends. Simplicity, sure, but not tolerance of error. RDF-aware
systems are highly tolerant of absent or unexpected data; arguably they
go too far in that respect - it becomes a bit of free for all. To
highlight this, let's look at the stuff that gets pulled out of the Atom
example I sent earlier, and sent to said 'RDF layer':
<event:EventObject rdf:resource="" rdf:type=""/>
It's a much less prim technology that people suggest. The following
scenarios will work:
- send just one of those,
- a thousand of those.
- just the event:* stuff
- just the iam:* stuff
- part of the event:* data
- part of the iam:* data
- new iam:* stuff
- new event:* stuff
- dc:* stuff in either event:* or iams:* or both.
- *:* stuff in either event:* or iams:* or both.
- a FOAF block, every now and then
- RSS1.0 outside the RDF, you can send the lot right through
- logging a software upgrade:
<event:EventObject rdf:resource="urn:XXX" rdf:type=""/>
<doap:Project rdf:about="urn:XXX" rdf:type="urn:hmm...upgrades">
No surprise then to find RDF diehards looking at mU/mI processing
models, concepts like 'foreign markup', or non-optional typing, @rel,
and shaking their heads.