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

Hi Keith,

You've dropped from the thread the most important point I made in my
last email: you implied in your previous email that you wanted the
potential for a profile to *negate* RDFa. From where I stand, I suspect
this even invalidates the way GRDDL works.

Consider a world where XHTML is validated using XML Schema. GRDDL says
that I can have a schema-specified transformation. Now, whatever
@profile says in the instance document, the schema-specified
transformation remains a valid transformation to run. Your
instance-based @profile cannot *negate* the schema-specified
transformation, it can only add another transformation that is also valid.

RDFa is effectively a schema-specified transformation. You can choose to
perform additional transforms if you want (and I'd rather they be hGRDDL
to keep the locality principle), but you cannot *undo* the RDFa
transformation specified in the schema.

Now, if HTML is validated using DTDs... what difference should that
make? The instance document shouldn't be able to negate what the
specification says about the syntax and its implied semantics.

So that's the key thing: if you consider that @profile can negate
schema-expressed triples, I think you're contradicting the way GRDDL
works, regardless of RDFa. I don't think @profile can negate the meaning
of @about, because @about is *specified* with associated semantics, just
like rel="next" (more further down on how your interpretation of
rel="next" is not quite right.)

> I'd quibble here that the document isn't expressing this *triple*. It's
> expressing information which you might want to choose to express in any
> number of formats.

Ah, this is an argument DanC and I have all the time. RDF is an abstract
representation of data. If the author intends to say that the title of
the document is "Foo", then I can certainly express that intent as an
RDF triple, even if the author has no idea what RDF stands for. An
author doesn't have to be RDF-aware. Otherwise, the entire
microformat-GRDDL approach is dead in the water, as the majority of
microformat folks have no love (or likely knowledge) of triples.

> I don't think it is what you want to do with RDFa because you only want
> to express some of the semantics of the html spec. RDFa doesn't express
> the whole document as triples. You pick and choose. You're parser, for
> instance produces triples from @rel=next, but you don't from
> @rel=stylesheet for instance.

On the general principle: we pick and choose things that are semantic.
On @rel=stylesheet, that's actually a mistake in my parser, since that's
a reserved word and thus does denote some semantics.

> I don't see that a @profile instead of a DOCTYPE worsens the situation
> of copy-and-paste and self-containment. Neither can be placed within the
> <body> of the document. In fact, if anything, the DOCTYPE is far more
> fundamentally rooted to the top of the document. And as Dan said, far
> less accessible for scripting and XSLT.

Again, you're now staying away from your previous
argument, where you said you wanted to use RDFa attributes for other
purposes. *That* is what @profile-centricity would do: it would make
these attributes potentially mean something *different*, which is what
hurts copy-and-paste because it weakens the meaning of these attributes
in authors' minds.

There are plenty of reasons to take stuff that was never meant to be
semantic and provide ways to transform that into RDF. That's the beauty
of GRDDL. But when you specifically introduce attributes for
semantics, leaving their meaning up in the air and dependent on a GRDDL
transform is a disaster for locality and self-containment, because it
dillutes the meaning of the attributes.

> I don't think you've really addressed my earlier point. <link rel="next"
> href="/next.html" /> is the DOM.

No, it's not just the DOM. The HTML specification says that this has a
special meaning, and that browsers can take that meaning and do
something with it if they choose, like offer a Table of Contents UI.

> Neither GRDDL nor RDFa is, or should
> be, about expressing the entire DOM as triples. There's lots of
> information within the document structure that RDFa chooses not to
> express as triples - this doesn't negate their meaning or presence in
> the DOM.

You're confusing things. rel="next" is more than the DOM. foo="bar",
that's DOM, rel="next", that's DOM + HTML-specified semantics. In RDFa,
we're trying to expand the HTML-specified semantics in a consistent,
backwards-compatible way, because we think that's very valuable. We're
not just adding attributes that can then be interpreted in any way the
profile chooses.

> On the contrary as far as I can see.
> If you make RDFa consistent with GRDDL

This is a vague statement. I believe we are consistent with schema-based
transformations. I'm just trying to get the same effect via DTDs and
DOCTYPE.

Since GRDDL already specifies a way to grandfather in non-XML
transformations, it could easily specify a way to follow one's nose to a
GRDDL transformation using DOCTYPE.

Let's get back to the key issue I have with what you're trying to do:
you want to use @about, @property, @content but interpret them in ways
other than what RDFa specifies, and not in addition to the RDFa meaning,
*instead of* the RDFa meaning. You're suggesting that we validate stuff
on the one hand, and specify semantics separately, on a per-document basis.

In other words, as hard as it already is to get people to standardize on
one syntax, you'd like to make it harder still :) That's unlikely to
convince me.

[... stuff about the advantages of GRDDL ...]

I think GRDDL should absolutely be (very slightly) extended to find
schema-based transformations for DTD/DOCTYPE documents, so that this
will work flawlessly. And I encourage RDFa authors to add the RDFa
profile to make it extra clear. But I don't want to do anything that
makes it easy to negate RDFa when using RDFa attributes, that hurts us
too much.

>  Firstly, the most likely scenario for reusing RDF attributes is authors
> needing to extend RDFa, rather than pervert it. How often people need to
> extend RDFa depends on how good the spec is I suppose; but wouldn't you
> rather they were able to do so and remain standards-compliant?

So this is different. Yes, if people want to add their own syntactic
sugars to extend RDFa, that's great, but then the only way to do that
and preserve the principles of RDFa is via hGRDDL, not GRDDL. So you can
have the baseline RDFa defined in the DOCTYPE/schema, and the profile
indicating an hGRDDL transform that extends RDFa. Nothing wrong with
that. You just *can't* redefine the baseline meaning of the RDFa attributes.

> I think
> you said yourself Ben (though it could have been someone else), with
> regards HTML5, that people will do what they need/want to do anyway, so
> it is better for the spec to plan for extensibility than force people
> into defiance of it.

Absolutely, and as I explained many times, I tried (in vain) to get the
GRDDL folks to make something like hGRDDL possible, so RDFa could be
extended. But that was not a GRDDL priority, so it didn't happen, so
hGRDDL will have to be specified separately.

It's important to note that GRDDL alone, because of this limitation,
*cannot* extend RDFa without breaking the locality and self-containment
principles. hGRDDL is necessary.

> Secondly, RDFa also infers triples from existing elements and
> attributes. Your js RDFa parser Ben, generates some odd triples from my
> eRDF documents

Give me some examples. I'm sure the main problem is that my parser is
buggy and far too promiscuous.

> The most important thing is to be able to get triples.

In RDFa, that's *one* of the important things. The other principles are
just as important, and they require a consistent syntax. Thus, I
continue to claim that you're looking at this through GRDDL-colored
lenses :)

> RDFa is an
> offical syntax for providing both triples, and the DOM context of those
> triples. That may be a good option for authors to have, but it doesn't
> need to be forced on authors whether they like it or not - that would
> be  a bad thing.

I'm not forcing it on anyone. Don't use the DOCTYPE. But I *am* saying
that if you use the attributes we've defined, we're going to say that
those mean what RDFa says they mean.

-Ben

Received on Monday, 16 July 2007 23:26:19 UTC