Re: Banging the identity drum again, this time REST-style

Hi Lars,

On 25 Nov 2010, at 9:09 PM, Lars Heuer wrote:

> [...]
>> First, I think you're mixing metaphors here.  I'm not suggesting
>> trying to turn an XML element into a topic or even a subject proxy. 
>> While this can be done and there are valid reasons for wanting to do
>> it, it isn't what I was describing at all.
> 
> Finally I understood what you meant. :)

Great. :)

> [...]
>>        "atom:link elements MAY have a 'rel' attribute that
>> indicates the link relation type."
> 
>> The spec then goes on to suggest 5 initial values for the Registry
>> of Link relations.  One difference between the HTML5 version and the
>> Atom version is that the HTML5 version supports space delimited
>> values.  Therefore, it would be easier to identify something as a TM relation:
> 
>>        <link rel="tm:psi http://psi.example.com/create" href="/create" />
>>        <link rel="tm:psi http://psi.example.com/update" href="/update" />
>>        ...
> 
> I see. I'd simply treat all "rel" values as identifier, so tm:psi
> shouldn't be necessary. If I understood Atom and RFC 5988 correctly,
> the "rel" attribute was exactly meant for that purpose. Not all rel
> values are IRIs. There are some predefined names like "self" and
> "alternate" which can be expanded to
> <http://www.iana.org/assignments/relation/[RELATION-NAME-HERE]>. For
> example "self" should become
> <http://www.iana.org/assignments/relation/self> (which gives a 404
> unfortunately).

Interesting that it expands that way and not simply to the baseuri itself...

> I wonder if we need tm:psi as additional "markup". If all "rel" values
> resolve to IRIs, the resource can provide
>  a) Human readable information (PSI-alike) what the rel means and
>     what operations are possible
>  b) Machine readable information which informs an agent about the
>     possible operations
> 
> "tm:psi" as additional value is insofar disturbing as RDFa allows
> multiple, whitespace-delimited values where each of these values
> indicates a predicate/subject/object and I think you meant "tm:psi" as
> annotation for <psi.example.org/create> (sorry if I misinterpret your
> intention again).
> 
> I am unsure if the "rel" should provide information about the accepted
> media types etc. since Atom and RFC 5988 provide the "type" attribute.
> A resource may provide multiple links to another resource with the
> same value but a different "type" attribute (that's how Atom works).

This is probably just a consequence of me trying to invent things in an email... ;)

Seriously, though.  There were two reasons for trying to do it that way.  First, it was to make it more obvious what kinds of things were at the other end, but the second was to do this in a way that applied a little syntactic sugar.  Admittedly, there was a marketing angle to it, but I thing something like even a PSI uri scheme might be more useful in that way.  Sure, it's just HTTP under the covers, but it signifies the intent of the URI more clearly. ;)

Independent of any of the above, the primary intent is to dovetail easily into the existing extension points with a minimal amount of disruption.  If RDFa has this interpretation of delimited values as triples, then we need to either define something complimentary or, as you suggest, avoid it entirely.  I'm the first to admit that my RDF knowledge is far from complete and would only be at a rudimentary level.

> [...]
>> This gets back to my point about living in a heterogenous interweb.
>> I'm not trying to convert everything to Topic Maps.  I'm trying to
>> apply them where they make sense because there are plenty of
>> unsolved problems out there that fit well within the original intent
>> and remit of why Topic Maps was developed.
> 
> ACK. At least we could try to convince people to provide human and
> machine readable resources for the "rel" IRIs. If we convinced them,
> RDF will still dominate the market for machine readable data, but we
> could also offer descriptions in one of the Topic Maps formats.


Yep, and not only that, if people actually decided that they could be more expressive or more precise using Topic Maps, then there's already a well-defined mechanism in place for them to build upon.  It's a win-win as far as I see it.

Cheers,

ast
--
Andrew S. Townley <[email protected]>
http://atownley.org