[uf-discuss] Re: [microformats-discuss] FYI: two posting about the Semantic Webthe "SynWeb", scraping and microformats

[Danny Ayers]

Apologies to Tantek & all, I'd exit the thread but there's an "I don't
know what you mean." to deal with first.

On 10/25/05, Ian Hickson <ian at hixie.ch> wrote:

> What I was referring to was the "using URIs as keys" part. People don't do
> that today, not knowingly. They bookmark things, they search for things,
> they write companies names followed by the magical incantation ".com".
> They don't know they are using URIs; those are an implementation detail
> which could be replaced without changing the way people use the Web.

I don't disagree with the usability angle - but URIs are part of the
current Web infrastructure. Hide them, sure. But they are very useful
from the development point of view, they are *working* global
names/IDs.

> IMHO in that case you are fixating on something that is incidental.
>
> It's like saying "I'm fed up with sleeping in the rain. It makes sense to
> prevent the rain from falling on my living space. I think the easiest way
> of doing that is to build a roof - by which I mean primarily the adhesive,
> nails.". Of course you can build a roof without nails. You could use
> screws. Equivalently, you could build a coherent Web without URIs. You
> could use GUIDs with a central dispatch server, for instance.

You could. But if you have nails...

> I don't think the URI part (or the RDF part) is relevant to the discussion
> of trying to figure out how to make data on the Web more accessible.

I believe it's crucial - a naming scheme that works globally.

> I disagree that RDF is good at expressing highly interconnected data
> structures. Given a blob of RDF it takes me HOURS to determine what on
> earth it is expressing. In fact I usually have to use an RDF grapher or
> some other computer tool to do it. (Regardless of what serialisation it
> uses, be it XML RDF, n3, RDF/A, or anything else.)
>
> That, IMHO, is why RDF has not been a huge success on the Web.

Ah, ok, there's a difference in perspective here. Good visualization
tools are needed for complex data, period. RDF/XML is ugly from day
one, but once you get multi-domain data mixed together, any format
will look ugly.

> > > Neither of these requirements says anything about the data model,
> > > format, or syntax; those are all quite secondary.
> >
> > Ok, the specifics are secondary, but with current tools you would need
> > some kind of data model to be able to formulate queries. To interoperate
> > with the user a way of managing the presentation will be needed, all
> > arrows point to a markup language.
>
> I don't know what you mean.
>
> The idea is that you can go to a site, and the UA will know how to present
> that data, without any hint from the author.

Ok.

> HTML does this, for instance. You can go to any well-written HTML page and
> without a stylesheet or anything, get readable output.

Ok again, but this is assuming direct author-reader comms. If we want
to maximise the benefit of data on the Web, we're talking about
integration, mash-up, filtering, repurposing, processing,
transformation and regurgitation.

> If you use forms for this, then you haven't exposed the data layer, which
> is what you were asking for. Thus forms don't solve 1 above.

Sorry, all I meant was using forms at the machine-human interface, not
necessarily machine-machine.

> The SPARQL protocol could be an option (I don't see how Atom could do it).
> But that's just half the solution -- you need to be able to present this
> to the user. SPARQL doesn't seem to have a clean way for the UA to
> determine what UI to expose, for instance.

Do a GET with your query parameters to a SPARQL endpoint, you get a
bunch of data back. It'll usually either be RDF/XML (appropriate in
the machine-machine scenario) or in SPARQL's results format - an
almost depressingly dull XML thing. At least in the near future I
anticipate this will be piped through XSLT to something the UA can
work with. A lot of the time this will be HTML.

> (Also, SPARQL seems unbelievably over-engineered.)

Maybe. In my own play I think I've only had need for SELECT (as in
SQL), ORDER BY and LIMIT (to clip & order the results), but will be
probably using FILTER (comparisons, e.g. where ?size>10) in the near
future. I was watching the WG in the early days, and they did get a
flood of use cases, mostly apparently valid. My personal preference
would probably have been for them to just do the bits I just
mentioned, plus simple update and/or appends and delete. But I've been
told that the logic for those is non-trivial/controversial, probably
another charter or two's worth.

> Easier for you, possibly. My mum doesn't want to learn anything about RDF
> models. She just wants to find out if her friend is online or whether the
> bus to get her to the gym leaves at 14:00 or 14:15.

Isn't there someone she can ask?

> Before the servers will provide arbitrary querying, you need to find a way
> for the user experience to improve over what is currently available. (What
> is currently available being specialised search forms per data set, with
> the data not directly available to query.)

Thanks, that is very useful.

I'd better duck out of this thread now before Tantek throws something
heavy at me. But I'm very grateful for you going to the trouble of
arguing these points. It would be fibbing to say you've won me over
much on any of the significant issues, except that you clearly have a
valid viewpoint, and you've given me several insights, and that I
totally appreciate.

Cheers,
Danny.

--

http://dannyayers.com