W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > January 2008

Re: capturing reserved keywords in @rel

From: Mikael Nilsson <mikael@nilsson.name>
Date: Wed, 23 Jan 2008 12:36:07 +0100
To: public-rdf-in-xhtml-tf@w3.org
Cc: Thomas Baker <tbaker@tbaker.de>, Pete Johnston <Pete.Johnston@eduserv.org.uk>
Message-Id: <1201088167.6964.11.camel@daneel>

[Please cc on replies]

To be 100% clear about the Dublin Core position here:

The two specifications for representing Dublin Core metadata in

Recommendation, from 2003:

Proposed recommendation, will eventually replace the above:

*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.


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
> the namespace document for
> http://www.w3.org/1999/xhtml/vocab#
> defines prefix-less @rel values that are meaningful (it may be a
> 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
> that.)
> Introducing the extra @profile mechanism to define other namespace
> prefix-less @rel values is, well... under-defined, isn't it? There is
> accepted formalism to define such values, so either we define this,
> we leave it undefined but then we have a problem because the 
> preprocessing is undefined... or we define this mechanism a la XSLT,
> 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
> >>It is a reasonable way of implementation (my implementation has,
> >>essentially, the same general feature built-in), but it is not a
> >>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:
> >>
> >>
> >>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
> >>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
> >
> >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
> >of the spec. (And you've just said that you don't think this should
> >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
> >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
> >    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
> >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
> >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
> >"...#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
> >unprefixed CURIE, in all other contexts, but as long as we ensure
> >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
> >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


Plus ça change, plus c'est la même chose
Received on Wednesday, 23 January 2008 11:36:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:26 UTC