Re: capturing reserved keywords in @rel

Mark,

Again: I am lost. Really. What I think Manu (and I) are saying is that 
the namespace document for

http://www.w3.org/1999/xhtml/vocab#

defines prefix-less @rel values that are meaningful (it may be a simple 
XHTML file listing the values in a <dl>, I do not really care!), and 
they are in that namespace. All other prefix-less CURIE values are 
thrown away. Period. Full stop.

I do not think there should be _any_ reference to _any_ preprocessing 
step in RDFa. Yes, @rel="DC.Creator" will be lost, and RDFa requires 
@rel="DC:Creator". (The DC folks actually know that and have agreed with 
that.)

Introducing the extra @profile mechanism to define other namespace for 
prefix-less @rel values is, well... under-defined, isn't it? There is no 
accepted formalism to define such values, so either we define this, or 
we leave it undefined but then we have a problem because the 
preprocessing is undefined... or we define this mechanism a la XSLT, in 
which case we have to reproduce GRDDL... let us not go there!

I may be missing something fundamental here.

Ivan

Mark Birbeck wrote:
> Hi Ivan,
> 
>>> 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.
> 
> Right...I agree. But that does mean we have gone full circle, since
> that's what we had before, when we agreed to defer the issue all that
> time ago. The whole point of my suggestion at the time, was that we
> would add the feature that we know we want to implementations, and
> then we should work out later exactly how to write it up in the spec,
> or whether it should be part of some other spec, such as hGRDDL, or
> even (dare I say it?) CURIEs.
> 
> I'll come back to this idea at the end.
> 
> 
>> 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?
> 
> First, with respect to Manu, I don't know what this means:
> 
>   The http://www.w3.org/1999/xhtml/vocab# namespace is automatically
>   applied to each predicate that is non-prefixed and exists in the
>   http://www.w3.org/1999/xhtml/vocab# namespace.
> 
> It would need to be more precise than this, to count as "spec-ready text".
> 
> But to be fair on Manu, it's difficult to see how we _could_ be more
> precise -- that's why I was all for moving this whole question outside
> of the spec. (And you've just said that you don't think this should be
> in the spec, anyway. :)
> 
> Anyway, this isn't what I've been trying to raise. The issue I keep
> coming back to is what to do with the non-pre-processed values, i.e.,
> those values that weren't in the list of XHTML link types. They will
> still be sitting there in @rel and @rev, and whilst they _look like_
> CURIEs, they are not. If we apply Manu's prose above, then we will be
> left with a non-prefixed CURIE for "DC.Creator", for example, and that
> will generate a triple.
> 
> So...
> 
> Everyone knows what they would _like_ to do with these values -- I've
> heard "ignore them" plenty of times now. :) So all we need is some
> "spec-ready text" that might achieve this.
> 
> To illustrate what I mean by being more precise, we could solve this
> by, for example:
> 
>   * saying that @rel and @rev hold 'safe CURIEs', rather than CURIEs,
>     and that when processing @rel, only CURIEs are processed (Ben
>     doesn't like this approach because it reopens a closed issue, but
>     it is important to realise that this is the only way to ensure that
>     CURIEs are consistent throughout the spec);
> 
>   * or, saying that a CURIE actually doesn't have an empty prefix
>     version, and so "DC.Creator" is simply not a CURIE, and so is
>     ignored (I don't like this approach because it means our CURIE
>     rules will be different to those in @role and @access).
> 
> But given that we can't get agreement on this, I think the best thing
> is to take it out (as you say) but to define the preprocessing step as
> being closely related to @profile.
> 
> By this last point I mean that XHTML already says that if you use a
> LinkType value in @rel that is not referred to by a value in @profile,
> it is invalid. So we could extend that somewhat, and say that the URL
> of the profile is prefixed onto any 'matching' values (in the way that
> "...#vocab" is added in hGRDDL), and then any unmatching values are
> *completely removed*. This means that "DC.Creator" would be gone if
> there is no appropriate @profile value, and therefore it could never
> be confused with a non-prefixed CURIE.
> 
> Of course, the exact mechanism by which the correct DC prefix gets
> attached to the correct values based on @profile would need to be
> worked out, but pulling in a script in GRDDL fashion is probably what
> Ben has in mind. So until it has been defined, "DC.Creator" will
> simply be removed, and "next" and "license" will work fine.
> 
> But the key advantage of this approach is that it moves the issue out
> of the RDFa spec, and into some pre-processing specification, and we
> therefore don't need to touch our rules. "DC.Creator" remains a valid,
> unprefixed CURIE, in all other contexts, but as long as we ensure that
> it never gets to the RDFa parser when used in @rel, then there can be
> no confusion. Which means that we don't need to say *anything* about
> ignoring unprefixed values in the spec.
> 
> In fact, all we really need to do is add a note to the RDFa spec that
> tells implementers that there is a need for a pre-processing step
> which has the effect of normalising values with a valid profile, and
> removing those that are invalid, to take into account legacy mark-up.
> We could say that a future spec will define this in more detail, and
> that for now an implementer should act 'as if' that pre-processing had
> been performed.
> 
> 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