Re: capturing reserved keywords in @rel

Mark Birbeck wrote:
> Hi Ben,
> 
>> We should *not* consider hGRDDL as an official piece of the RDFa spec.
>> I'm only trying to show how trivial it is to look for reserved keywords
>> and prefix them so they can be picked up by the main RDFa parser (which
>> otherwise ignores un-prefixed @rels). This approach is a pre-processing
>> step, which may be how we want to word it.
> 
> Right...but what about the spec? As I keep saying, the tricky bit is
> not writing code to do it, but putting it into the spec. Everyone
> keeps saying this is easy, but still no-one has tackled the
> specification side. :(
> 
> So the first question is where are you proposing to place the
> pre-processing step? (In the spec, I mean.)
> 

Nowhere:-)

I do not think that this pre-processing step should be part of the spec. 
It is a reasonable way of implementation (my implementation has, 
essentially, the same general feature built-in), but it is not a spec issue.

I am actually lost. I thought Manu's proposal in:

http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2008Jan/0152.html

is a perfectly reasonable way of document this and put an end to the 
issue (and hGRDDL is _a_ conceptual way of implementing it, but that is 
not part of the document).

What is wrong with Manu's stuff?

ivan





> Second, once the pre-processing step has run, there may still be some
> non-prefixed values left that were unmatched; since these are valid
> CURIEs, what are you suggesting is done with them?
> 
> I'm sure the answer will be 'ignore them', but how, exactly? Some rule
> somewhere needs to say that a different CURIE processing algorithm
> needs to be applied to these values than those in other attributes.
> Where would you put that rule?
> 
> Last time we discussed this there were proposals that we actually
> redefine CURIEs to have a mandatory prefix, and that was why we ran
> aground. And I'm very much against having differential rules, so I'm
> trying to get specific here on how you would 'switch out' the values
> that you want to ignore.
> 
> 
> Not wishing to preempt any replies, but like to return to a suggestion
> I made the other day, and see if you'd find it acceptable in
> conjunction with your hGRDDL proposal.
> 
> I was saying that I would like to see us leave CURIE rules alone (or
> if we change them, we change them everywhere), and instead modify the
> definition of @rel so that it could take _both_ a safe CURIE _and_ a
> LinkType. This seems right to me anyway, since we are dealing with an
> attribute that already exists in XHTML, so we really shouldn't be
> removing its old type.
> 
> So, for example, a @rel value might take something like the following:
> 
>   <link rel="license" href="..." />
>   <link rel="[cc:license]" href="..." />
> 
> This uses safe CURIEs in just the same way as attributes like @about
> and @resource.
> 
> You could still run your pre-processing step, with the minor
> modification that matching values are converted to a safe CURIE, not
> just a CURIE:
> 
>   <link rel="[xh:license]" href="..." />
>   <link rel="[cc:license]" href="..." />
> 
> And in fact, since the default prefix is "...#vocab" then we wouldn't
> even need to worry about the 'xh' prefix:
> 
>   <link rel="[:license]" href="..." />
>   <link rel="[cc:license]" href="..." />
> 
> It also means that we don't need to worry about unconverted values,
> since they will simply be non-CURIEs:
> 
>   <link rel="DC.Source" href="..." />
>   <link rel="[:license]" href="..." />
>   <link rel="[cc:license]" href="..." />
> 
> Our algorithms could be tweaked slightly to say that what we look for
> in an attribute depends on the datatype of the attribute, and so in
> the case of @rel we are only looking for safe CURIEs.
> 
> It's not perfect -- what is? :) -- but it does mean that CURIEs behave
> the same everywhere, and it allows us to ignore the unprefixed values
> that didn't match the list of XHTML types, but that we don't want to
> be interpreted as unprefixed CURIEs.
> 
> Regards,
> 
> Mark
> 

-- 

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