RE: RDF: XULing or Grueling

> -----Original Message-----
> From: public-sweo-ig-request@w3.org 
> [mailto:public-sweo-ig-request@w3.org] On Behalf Of Bijan Parsia

 I've heard the 
> network effect argument for *years*. The flipside of the 
> network effect is that *most* things can succeed if everyone 
> is using it, however crappy. 

I don't have much in the way of counter-examples to back this up, but I
suspect this is something we take for granted that the Web quietly gets
right (by hitting various technical/social sweet spots). One reason we
don't see the same diversity of applications build on email protocols
could be that the too-crappy-to-succeed threshold is much lower. Such
things never get to the self-sustaining point of everyone using them.

People have *always* been doing 
> big dumps of data into RDF (DMoz; musicbrainz; TAP; 
> WorldBook, etc.). 

True, but I'd suggest that the treatment of these dumps as true (linked)
web data rather than just dumps in an arbitrary data model/format is a
relatively recent phenomenon. It's another chicken & egg thing. While
danbri's (I think it was his) linked data representation of WordNet was
online years back, without data-oriented web-aware client tools it
didn't benefit from the network effect in the data domain.

> > In addition, the RDF/XML serialization and RDF Data Model 
> separation 
> > didn't help either.
> 
> I dealt with a bit of this in my reply to Harry, but I'll 
> also point out that I've encounter loads of people who don't 
> like the model. For many purposes, I'm one of them. I think 
> both of the critical XUL reflections were critical *of the 
> RDF model* (esp. Hyatt who didn't care for the graphs at all).

While I have serious doubts about certain aspects (yeah, RDF reification
mostly), having a graph-oriented data model for the web seems a
no-brainer. But that isn't to say that other models can't be more
effective locally.

> Perhaps. I didn't find it to have a decent end user 
> interface. 
...
> Being able to exhibit data from Wikipedia is, indeed, useful to me.  
> But this is more interface than anything else.

I don't disagree, but breaking open the silos (connecting them with
broader pipes than HTML) provides a much richer back end on which to
build user interfaces. We definitely also need to work on the interfaces
to expose this.

> This is a bit of a tangent from my original purpose which is 
> to figure out what went wrong with some major RDF projects 
> and, eventually, to have some sort of sane decision tree for 
> when or when not to use RDF.

I'm not sure RDF/not-RDF is quite the right question. I wish I could
express this better, but the utility of RDF comes from its role in
globally-resolvable resource description and web-connectivity rather
than its 'RDFness'. 

As a substrate language RDF can be applied to pretty much all the data
we deal with. A bunch of interlinked HTML documents can be viewed as RDF
with a generic link predicate associating untyped resources. In-document
XML trees or similar structures can be grounded with URIs. OO objects
can usually be projected (lossily) into richer RDF. Data in a relational
DB can be (often lossily) fragmented down into triples. Etc etc. But
there's nothing inherent in RDF itself that means data expressed in it
will be more useful. (While most other representations have the inherent
obstacle of not having a already-deployed system for global keys).

Ok, experience tells us RDF can often be inconvenient or just plain
unpalatable. But assuming that RDF is potentially available from any
other data representation, this isn't a problem - anyone that wants it
can have it. The question becomes more how we can maximise the benefits
of resource description and web connectivity. 

As an example, take microformats. A cheap and cheerful way of decorating
HTML with explicit data. But as generally practiced, the
entity/relations of the data are identified using special short strings
("vcal", "fn" etc). Microformats.org acts as a kind of registry ("vcal"
marks a container for markup using the hCalendar conventions, "fn" is
the name of something...). This is reasonable resource description, but
falls short in web terms. To expand the utility of this data, what's
needed is the binding of the terms to URIs. HTML already has a perfectly
good mechanism, meta data profiles. But the problem is in getting people
to use them - unless you're a confirmed RDF fan the potential benefit
isn't obvious. In this kind of situation probably the only way forward
is to make the benefits visible - the "showing not telling" angle.

I guess what I'm trying to say is that while putting a lot of effort
into promoting RDF (and other Semantic Web technologies), we [the
enthusiasts] perhaps forgot about promoting the Web. SWEO is chartered
with an emphasise on semweb tech, so in that context I'd suggest a
plausible strategy might be instead of encouraging "More RDF", rather
encouraging (and demonstrating) "More Useful RDF".

Cheers,
Danny.

Received on Monday, 8 October 2007 09:35:49 UTC