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

Hi Lars & everyone else replying to the thread,

Apologies for the radio silence.  I've been on the road the last few days, and they tend to frown on typing emails while driving down the motorway if you're also doing the driving... ;)

More below:

On 23 Nov 2010, at 1:54 PM, Lars Heuer wrote:

> Hi Andrew,
> 
> [...]
>> All I was actually was presenting in the original mail was a
>> potential opportunity to remind people:
> 
>> a) There's this thing called Topic Maps, and we think it's pretty cool for these reasons, and
> 
>> b) we think this is how it might possibly be useful in making your
>> life easier as the designers, architects and implementers of
>> loosely-coupled information systems.
> 
> Let's focus on these points.
> 
> If I've
> 
>   <link rel="http://psi.example.org/father-of"
>         uri="http://www.example.org/sean"/>
> 
> Why should I create a mapping to Topic Maps if I can translate it
> directly into RDF's triples? Okay, we don't want a mapping, so we can
> simply enhance the link with attributes to make it mappish:
> 
>   <link rel="http://psi.example.org/father-of"
>         uri="http://www.example.org/sean"
>         this="http://psi.example.org/father"
>         other="http://psi.example.org/child"/>
> 
> Now we can create a binary association from the link specification:
> 
>    %prefix ex <http://psi.example.org/>
> 
>    ex:father-of(ex:father: <context-iri-here>,
>                 ex:child: <http://www.example.org/sean>)
> 
> That's all nice and good. But who would annotate the links with
> further attributes and why? I can directly translate the 1st link into
> a subject pred object triple.
> 
> Practically, I'll find more links in the wild which are as simple as
> the first link, so I need a mapping which creates the missing role
> types.

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.

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.  While this was one of the original use cases of RDF, in practice (and a few searches on google for the phrases that came to mind), I could find very little on applying RDF to this domain.

The link element has specific semantics defined by the various HTML specifications (HTML5 is here[1]).  Also, the only valid link types for HTML5 are defined in the specification[2].  For Atom, it's defined here[3].

If you want documents of either of these specifications to validate, you can't just add attributes to them in a higgldy-piggly manner--that being a very technical term, BTW. :)

Therefore, your basic premise of arbitrarily extending existing XML elements breaks down because if you're using any kind of controlled vocabulary, whether extension of the document is possible in this way is down to the document type.  Of course, you can reference an external DTD or other document type that ensures that these attributes are valid, but the point is that you shouldn't just augment elements the way you're suggesting above.

Second, as the original intent of my first mail was to describe the opportunity to provide guidance on how to orthogonally layer Topic Maps identity into existing Web standards, it makes little sense to talk about general knowledge representation.  What we're after (from the Atom spec) is:

	"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" />
	...

Where things get interesting is not in the GET case, but in the data manipulation case.  How does a user agent "know" how to interact with the given endpoints?  How do you know what parameters are required?  How do you know what input types are supported?  How do you know what HTTP verb to use?

These are the questions that must be answered if you are to use this or any other resource linking mechanism to fully support the hypermedia as the engine of application state REST criteria.

It isn't about augmenting the instance of the link element, it's about describing the target resource and the interaction semantics required to successfully navigate the hypermedia information space supported by the application.

Do you see where we're talking about different problems?

> 
> [...]
>> I'm sure you've had this feeling with the work you've mentioned
>> doing on dbpedia dumps, but why should we have to do this.  Why are
>> we, a very small community, trying to absorb the work of helping
>> everyone else make sense of this information landfill we see and
>> experience every day through the window of Google's search box?  Why
>> can't we distribute this effort--just like the Web?
> 
> If you want to be the Topic Maps poster boy, go ahead. ;)

I'm not volunteering, but I'm not missing opportunities to discuss where I see value in applying the technology to solve real-world problems.  It's like any organization, but particularly a startup:  everyone is part of the sales team, whether they know it (and like it) or not.  If you believe something has value, promoting it should never be left as "that's someone else's job" or it will never get anywhere.

People may still choose to reinvent certain wheels, but at least they should be making that conscious decision to do so with as much information as possible and a clear understanding of why they think it's necessary.  There are, in fact, times when this makes sense.

> I just wondered why people should extend the links if the links work
> for important technologies like RDF/LOD. I simply doubt that they
> change it just because a few people on this planet like to see it more
> Topic Mappish.

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.

Hopefully, this helps you understand why I started the thread in the first place. :)

Cheers,

ast

[1] http://www.w3.org/TR/html5/semantics.html#the-link-element
[2] http://www.w3.org/TR/html5/links.html#linkTypes
[3] http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.link
--
Andrew S. Townley <[email protected]>
http://atownley.org