Re: capturing reserved keywords in @rel

I am happy I did not misrepresent you guys!

Thanks Mikael

Ivan

Mikael Nilsson wrote:
> [Please cc on replies]
> 
> To be 100% clear about the Dublin Core position here:
> 
> The two specifications for representing Dublin Core metadata in
> HTML/XHTML:
> 
> Recommendation, from 2003:
> http://dublincore.org/documents/dcq-html/
> 
> Proposed recommendation, will eventually replace the above:
> http://dublincore.org/documents/2007/11/05/dc-html/
> 
> *both* rely on the @profile attribute for triggering interpretation of
> @rel etc as Dublin Core metadata.
> 
> Thus, from a DCMI point of view, there is no expectancy that any triples
> be inferred for rel="DC.creator" and similar in the absence of a
> matching profile attribute.
> 
> The proposed recommendation above uses GRDDL for XHTML, thus taking care
> of generating triples on its own.
> 
> The expectation is that direct use of RDFa will *eventually* replace the
> above specifications. In the meantime, it is assumed that RDFa and
> DC-in-HTML remain orthogonal and non-overlapping. I assume that this
> corresponds to what this TF wants, but i just wanted to make sure there
> is no misunderstanding.
> 
> /Mikael
> 
> 
> On Tue, Jan 22, 2008 at 02:23:30PM +0100, Ivan Herman wrote:
>> Date: Tue, 22 Jan 2008 14:23:30 +0100
>> From: Ivan Herman <ivan@w3.org>
>> To: Mark Birbeck <mark.birbeck@x-port.net>
>> Cc: Ben Adida <ben@adida.net>, RDFa <public-rdf-in-xhtml-tf@w3.org>
>> Subject: Re: capturing reserved keywords in @rel
>> Archived-At: <http://www.w3.org/mid/4795EE52.3070402@w3.org>
>> Sender: public-rdf-in-xhtml-tf-request@w3.org
>>
>> 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
> 
> 
> 

-- 

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