Re: rel names vs URLs

The root idea seems perfectly sensible to me, and I agree it's wholly 
within the bounds of my interpretation of WebArch.  Indeed, the IETF 
itself has done so before, _for link relations_ ("what??"  read on...)

> For people who don't want to use URLs for relations, this wouldn't 
> affect them, and they wouldn't need to know about it.  This would NOT 

I'm not sure if you'd consider this a TECHNICAL problem or a "dislike it 
for non-technical reasons", but my sense from an offline discussion with 
IETF folks (IIRC someone involved with 5988, but hazy memory here) is that 
they don't like >1 name for link relations.  Recall that when 5988 took 
over the Atom-defined link relations from 4287, it DROPPED the existing 
IRI-equivalency rule (4287 section 4.2.7.2) that fundamentally did exactly 
what you are proposing on the URI side.  My conversation was limited to 
"was this intentionally dropped?  yes.  why?  two names for the same thing 
is Bad, and 4287:4.2.7.2 forces that extra unneeded complexity onto 
clients".

Since your approach does not force anything onto clients, they might get 
less exercised about it.  Given the historical use of the IANA IRI, you 
might consider using that too... basically restore the old shortname <=> 
equivalence relation, but with the understanding that shortname is to be 
used (and is the only value clients are required to understand) in 
contexts where the shortname syntax is permitted, and the IRI is a 
fallback used in contexts like RDF that do not permit shortnames.  Who 
knows, maybe that sort of "one name for clients of any given syntax" 
detente is something they'd actually like; doesn't hurt them, and 
incrementally narrow the rift between the great houses.  It would be a 
fairly small compatible update to 5988 (which carries the Link Relation 
Registry definition), so maybe they'd consider doing it in an erratum.


Best Regards, John

Voice US 845-435-9470  BluePages
Cloud and Smarter Infrastructure OSLC Lead