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

Hi Andrew,

[...]
> few days, and they tend to frown on typing emails while driving down
> the motorway if you're also doing the driving... ;)

Don't write and drive ;)

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


> What I was suggesting was a way to leverage Topic Maps PSIs
> orthogonally to the markup to describe how to interact with the
> endpoint itself.

ACK.

[...]
>         "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).

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

[...]
> Do you see where we're talking about different problems?

Finally! :) I am a bit slow. :)

[...]
> 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.

Best regards,
Lars
-- 
Semagia 
<http://www.semagia.com>

<https://twitter.com/larsheuer/> Twitter
<http://www.topicmaps.de/mailinglist/> German Topic Maps mailing list
<http://tinytim.sourceforge.net/> Open Source Topic Maps engine
<http://mappa.semagia.com/> Mappa - Python Topic Maps engine