Re: A rose by any other name is just as thorny...

So, let me try to reformulate that to see if I understand

- we have the generic @vocab and @profile mechanism
- there is no default set of keywords hardcoded in RDFa 1.1 Core
- there is no default @vocab or @profile for RDFa 1.1 Core
- there is no default set of keywords hardcoded in RDFa 1.1 XHTML
- there is no default @profile set for RDFa 1.1. XHTML
- there _is_ a default @vocab, conceptually set on the <html> element,
which is set to the value of "http://www.w3.org/1999/xhtml/vocab#".

I believe that would cover the mechanism you describe, right? I am
trying to see whether there is anything conceptually different or new
here, and my impression that the only additional thing is the last
bullet items.

More generally, we may have default @vocab values set by specifications
for different RDFa 1.1 usages for specific XML vocabularies. The issue I
see is how various RDFa processors would know about those defaults. For
the (X)HTML case I would probably look at the suffix and/or the media
type and 'hardwire' the default that way; that could also work for other
XML dialects that happen to have a dedicated suffix and media type...

Ivan



On 2010-3-26 09:34 , Manu Sporny wrote:
> On 03/25/2010 05:02 PM, Ivan Herman wrote:
>> On 2010-3-25 15:11 , Shane McCarron wrote:
>> [skip]
>>>
>>> What's my point?  My point is this.  In a world where we permit the
>>> declaration of new default vocabulary prefixes, we have no need to ever
>>> determine the collection of terms that is defined by that vocabulary. 
>>> We should just trust the document.  We are already doing that in every
>>> other instance anyway.
>>>
>>> Thoughts?
>>
>> I may either misunderstood you or the original proposal for the default
>> prefix. But _my_ understanding has always been that if one uses the
>> default vocabulary prefix than this is just used to be concatenated with
>> the prefix-less term in, say, @rel. That is certainly the way I
>> described in
> 
> Shane's not talking about the "default-prefix" concept, at least, not
> directly. Shane is raising a very interesting point about the "default
> vocabulary" and how we might resolve keywords like prev/next.
> 
> Namely, how do we mesh features like rel="prev" and rel="next" into the
> RDFa Core document without enforcing XHTML+RDFa keywords into RDFa Core?
> Remember, SVG, ODF, XHTML and HTML are all going to share the RDFa Core
> document - putting XHTML specific stuff into RDFa Core is far from ideal.
> 
> We have been talking about a default vocabulary document for a couple of
> weeks now, the idea is that the default vocabulary document would be an
> RDFa Profile, and would be used if there is no mention of @profile in
> the current RDFa Processor context.
> 
> So, at the moment, we could say that xhv is the URL for our default
> vocabulary document in RDFa 1.0:
> 
> http://www.w3.org/1999/xhtml/vocab#
> 
> and when somebody does this RDFa 1.0:
> 
> <body>
>    <a rel="next" href="chapter3.html">Chapter 3</a>
> </body>
> 
> We create this triple:
> 
> <>
>    <http://www.w3.org/1999/xhtml/vocab#next>
>       <chapter3.html> .
> 
> That's hardcoded into all the RDFa Processors right now. Shane is
> saying, let's not hard-code it and let's not require de-referencing the
> default RDFa Vocabulary Document (http://www.w3.org/1999/xhtml/vocab#).
> Like Toby's line of argumentation, a processor doesn't need to
> dereference the default RDFa Vocabulary document to generate a triple.
> For example, in RDFa 1.1 - if there is no active @profile, and there is
> no active @vocab, this markup:
> 
> <body>
>    <a rel="foo" href="bar.html">Baz</a>
> </body>
> 
> would generate this triple:
> 
> <>
>    <http://www.w3.org/1999/xhtml/vocab#foo>
>       <bar.html> .
> 
> Yes, "foo" isn't defined in the XHTML vocabulary, but who cares? It's
> not going to do anything if generated... it's a useless triple.
> Historically, we've shyed away from this behavior in the name of not
> generating junk triples. It's the reason we put all of the reserved
> words in a normative section in the RDFa 1.1 spec.
> 
> ****
> So, Shane is saying - let's relax this requirement and not specify
> reserved keywords in the RDFa specification. Let's just specify a
> default vocabulary URL.
> ****
> 
> If we do that, we simplify the spec and don't require dereferencing of
> the default vocabulary document. The downside is that we run the risk of
> generating junk triples. The bottom line, though - is that there is
> still a follow-your-nose story. The RDFa processor should trust that
> what the author put in the document is what they meant.
> 
>> http://www.w3.org/2010/02/rdfa/drafts/2010/ED-vocab-20100326/
>>
>> There is no intention of dereferencing that URI.
> 
> Yes, for @vocab... but we're not talking only about @vocab. We're
> talking about the interplay between "The Default RDFa Vocabulary" (which
> is an RDFa Profile), @profile and @vocab. So, something like this:
> 
>    <a rel="foo" href="bar.html">Baz</a>
> 
> would follow these rules in Shane's "rose" proposal:
> 
> 1. If there is a @vocab active in the current RDFa Processor context,
>    generate a triple with @vocab + foo as the predicate.
> 2. If there is no @vocab active, but there is a @profile active check:
>    2.1 If "foo" is a keyword defined by @profile, and if so
>        use that URL.
>    2.2 If "foo" is not a keyword defined by @profile, generate a
>        triple with xhv + foo as the predicate.
> 3. If there is no @vocab or @profile active in the current RDFa
>    Processor context, generate a triple with xhv + foo as the predicate.
> 
> At least, I think that's what Shane is saying...
> 
> -- manu
> 

-- 

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF   : http://www.ivan-herman.net/foaf.rdf
vCard  : http://www.ivan-herman.net/HermanIvan.vcf

Attachments

Received on Friday, 26 March 2010 21:31:21 UTC