[whatwg] RDFa

Henri Sivonen wrote:
> When you do so, please consider the HTML Design Principles from the W3C
> side (particularly the one about DOM Consistency between HTML5 and XHTML5):
> http://www.w3.org/TR/html-design-principles/#dom-consistency

Sure. And since we're only adding attributes, I don't see how DOM
consistency is going to be an issue.

> The problem is that communities seldom resign to being happy on their
> own. They often start propagating their happiness onto others, at which
> point it would be better for the syntax for happiness not to be crufty
> to begin with.

I see you're resorting to subjective name calling. Not exactly relevant
to a technical discussion, nor do you have any proposals for "fixing"
said cruftiness that wouldn't also fall short of the goal we've
described in the ccREL paper.

>> That doesn't scale (unless you expect people to actually use GUIDs with
>> timestamps), and it's extremely web-unfriendly, since you can't look up
>> a concept to figure out what it might mean.
> 
> It seems to scale for the Java community, and looking stuff up works.

You mean, looking stuff up in your local CLASSPATH directory? How is
that like the web?

More importantly, even in Java local CLASSPATH traversal, you still have
a standardized method for de-referencing the pointer, looking into the
Class object, and determining all sorts of metadata about it. How does
that translate to the web? It only does if you use URIs.

> FWIW, I think that's a requirement-level bug. The PDF should talk for
> itself.

I've explained in other emails why this is unrealistic, and why that
wouldn't solve the entire problem anyways.

>> Well, we can discuss that part.
> 
> Previously, you said that it was too late to change RDFa, though.

No, I said it is too late to change RDFa-in-XHTML1.1 v1.0, and I've
explained that changing attributes like @property would be gratuitous
and only impose needless incompatibility.

I have suggested that adding another way to do prefix mappings (other
than xmlns), might be worth considering.

> Adding Namespaces to HTML is much, much bigger a deal than adding a few
> attributes in no namespace.

It's not "Namespaces." It's "namespaces." And adding the ubiquitous
computer-science concept of "namespaces" should not be a big deal at all.

> Whether they are called CURIEs or qname-in-content is unimportant. They
> come with the same problems.

No they do not. For example, no need for backwards-compatible
constraints. And we have the possibility (under consideration), of
expressing bindings only in attribute values.

> The indirection
> would still likely confuse authors as much as Namespaces confuse them.

You keep switching your model. You want PDFs to be marked up, and you
think authors will do that by hand and not be confused? No, right? But
in the case of RDFa you keep coming back to authors being confused by
the indirection.

I think the indirection is a *lot* less confusing than twiddling some
PDF-embedded RDF/XML. And we have better tools already.

> Many videos consistently from a founder--not some random CC fan. Also,
> I'm still not talking about the license of the *video*. I'm talking
> about the licenses of the *photos* remixed into the video.

That would be a fair criticism. If you think we're not citing properly,
please send us links to the videos where we're not doing a good job. We
all make mistakes.

> Also, I gather that the videos are captured with something like Snapz
> Pro X--not exported directly from Keynote. The "tools will save us"
> vision

You're putting words in my mouth. I didn't say "the tools will save us."
I said "the tools will help us, but they're not required."

And again you're making a point that, in some cases, the tools won't be
100% helpful. So what? We should refuse to adopt a solution because it
won't solve *all* of our problems?

> So tools for existing metadata schemes aren't there. I think RDFa isn't
> something that "the average user" can understand, either. Do you expect
> tools will emerge for *this* metadata scheme?

They are already there.

Go to http://creativecommons.org/license/, fill out the form, get your
chunk of HTML+RDFa, go paste it in your MySpace or blog entry, and
you're done.

People do this every day. It works relatively well.

> Why can't machines pick key-value pairs from the document information
> dictionary? Why is an RDF graph needed?

Read the ccREL paper about vocabulary modularity and extensibility to
future data types.

> Actually, it's relevant to the extent the "requires"/"permits" part of
> ccREL is supposed to work. (HTML5 shouldn't include stuff that doesn't
> work.)

You're making a false argument:

1) requires/permits works

2) even if it didn't, it would be a vocabulary problem, not a problem
with RDFa.

> Happi*er*, yes, but I think having the layer of prefix-based binding to
> URI is a design bug regardless of syntax. But yes, having a non-xmlns
> binding for *both* HTML5 and XHTML5 would make things less bad than
> using xmlns.

Good to know, thanks.

-Ben

Received on Saturday, 23 August 2008 14:15:00 UTC