W3C home > Mailing lists > Public > public-swd-wg@w3.org > February 2008

Re: [Fwd: Re: Best Practices Issue: RDF Format Discovery]

From: Sean B. Palmer <sean@miscoranda.com>
Date: Thu, 7 Feb 2008 11:30:16 +0000
Message-ID: <b6bb4d890802070330j1d493ca0pc8b917b91c25f6cb@mail.gmail.com>
To: "Ben Adida" <ben@adida.net>
Cc: public-swd-wg@w3.org

On Feb 6, 2008 8:22 PM, Ben Adida <ben@adida.net> wrote:

> This is a response to your comment from November 22nd [1]
> as it pertains to RDFa.

Thanks. I have some comments above this below, prefaced with a bit of
a philosophical interlude that'll explain where I'm coming from.

Tim's got this great slide that explains that whereas the Web
connected web pages (technically we call these "information
resources") and mailboxes and boring things like that, the Semantic
Web extends that naturally to connect together people and
organisations and events and so on:

http://www.w3.org/2001/sw/grddl-wg/tut7/images/semantic.jpg
(That's not the one, but close enough.)

"The power of the web was still not totally used to its full potential
until the semantic web came along. The Semantic Web's realization is:
*It is isn't the documents which are actually interesting, it is the
things they are about!*" - http://www.w3.org/DesignIssues/Abstractions

But I realised something about this:

Though the Semantic Web connects all these *non* information resources
together, we're always going to be working with them on the computer.
The Semantic Web can represent a person, but it can't actually give me
that person, obviously. It can tell me their name, their homepage, all
of their properties, and it does this by showing me pictures, a link,
a web page, other multimedia, widgets.

All of these things are based on the computer, so we're kinda back to
square one again: back with those information resources.

What RDFa does, or could do, is to concentrate on the link between our
web pages and all of these concepts that the Semantic Web enables us
to talk about. This is why I'm warming to RDFa. My comments on the
specific issue of follow-your-nose link back to this point.

> For example, XHTML2 will include RDFa by default

At the moment I'm much more concerned with HTML 5 than either XHTML
1.1 + RDFa or XHTML 2. There seems to be a lot more momentum behind
the former than those latter two, even if in charter land they're all
equals.

I don't want to go into this too much, but it seems like XHTML 2 might
be a bit like W3C XML Schema and HTML 5 is more like RELAX NG. Though
their remits are different, the amount of use that they see, and their
importance to developers such as me, are going to be quite different
as a result.

If you want RDFa adoption to be as wide as possible, which we do from
a Semantic Web basis, the RDFa Task Force is going to have to think
about that, apolitically and perhaps even acharterally.

> We hope that HTML5 will at least provide a standard extension
> mechanism for components like RDFa

Yes, this is of some concern to me recently.

What if the HTML 5 (generic) extension mechanism is only available in
XHTML5 (xml) and not HTML 5 (non-xml)? Will that be acceptable? (No?)
Will it violate the HTML WG's charter? (No?)

> Or, they may find that RDFa is useful enough to include as part of
> their baseline specification

Maybe. Are the HTML WG aware of RDFa? More to the point: is it on
Hixie's fabled radar? There's a long way to go with it yet, so no need
to flip the panic switch, but I think it's worth getting in there at
an early stage. At the moment, HTML5's metadata facilities are
underwrought.

> In addition to this doctype-based inclusion

(See again my point about evolution and adoption.)

> our specification *recommends* that HTML+RDFa documents
> include a @profile reference to the RDFa profile URI [2]

Okay, excellent. Does it also recommend that user agents only conneg
between HTML versions and RDF versions if the @profile attribute is
available? Perhaps that's the best way forward.

Your response indicates that you haven't yet absorbed my comment about
*document* requirements vs. *user agent* requirements. What you're
telling me is what document authors should do. They should put an
@profile in their documents. Great, fine. But what should user agent
authors do?

My big contention has been that it's too much of a burden for Generic
Semantic Web Agents to have to parse an entire HTML document to
discover whether it contains metadata or not. I'm thinking now that
what I really meant to say is whether one should be able to "conneg",
in a sense, between the documents.

Are you aware of the Tabulator RDF browser?

http://www.w3.org/2005/ajar/tab

That's the kind of thing I've been working on. When you browse the web
with it, as a Firefox extension, it either shows you a normal web
page, or if it finds RDF then it shows you a special RDF view.

In the case of an RDFa document, what should it do? Perhaps it should
only show the RDF view if the @profile is present. On the other hand,
I dunno where this leaves HTML 5, which doesn't even have an @profile
attribute.

> This aggressive parsing can serve to bootstrap our future ideal
> world where HTML+RDFa can be freely copied and pasted.

*My* "future ideal world" doesn't have HTML or RDF at all... :-)

> Since the RDFa attributes are unique enough and fully backwards-
> compatible with existing HTML, it is extremely unlikely that someone
> would write RDFa they did not mean "by mistake."

No, it's impossible. I think you're underselling your argument. Are
you saying that non-W3C people can arbitrarily squat attributes in the
per-element namespace partition? I really don't think they can.

The issue isn't about this.

> In the end, we hope that RDFa will become a standard syntax
> for embedding RDF in HTML

Well you've only got to get to REC. Perhaps you're talking about
popular adoption, then; and I hope that you heed my comments about
that.

> [2] http://www.w3.org/ns/rdfa

Excellent choice of URI; thanks for stating it!

And thanks for the response.

-- 
Sean B. Palmer, http://inamidst.com/sbp/
Received on Thursday, 7 February 2008 11:30:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:31:48 UTC