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

Andrew,

No answers but a thought or two.

The LOD crowd seems to now think the person who is aggregating data is
responsible for making sure they are getting the subjects they want. 

The problem being how do you and I apply the *same* rules for the
subjects we "recognize?"

Moreover, how do we interchange those rules, reliably, if we decided to
do so? 

Granting there is no absolute guarantee that we will get the same
subjects but there are some things that would help:

1) State what properties being present in an RDF graph identify a
subject of interest. (ignore URI for identity purposes, unless you are
using it for processing *after* having satisfied yourself of the
subject's identification)

(I suppose you could use a SPARQL query to define the query, which if
successful, identifies a subject.)

2) For subjects where the Web doesn't "scale" (think Large Hadron
Collider, All sky surveys, US case law (think of all the associations
within a single case), and all manner of other "dark" data), use
whatever "set of properties" declarations are available and define some
set as "identifying" subjects of interests.

3) For subjects already subject to query languages (like SQL), use
existing query language to specify property sets that identify
subjects. 

When going between private data sets it will probably (always?) be
necessary to declare the properties that identify the subjects
represented by keys in order to obtain reliable subject identification. 

For public data sets (or at least those accessible publicly, it may be
possible to declare the keys publicly. Granting that keys aren't used
consistently in data systems but that's another issue. 

Hope you are having a great day!

Patrick

PS: If you know the US TV series M*A*S*H, this should be known as
"meatball semantics." It's not perfect but perfect means we can't
deliver a useful answer in a timely fashion.


On Mon, 2010-11-22 at 17:27 +0000, Andrew S. Townley wrote:
> 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
> _______________________________________________
> topicmapmail mailing list
> topicmapmail-Zo64W7twoUFWk0Htik3J/[email protected]
> http://www.infoloom.com/mailman/listinfo/topicmapmail