Re: Further changes to URI and CURIE processing description

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