[whatwg] Ghosts from the past and the semantic Web

Henri Sivonen wrote:
> Isn't the whole point of splitting URIs into two and introducing syntax
> into later putting the part back together that the length of the URI
> gets amortized when the same prefix is used many times even though in
> the case of a single occurrence, the indirection syntax actually makes
> things *longer*?

Yes, a tiny bit longer when there's only one property, and for that we
gain a nice feature, which is that we don't have to disambiguate between
full URIs and CURIEs all the time.

> Putting the prefix declaration and the CURIE on the
> same element to make then travel together when copied and pasted seems
> the defeat the entire point of CURIEs.

It's very tough to have a productive discussion with you when you
nitpick different details of specific examples, rather than seeing the
general design which *enables* these different examples.

The point is you have to find a balance on where you put the prefix
declarations. But it's not black or white, as you seem to imply. It's
not "on the root" or "on the specific element."

And at the end of the day, it's up to the publisher! That's the whole
idea. If you know what you're doing, you'll put the prefix on the right
element and you'll move it around as you add more RDFa. If you don't
know what you're doing, you'll probably just copy and paste the HTML
Creative Commons gives you into your page, and you won't add any more
RDFa to it.

So the problem you speak of actually doesn't really exist.

> This would be more robust under copy and paste:
> 
> <a rel="license"
>   href="http://creativecommons.org/licenses/by-sa/3.0/us/">
> <img alt="Creative Commons License" style="border-width:0"
>  src="http://i.creativecommons.org/l/by-sa/3.0/us/88x31.png" />
> </a>
> <br />
> <span
>      property="http://purl.org/dc/elements/1.1/title">
>  HTML5 Example
> </span>
> by
> <a href="http://ben.adida.net"
> property="http://creativecommons.org/ns#attributionName"
> rel="http://creativecommons.org/ns#attributionURL">Ben Adida</a> is
> licensed under a
> <a rel="license"
>   href="http://creativecommons.org/licenses/by-sa/3.0/us/">
>  Creative Commons Attribution-Share Alike 3.0 United States License
> </a>.

And highly repetitive. Someone (was it you?) said that writing out full
URIs is a pain, and it's also error-prone.

> This would be more HTML-like:
> 
> <a rel="license"
>   href="http://creativecommons.org/licenses/by-sa/3.0/us/">
> <img alt="Creative Commons License" style="border-width:0"
>  src="http://i.creativecommons.org/l/by-sa/3.0/us/88x31.png" />
> </a>
> <br>
> <span
>      property="title">
>  HTML5 Example
> </span>
> by
> <a href="http://ben.adida.net"
> property="cc-attribution-name" rel="cc-attribution-url">Ben Adida</a> is
> licensed under a
> <a rel="license"
>   href="http://creativecommons.org/licenses/by-sa/3.0/us/">
>  Creative Commons Attribution-Share Alike 3.0 (United States) License
> </a>.

And completely unscalable to the Web, because I have no idea what
cc-attribution-name is unless there is a *central* registry somewhere,
the way Microformats are forced to do things.

Pretty poor design, from the POV of the Web.

> SQL in browser is different from RDFa. When at least two out of Gecko,
> WebKit, Opera, IE and Gears teams are determined to ship a feature,
> Hixie can't stop them, but Hixie can step in and steer them to do what
> they are determined to do in such a way that the implementations
> interoperate. In this case, at least two (three?) out of those five
> indicated that they were going to expose SQLite to JavaScript.

So what you're saying is, priority is given to features that the browser
vendors want... and for some reason to Gears, which I guess gets special
status because it's Google. That's a bit odd given that Gears is a
browser add-on that "the bulk of users" will not know how to install.

The problem with this approach, and it's my general issue with how the
WHATWG sees the world, is that browser vendors have a very twisted view
of the world. Web publishers, like myself, also have a very twisted view
of the world, of course, though twisted in a different way.

So, how do publishers get some pull with WHATWG? Browser vendors just
implement their features, validation and specs be damned. But publishers
can't do that, because we need to convince other publishers, and we
don't control the tools, and we don't control validation.... so we're
stuck until some browser vendor sees the light, which inherently rules
out the more loosely coupled data solutions we've been talking about.

Shouldn't a standards organization like WHATWG look beyond just the
browser vendors? Isn't it a bit narrow-minded to focus on just them?
Isn't that what a standards group is supposed to do? Or is WHATWG's goal
to just have the browser vendors talk amongst themselves?

WHATWG should see something like Ubiquity, or SearchMonkey, and realize
"here are some applications that are surprisingly different from
existing browsers, let's make sure we enable them, too, with a Web-scale
architecture."

-Ben

Received on Friday, 29 August 2008 10:04:57 UTC