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

On 22 Nov 2010, at 9:57 PM, Lars Heuer wrote:

> Hi Andrew,
> 
> I'll ignore everything Patrick has said and you've responded since
> this e-mail is shorter. In fact, I'll ignore everything you wrote. ;)\

I'm still chuckling, and I read this about 5 minutes ago.... well done! :)

> 
> IMO RFC 5988 is nice, but does not help (us?) (yet).
> 
> RFC 5988 specifies a binary link (with some context like media type
> etc., so it's not necessarily a binary link) between resources.
> 
> Further, the spec is (maybe intentionally) silent about the
> interpretation of the body of an response. Is the body necessary if
> the header provides all information? How do you interpret differences
> between the header and the body?

Oh, sure... play the RFC card.  TBH I hadn't even looked at the RFC because that was the part inside the <snark></snark> tags.  Maybe I need a PSI for the snark tag.... ;)

> For simplification I'd reduce RFC 5988 to triples:
> resource - has-relationship-to - another-resource
> 
> How would that help Topic Maps? If you favour TMDM you can use
> AsTMa=/CTM templates to create associations between resources. Or if
> you aren't a fan of AsTMa=/CTM you may map the "rel" attribute aka
> property to proper TMDM role types... .  Triples? Properties? Hmmm...
> ;) Isn't this an RDF -> Topic Maps mapping?
> 
> Yes it is.
> 
> Yeah! It mentions key/value pairs... TMRM is about key/value pairs...
> Great, but keys (and values) in TMRM don't have necessarily an IRI...
> .
> 
> I still see some value for RFC 5988 but not for Topic Maps.

I'll have to actually READ the RFC and have a think to respond properly, but I think you inverted the problem.  I was talking about what Topic Maps could bring to the RFC (based on reading the intro and assuming that it is the basis of the link I referenced inside the snark tag).

I think we need to help the world understand how Topic Maps can help in these situations rather than implementing yet-another-directory or yet-another-identity-mechanism.  If you need one, fine, but at least be able to express it in terms of things that exist so people can understand why it's relevant and necessary.

There are too many cases where the "if I'd have only known" syndrome applies on a regular basis, and it's only going to happen at an exponentially increasing rate.  People are too busy inventing stuff to go looking for prior art in most cases because someone is standing over them with a big stick going "is it live yet?"  Those of us that can recognize patterns (real or imagined--I'm not saying which) seem somewhat obligated to tell people about them, don't you think? :)

BTW, thanks for the RFC reference.  I hadn't gone looking.  Mark's a smart cookie with an emphasis on the practical and pragmatic, so he's one of those trying to do the right thing.  I think we should try and help.  Maybe it'll work and maybe it won't, but either way, we won't be able to sit back in 2-5 years and go, "damn, I wish we'd said something."

BTW, I'm not suggesting accosting Mark.  I'm just speaking in broad, semantically nebulous generalizations... as I'm wont to do... ;)

Cheers,

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