Re: ISSUE-1: Status of RDFa Profiles

As Mark and Manu are delving very deeply into the @profile discussion, I 
just want to highlight something Toby wrote a few days ago regarding the 
issue with having @profile import prefixes:

> The other problem is that it introduces a conflict with full URIs in
> attributes.
>
> e.g.
>
> 	<div profile="http://example.com/vocab">
> 		<span property="foo:bar">foo bar</span>
> 	</div>
>
> If example.com is down, the parser has no way of determining whether
> "foo" is a CURIE prefix defined by the profile, or a URI scheme.

I think this is very important, even if example.com isn't down: it once 
again shows a conflict between @xmlns and @profile. At the end of the 
day, RDFa 1.0 treats unprefixed CURIEs and prefixed CURIEs quite 
differently, and as we try to harmonize them, we're going to keep 
hitting these types of issues.

Mark's token proposal is very elegant, but I don't see how it matches 
the constraints of RDFa 1.0, and I'm pretty sure most HTML authors won't 
see the parallel: it's one level of abstraction/indirection too much.

Mark, you say that you want to eliminate @xmlns... but we can't. Parsers 
are going to continue to support it, and people will mix RDFa 1.0 and 
1.1 conventions for a very long time.

Ivan, you say that @profile in the BODY is not RDFa 1.0 compliant. True, 
but we already have to deal with non-compliant HTML all the time (extra 
attributes for various JavaScript toolkits, etc...), so we *know* that, 
as people deploy RDFa 1.1 markup, RDFa 1.0 parsers will pick it up and 
generate triples. We need to ensure that those triples are a subset of 
the RDFa 1.1 triples.

So, again, I come back to this point: conceptually, no matter how we 
express @profile's, I don't see how we can let them import prefixes 
without causing significant problems.

-Ben

Received on Tuesday, 16 March 2010 23:48:22 UTC