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

Hi Lars,

On 26 Nov 2010, at 11:38 AM, Lars Heuer wrote:
> [...]
>>> 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).
> [...]
>> Seriously, though.  There were two reasons for trying to do it that
>> way.  First, it was to make it more obvious what kinds of things
>> were at the other end, but the second was to do this in a way that
>> applied a little syntactic sugar.
> 
> I see. Well, my rationale behind shying away of encoding accepted
> media types in the "rel" IRI is flexibility. If the resource
> <http://psi.example.org/create> provides information that the endpoint
> accepts POST requests and the request body must be encoded in
> application/xml, I cannot reuse the IRI if I accept application/json
> only or if my service evolves and accepts application/json *and*
> application/xml.
> 
> If the accepted media types are not encoded in
> <http://psi.example.org/create> I have more possibilities. I can reuse
> it as "rel" value for all services which accept POSTs.

Yes, you're right.  I seem to have blurred two things together there.  You need a clear separation between the what (semantics of the operation) and the how (the interaction model).

I also didn't read what you wrote very well either.  What I was talking about with the syntactic sugar was simply to make it obvious that the thing on the other end of the "rel" attribute was a Topic Maps PSI.  For that part of the discussion at least, I wasn't talking about the interaction model.

I still think that you could somehow derive the rest based on the value of the endpoint via either querying a registry/repository based on the PSI of the operation and the URI of the endpoint, or by supporting some kind of header returned via GET or HEAD requests that pointed you to the description of the interaction model for that resource.

> [...]
>> Independent of any of the above, the primary intent is to dovetail
>> easily into the existing extension points with a minimal amount of
>> disruption.  If RDFa has this interpretation of delimited values as
>> triples, then we need to either define something complimentary or,
>> as you suggest, avoid it entirely.
> 
> Well, my explanation of the whitespace delimited IRIs/QNames was not
> very good. RDFa treats multiple IRIs/QNames as multiple statements, i.e.
> 
>  <div about="http://psi.example.org/Joe_Cocker">
>     <span rel="rdfs:seeAlso foaf:page"
>          resource="http://en.wikipedia.org/Joe_Cocker"></span>
>  </div>
> 
> 
> represents the following statements (using QNames instead of IRIs):
> 
>   ex:Joe_Cocker rdfs:seeAlso wp:Joe_Cocker.
>   ex:Joe_Cocker foaf:page wp:Joe_Cocker.

Yuck.  That's worse than microformats!!  At least with them you have a single intersection point (in the "class" attribute) between the resource markup and the properties about the subject(s) described in the resource to keep things orthogonal.  Someone must have seriously been doing the bad drugs when they came up with the XML syntax above...

> [...]
>> Yep, and not only that, if people actually decided that they could
>> be more expressive or more precise using Topic Maps, then there's
>> already a well-defined mechanism in place for them to build upon. 
>> It's a win-win as far as I see it.
> 
> I agree. Maybe it's worth to evaluate OWL-S [1] [2].
> 
> OWL-S: Semantic Markup for Web Services
> [1] <http://www.w3.org/Submission/OWL-S/>
> [2] <http://www.daml.org/services/owl-s/>


Wow.  That's a blast from the past!  I hadn't looked at those since 2005...

In theory, yes, it is intended to do what I describe.  However, I think it would take the following changes to make it broadly useful:

1) Remove all dependencies on XML and SOAP from the specification
2) Remove the programming-language-defined-in-XML-attributes bits
3) Convert the core concepts to a set of well-defined and documented PSIs
4) Define a generalized mechanism to tie the interaction model to an endpoint (only one of which might be as WSDL stored in a R/R)

As it is, I think it's too big and tries to do too much.  It's also buried in a number of assumptions that presuppose WS-* Web services vs. the real Web.

However, it would be fertile ground with many of the seed concepts already in place and use cases considered from which to start.

Thanks for the reference! :)

Cheers,

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