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

Hi Ben,

 From my point of view, you're seeing a conflict between GRDDL and RDFa  
that doesn't have to exist.

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".

@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.

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.

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.

RDFa is one set of rules, eRDF is another, likewise the rules behind the  
various microformat profiles.

This doesn't deny RDFa its special status, or make life difficult for tool  
builders. 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. 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.

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.


> 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?

> 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?

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.

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.

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.

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?

(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?)

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).

Yours,


Keith


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Received on Tuesday, 3 July 2007 17:43:54 UTC