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

Hi Ben,

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

And I'm hoping to convince you not to invalidate some more important ones  
in the process ;)

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

Well, I suppose that I can't really expect that given the strength of your  
opposition to it, but I definitely think it would be the most sensible  
strategy.
One rule, one place to look. Makes sense to me.


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

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

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.

So we're always going to be looking at situation two:

>> 2. The semantics of the triples that can be extracted from the document
>> according to the rules specified by the document's author.
>
> Except I want the rules standardized, for issues of copy-and-paste and
> self-containment.

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.

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

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

>
> If it could, then everything would always have to be aware of the
> PROFILE attribute.I call that a GRDDL-centric approach, and I think it  
> is ill-suited to
> RDFa, because it encourages inconsistent publisher behavior.

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

* every GRDDL agent understands RDFa
* all fully-compliant RDFa documents will be understood by all GRDDL  
agents (as with DOCTYPE, it is likely that some documents will contain  
RDFa, but lack the @profile - individual software and people can make  
their own decisions on what to do in these cases, but cannot hold the  
publisher to the triples they generate as a result).
* Authors can check and test their documents by running them through any  
compliant GRDDL agent
* Consumers can be sure what triples were intended by the author of any  
document with a @profile
* You have a clear, consistent mechanism in place for adding RDFa to other  
types of XML document
* It is easy to check for RDFa with XPath and javascript, both in HTML,  
and in arbitrary XML.
* Properly compliant cut'n'pasting requires an RDFa profile in source and  
target documents.

If you make RDFa inconsistent with GRDDL:

* some RDFa-compliant documents will be GRDDL-compliant, some won't.
* some fully-compliant RDFa documents won't be understood by GRDDL agents
* HTML authors using GRDDL have to run their documents through two parsers  
and combine the results to check which triples they are publishing.
* There is no clear idea of what authors in other XML varieties will have  
to do yet.
* Consumers of HTML have to check both the DOCTYPE and the @profile to see  
how to get all the intended triples.
* Some tool developers will find it hard/impossible to check for the  
DOCTYPE, so will be forced to  either assume all documents are RDFa, or  
none are, regardless of the author's intentions.
* Properly compliant cut'n'pasting requires an RDFa profile in source and  
target documents.

> 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.
>
It doesn't. You only have real fully-compliant, follow-your nose cut and  
paste if the cutting and pasting is done from one RDFa document to  
another. This applies whatever official signifier you use to denote RDFa  
triples rules.


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

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

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

That's not true at all. The most important thing is to be able to get  
triples. RDF doesn't need to have only one syntax for this. 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.

Yours,

Keith


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

Received on Sunday, 8 July 2007 19:34:02 UTC