Re: Further changes to URI and CURIE processing description

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


-- 
  Mark Birbeck, formsPlayer

  mark.birbeck@formsPlayer.com | +44 (0) 20 7689 9232
  http://www.formsPlayer.com | http://internet-apps.blogspot.com

  standards. innovation.

Received on Thursday, 24 January 2008 11:26:13 UTC