Re: [RDFa] ISSUE-28: following your nose to the RDFa specification

Keith,

I think you've become a little too GRDDL focused. You seem to imply that
we should *never* have a single consistent syntax for RDF-in-HTML, that
we should always allow any attribute to mean anything. That's a terrible
thing. That means no copy-and-paste, ever. No self-containment. Unlikely
to be able to correlate region of screen to related metadata.

RDFa is trying to be a consistent syntax that always means the same
thing yet is flexible enough to allow any vocabulary. What's the driving
principle behind your approach? Why *should* an attribute mean different
things from one document to another? What's the advantage? Flexibility
of vocabularies is, of course, important, but flexibility of syntax is
not an inherent advantage.

> I asked this question in another thread, but didn't really get an
> answer: what is the disadvantage in aligning RDFa completely with GRDDL ?

Well, the first thing I would say is: what's the advantage? I don't see
an advantage, but I see plenty of disadvantages. The main disadvantage
is exactly what GRDDL leads you to think later in this same email:

> GRDDL ought to enable me to define my own RDF-in-HTML syntax based
> on, or incorporating parts of, RDFa.

So you want to use the RDFa attributes but have them mean different
things depending on what the publisher feels like? That's bad. We're
trying to standardize how people express things so that it becomes a
little bit easier to parse. Hijacking RDFa-specific attributes with
different rules... ouch, you just made my brain hurt.

That's the disadvantage of aligning RDFa with GRDDL. It implies that the
syntax is loose and authors can do whatever they want. That's terrible
for toolbuilders and interoperability. And it significantly hurts the
design principles of RDFa.

> If you don't let authors say "this
> is not RDFa" you shut down options and risk confusion about exactly what
> triples should be generated from documents.

Don't use the XHTML1.1+RDFa DTD! We didn't build RDFa to throw in a few
extra attributes so they could be used willy-nilly. That would be a
shockingly bad reason for a W3C WG. We built RDFa to let you express
RDF-in-HTML.

Do we want RDFa-specific attributes to always imply RDFa? Absolutely. I
think that's a good thing.

> In my opinion this would
> hamper innovation, reliability, and the usefulness of RDF-in-HTML in
> general.

I really don't understand this. Innovation doesn't happen at the syntax
level, it happens at the semantic level. We have a goal of standardizing
the syntax for expressing metadata while freeing the semantics thanks to
RDF. We think a standard syntax is a very good thing, for all of the
principles we've defined: self-containment (copy-and-paste), locality,
etc... and now you'd like us to build something that weakens these
principles significantly?

I'm about as opposed to this as I've been to anything :)

>> XHTML. So you'd need an author to add one or more of @about, @content,
>> @datatype, or @property. I've not come across anyone doing this so
>> far, and believe it to be very unlikely. I'm not ruling it out, I'm
>> just saying that given the way most HTML/XHTML authors currently work,
>> it is an order of magnitude less likely than overloading @class
>> values. And as RDFa becomes more well known, the chances of such false
>> positives *decrease*. (Since it's less likely that someone devising
>> their own language based on HTML would re-use these attributes.)
> 
> This is basically the same argument that microformats use isn't it?
> Choose some obscure strings to squat, and raise awareness that you are
> squatting on them?

Not really, no. RDFa is one syntax, it always means the same thing. Yes,
we are trying to make it such that, when someone uses that syntax, they
mean RDFa. Would we prefer it if everyone used the RDFa DTD? Of course,
but since we are only "squatting" on 5 attributes that will never
change, we think it's okay if parsers promiscuously pick those up
without the DTD.

Let's take a step back here and look at what you're asking toolbuilders
to do. I claim that what you are proposing is more like microformats.
You want no consistent syntax, you'd rather make up a syntax for every
application domain. That makes for very low interoperability.

The rule of interoperability is strictness in what you produce, and
flexibility in what you consume. So let's not make production even less
consistent, right?

> Can you tell me about XHTML 2 and RDFa? XHTML 2 has those attributes
> built in doesn't it? So presumably won't need a different DOCTYPE? How,
> if at all, can an author use XHTML 2 without implying RDFa?

XHTML2 includes the RDFa specification. If you use the RDFa attributes
in XHTML2, you mean RDFa. Just like when you say rel="next" in HTML4,
you mean that it's the next page in the sequence. This is a good thing,
not a bad thing. If there's already a syntax to express RDF-in-HTML, I
cannot see the advantage of a second syntax to do exactly the same
thing. The disadvantages, however, are huge, as I've mentioned before.

> I think if you really want to limit the possibilities of GRDDL, you need
> to at least be clear and up front about it so that GRDDL (and XHTML 2)
> authors are aware they need to avoid using RDFa-like syntax.

You need to take a step back: HTML came before GRDDL. HTML came with
some built-in semantics. GRDDL can never change those built-in
semantics. Not even Danny Ayers's bogus profile. rel=next means
something according to the HTML spec.

In XHTML2, if you use about, property, etc..., you mean RDFa. Can you
use GRDDL to mean something else, too? If you really want to, but you
still mean RDFa.

> pps: Ben, does using hGRDDL imply "this is not RDFa", or only that the
> result of the transformation will be RDFa? (I wonder, could you use
> GRDDL on RDF/XML to generate, eg, reified RDF/XML ?)

hGRDDL is not built into GRDDL, sadly, so I think your GRDDL approach
makes things much worse.

Again, I see flexibility of syntax as a serious downside. You need to
justify this need for flexibility. Why is it useful? GRDDL was built not
because people wanted lots of different syntaxes, but because people
were forced to build their own syntaxes, and it was time to find a way
to extract semantics.

So yes, we seek a syntax that is consistent, that always means the same
thing, and that imposes on HTML as little as possible. That's not
compatible with a GRDDL-centric approach, exactly because it's leading
you (and likely others) to think that the attributes can be safely
reused to mean other things and to *negate* RDFa. That would be a very
bad thing.

-Ben

Received on Sunday, 1 July 2007 22:29:07 UTC