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

Re: Further changes to URI and CURIE processing description

From: Ivan Herman <ivan@w3.org>
Date: Thu, 24 Jan 2008 12:42:53 +0100
Message-ID: <479879BD.4020305@w3.org>
To: Mark Birbeck <mark.birbeck@formsPlayer.com>
Cc: W3C RDFa task force <public-rdf-in-xhtml-tf@w3.org>
Hm. I have not thought of @name at all! But my recollection was that we 
would leave @name out of the RDFa picture altogether, so I am not sure 
what you refer to when you say "@name we;ll have to do what I've done 
with @rel/@rev".

I have no problem defining @property as CURIE and leave it at that. I 
guess my only issue is consistency: if this is what we do than the list 
of values in section 9.2.5 of the current syntax document is irrelevant 
and should be removed (as, as I said in my comment, most of section 9 
should be removed in my view...:-)


Mark Birbeck wrote:
> Hi Ivan,
> Ah, yes...I forgot about that one.
> My suggestion would be slightly different. I think we should set
> @property to simply be a CURIE, with none of the complications of
> @rel/@rev, and then leave @name completely untouched, i.e., exactly as
> it used to be.
> If you think about it, one of the arguments for keeping legacy values
> in @rel is so that the values work in things like search engines. So
> if we encourage people to use @property for their legacy values then
> they *won't* work in search engines! In other words,
> @property="description" will NOT work for Google, even though it
> generates a lovely triple for us.
> But the converse, make @name hold both legacy values and CURIEs seems
> pointless...why bother? Why not just keep @name as it always was, and
> leave @property to be cleanly devoted to CURIEs.
> Of course, in @name we'll have to do what I've done with @rel/@rev,
> and say that certain values are a shorthand for a longer URL, but
> that's easy enough.
> Regards,
> Mark
> On 24/01/2008, Ivan Herman <ivan@w3.org> wrote:
>> Mark,
>> First of all, I have no problem with the proposed changes and the way
>> you describe @rel/@rev. I have a number of other comments on the syntax
>> document (nothing major), I will send them in a separate mail.
>> My only comment here is: what is then the fate of @property? The current
>> syntax document lists, in section 9.2.5, a number of reserved values for
>> @property, too, which are clearly defined by the XHTML group. I see two
>> alternatives:
>> 1. we should treat @property exactly like @rel/@rev in this respect and
>> add it to your description accordingly (ie, @property="description"
>> generates an appropriate triple with a literal and @property="foobar" is
>> ignored).
>> 2. there should be no list of preserved terms listed in the document for
>> @property.
>> Personally, I think alternative #1 is the consistent one...
>> Ivan
>> Mark Birbeck wrote:
>>> Hello all,
>>> I've just pushed up some more changes, the main ones being to deepen
>>> further the explanation about how CURIEs and URIs are processed. I've
>>> done this for a couple of reasons.
>>> The first is that in the processing section there was a lot of
>>> repetition to explain some of the common requirements. For example,
>>> all URIs need to be resolved relative to base, using the algorithm in
>>> RFC 3986, and this was repeated at every point in the processing model
>>> rules. Also, if an attribute can take a CURIE then that must be
>>> converted to a URI, which was again repeated.
>>> So...I've changed the processing rules to simply say, for each
>>> attribute 'obtain a URI according to section blah blah'. Then in that
>>> section I look at how the URI is obtained; for example if it's @href
>>> you just read the value straight, if it's @about you check for safe
>>> CURIEs, and so on.
>>> That all keeps the processing model section a bit leaner, as well as
>>> giving a bit more space to elaborate more fully on how URIs are used,
>>> and how CURIEs get converted. It also means that some of the things
>>> that seemed specific before, are now applied to all uses of CURIEs.
>>> For example, I've now explained what happens with non-CURIEs, which
>>> before was only being applied to @rel (i.e., that they are ignored)
>>> but now applies to all attributes (e.g., @about="[foo]" will not set a
>>> new subject).
>>> Having the extra space also allows us to draw implementers' attention
>>> to key parts of the whole CURIE/URI set-up which were not drawn out
>>> before. For example, I've taken the opportunity of having a separate
>>> section to point out to implementers that they must take into account
>>> that XML namespaces are locally scoped...obvious I know, but it's the
>>> kind of thing that is important for smooth implementation.
>>> Anyway, I'm flagging this up mainly to draw attention to the fact that
>>> although there have been a lot of changes, they shouldn't have
>>> affected the processing. If anyone thinks that the processing has been
>>> changed in any way, then please flag it up, because it was not
>>> intentional.
>>> However, there is one place I have changed the meaning...and it is
>>> intentional. :)
>>> (Takes deep breath...)
>>> I have slightly changed how @rel and @rev work. There should be no
>>> difference in the _effect_ though, but the change is that the
>>> algorithm converts tokens like "next" and "license" *directly* to
>>> URLs. In other words, "license" is no longer a shorthand for
>>> xh:license, it is a shorthand for "http://....vocab#license".
>>> It will no doubt sound to most people as if I'm discussing how many
>>> angels can fit on the head of a pin; if it does, that's good, because
>>> it probably means that no-one is bothered either way.
>>> But for anyone who is worrying, here is the rationale: the point of
>>> the new section on "CURIE and URI Processing" is to explain how you
>>> get URIs for creating triples. As far as the main processing model
>>> section is concerned the world is only made up of URIs -- there is no
>>> such thing as a CURIE, since they will have already been converted.
>>> Some attributes can take both a URI and a CURIE, and in that situation
>>> the URI simply bypasses the CURIE algorithm and just remains a URI.
>>> It struck me that the same could be said of @rel and @rev; you could
>>> say that @rel and @rev take EITHER a link-type OR a CURIE. If it's a
>>> link-type (next, previous, license, etc.) then you might as well
>>> convert it straight to a full URI. And if it's a CURIE...well, we know
>>> what to do with CURIEs.
>>> The problem with the previous approach of saying that "next" is a
>>> CURIE...is, well...it isn't. Now that we've said that an unprefixed
>>> CURIE is invalid, then "next", "license", etc. are simply not CURIEs.
>>> The only way to make them work is to have the preprocessing step that
>>> we've all talked about, but then it gets very odd -- we've defined an
>>> attribute that takes values of a certain type (CURIEs) and then listed
>>> some values that don't conform to that type ("next", "prev", etc.) and
>>> then we're relying on an external process to come tidy everything up
>>> and make it work!
>>> However...
>>> If we take a different approach and say that the definition of
>>> @rel/@rev is conceptually along these lines:
>>>   linktype ::= "alternate" | ... | "next" | ... | "up"
>>>   rel ::=  linktype | curie
>>> and then say 'link-types are processed by converting them to URIs',
>>> then we're all done. We don't need a preprocessing step, since
>>> everything is within the RDFa syntax itself. And we've kept the
>>> mapping from linktype to URI outside of both CURIEs and the core RDFa
>>> processing model
>>> Anyway...chew it over...
>>> And be warned that I am up against a tight deadline, so even if you
>>> rant at me that this is a terrible change, I'll probably ignore you.
>>> :)
>>> 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

Received on Thursday, 24 January 2008 11:42:59 UTC

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