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

Hi Keith,

Taking your last comment first:

> I'm sorry if the last email seemed a little heretical Ben. Hopefully 
> this reply has persuaded you, if not of the validity of my viewpoint, at
> least that we want (some of) the same things (consistency for publishers
> and tool builders).

And I'm sorry if my response seemed a bit harsh, I'm trying to make sure
we don't make a mistake that invalidates the whole set of principles we
set out to accomplish in the first place :)

I do think we want some of the same things, but I also think you want
the consistency to always come from the GRDDL end of things, and you
expect every client to be @profile-aware. More on this in response to
your specific comments.

Keith Alexander wrote:
> GRDDL doesn't (I think) redefine the meaning of HTML (or any other
> format); it simply lets the document publisher say: "apply this
> transformation to the document to get the triples I want to publish".

so far so good.

> @rel='next' can mean something according to the HTML spec, but it
> doesn't mean that my GRDDL profile needs to generate  <#x> html:rel-next
> <#y> . Nor is it incorrect if it generates a completely different triple
> from the same @rel value.

correct, your GRDDL profile doesn't have to be complete, but the page is
*still* expressing the triple <#x> html:rel-next <#y>, since that's part
of the HTML spec and the GRDDL profile can't undo that.

> I think we're talking about two different kinds of semantics here, with
> RDF-in-HTML.
> 
> 1. The semantics derived from the HTML specification. (RDF *from* HTML
> ?). It may be possible to express these semantics as triples: <#x>
> html:rel-next <#y> . but it's not usually very useful to do so.

Why is it not useful? This is exactly what we want to do with RDFa:
create a new version of HTML that implies triples in more extensible
cases. We want that to be part of the language.

> 2. The semantics of the triples that can be extracted from the document
> according to the rules specified by the document's author.
> 
> Number 2 is the one we're all interested in I think; depending on the
> rules specified, it can encompass any of the same triples as number 1,
> or completely different triples altogether.

Except I want the rules standardized, for issues of copy-and-paste and
self-containment.

> If your tool comes across my non-RDFa page, it can look
> at my @profile see that I'm using a non-RDFa GRDDL profile, and know
> that it shouldn't parse my page as RDFa.

Ahah, and *this* is where I claim the problem is. I don't think that
profile should be able to negate what the XHTML+RDFa spec is saying. It
can't negate rel=next, so similarly it can't negate the RDFa.

If it could, then everything would always have to be aware of the
PROFILE attribute. That's what I mean by GRDDL-centric. You want to not
care about the DTD, but you also want me to *always* care about PROFILE.
I call that a GRDDL-centric approach, and I think it is ill-suited to
RDFa, because it encourages inconsistent publisher behavior.

> By using a custom profile, I'm
> not expecting your tool to have to adapt to that profile, or accomodate
> it in any way, other than *not* extract triples I *didn't* specify.

That sounds contradictory to me. You are asking my tool to accomodate
your profile, because you'd like my tool to check for PROFILE=no-rdfa. I
want to be able to ignore the PROFILE for purposes of RDFa, since that's
not the primary RDFa flag. It's not the primary RDFa flag because if it
were, it would encourage publishers to use the RDFa attributes for other
purposes.

And I definitely don't want to encourage folks to use the RDFa
attributes for non-RDFa purposes, since that hurts the
self-containment/copy-and-paste goal significantly.

> If my page does have the RDFa profile on the other hand, your tool can
> extract triples according to the rules of RDFa, do clever things with
> the html context of the triples, etc.

Right, so again you're asking for a PROFILE centric approach to this.
For reasons mentioned above, I don't think that's good. It takes us down
the same broken path of microformats: no consistent syntax, ever.

>> Innovation doesn't happen at the syntax
>> level, it happens at the semantic level.
> 
> I think this is an especially dangerous assumption to make - especially
> since we are talking, not about one format, but the intertwining of two.
> For example, RDFa doesn't (so far as I can see) make any use of @value.
> Someone might want to extend the RDFa syntax with a custom GRDDL profile
> to cope with form input values. That would be innovation rather than
> simply variation, wouldn't it?

This can be done with hGRDDL, where value="" is transformed into
content="". So you could do it with a profile, and it would extend RDFa,
it just wouldn't *negate* existing RDFa.

> The beauty of GRDDL and your hGRDDL proposal is that you can have both
> because you are providing the necessary transformation for consumers to
> get the document/data in a consistent standard format, while giving the
> producer the flexibility to publish in a different format, should they
> need to.

Yes, but *not* by re-defining the existing RDFa attributes! Otherwise,
copy-and-paste is gone. hGRDDL and GRDDL don't work with copy-and-paste.
Copy and paste only works with a consistent syntax. hGRDDL and GRDDL are
mechanisms that help you bridge to RDFa, but they're not perfect.

> By being consistent with GRDDL, you can make things easier for tool
> builders and publishers, without compromising on any of the things RDFa
> would otherwise be able to do.

Do you see how it breaks the copy-and-paste use case, though?

> If you use the @profile to signify the presence of RDFa syntax, any
> GRDDL consumer is also an RDFa consumer. If you don't, consumers have to
> deal with the two separately,  authors have to be made aware of the
> dangers of their custom syntax looking like RDFa, and there have to be
> clear specifications on what happens when GRDDL and RDFa conflict/combine.

Well my goal is to eventually have XHTML validated using XML schema, and
then the XML schema file for XHTML+RDFa can contain the namespace-level
GRDDL transform, so that indeed GRDDL consumers can see RDFa, too. But I
 don't want to lead people down the microformat path, where there is no
consistent syntax ever.

Therein lies the crux of our difference: I consider RDFa to be specified
by the XHTML+RDFa spec, so if you use those attributes with the proper
DTD (potentially with doctype, as per Shane's comments) or XML schema
pointer, you mean RDFa. You would like it to be per-document, which is
what breaks the self-containment property.

> And if this is true of RDFa in HTML, then it will also be true of RDFa
> in every other XML format, won't it?

In any other XML format, RDFa can be specified as a namespace-level
transformation, so there's no issue at all. The issue we face with HTML
is specific to the DTD-based validation.

> (What happens, by the way, if the host language already has an attribute
> needed by RDFa? do you then give RDFa attributes a namespace of some kind?)

We'll cross that bridge when we get to it... it's an important question,
and I suspect the answer will vary depending on the specific situation.

I think we're getting to the crux of our disagreement here :)

-Ben

Received on Tuesday, 3 July 2007 18:05:57 UTC