Re: Further changes to URI and CURIE processing description

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...:-)

Ivan

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