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

Hi Patrick,

On 22 Nov 2010, at 4:33 PM, Patrick Durusau wrote:

> Sorry, its Monday morning so I a bit slow. ;-)

No worries.  :)  I probably only actually wrote half a thought, since it's something that's been on my mind for a few years...[1][2][3][4][5] ;)

> What "tastes" do you want to put together? 

Great taste #1:  doing REST right, the way Roy intended through actually driving agent (human or otherwise) interaction with services completely through hypermedia state transitions with minimal a priori knowledge of the service.  It's easy to do this with humans because of the browser and, well, we can generally read and understand things.  However, it isn't so easy to do this with automated agents.  Most people take the easy way out, but the brain damage [2] isn't their fault, really... ;)

Great taste #2: Topic Maps identity concepts around PSIs, reification and merging

> And how?

The short answer is:  "I don't know.  If I did, I would've implemented it by now..." ;)

The longer answer is based on the short one.  What I've tried to do when designing XML vocabularies over the last few years was to try and separate the data description mark-up from the markup for hypermedia navigation.  Of course, then you need to have a good way to describe, as unambiguously as possible, what the state transitions can be so that you have loosely coupled applications: [3][4].

From [5]:

> XLink and XForms would be a good start, but you'd still need something
> to say a particular link was edit vs delete. That's where I was saying
> you might potentially apply something like a microformat (easy to
> detect/resolve/parse), or you could somehow link to a more semantically
> rich description of edit published somewhere in either XTM or RDF. For
> example, the published subject identifier for the 'edit' operation might
> be something like (for illustration, and because it's intended to be
> used by humans...)
> http://example.com/psi/interaction/operations.xtm#edit
> 
> Resolving that URI would get you both machine processable and human
> readable information that you could use to ensure you can implement
> understanding (e.g. hard-code) the logic in your agent that when it sees
> a link "tagged" or "associated" in some way (again, maybe it's a
> microformat, maybe it isn't), you can safely assume that following that
> link will provide your agent with a way to edit the representation
> identified by the URI present in the link.
> 
> I agree that the mechanism for association hasn't been fully defined,
> and that if you had to implement this as part of your application
> processing logic, it would be overkill. What I'm advocating, however,
> is that this infrastructure should be defined, standardized and made
> available to agent developers as both a specification and then
> corresponding - you guessed it - language-specific library APIs that
> would allow you to write your agents at a higher level of abstraction
> (resources and operations) rather than resources, URI templates and HTTP
> APIs.

I've explored this a few times with mixed results, but I haven't come up with a way that I'm entirely happy with yet.  There was one great discussion (same list) that I can't find now that was later than the above where I tried to have another go via illustration.  Based on the way things've gone over the last few years, I haven't managed to get back to it.  I touched on it a bit during TMRA last year with a few people, but I still don't have a great example in the wild that demonstrates what I want.

As close as I've come is to define an envelope with some well-defined elements representing actions and descriptors for those actions referenced in the markup that are PSIs so that automated agents can discover what actions can be performed and the programmers can implement some notion of the consequences of performing those actions.  I started to spec it once, then I got sidetracked.  It will come around again though as I'm needing to solve that kind of problem soon.

Where I was going with the original mail was that maybe the collective minds here can either highlight where they're already doing this, or we can conveniently integrate legitimate examples into our ongoing work.  The latter is my plan, but I've a few more things to do over the next month before I can get back to it with much effort.

Hopefully that goes a bit further to explaining what I meant.  2-4 (nearly 5!) years later, mainstream developers might actually be ready for some of this stuff, and it is potentially an opportunity not to be overlooked. :)

Cheers,

ast

[1] http://www.mail-archive.com/service-orientated-architecture-hHKSG33TihhbjbujkaE4pw@public.gmane.org/msg04423.html
[2] http://atownley.org/2006/12/is-rest-api-an-oxymoron/
[3] http://www.mail-archive.com/service-orientated-architecture-hHKSG33TihhbjbujkaE4pw@public.gmane.org/msg07459.html
[4] http://www.mail-archive.com/service-orientated-architecture-hHKSG33TihhbjbujkaE4pw@public.gmane.org/msg04501.html
[5] http://tech.groups.yahoo.com/group/service-orientated-architecture/message/10238
--
Andrew S. Townley <[email protected]>
http://atownley.org