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

Hi Andrew,

[...]
>> 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.


[...]
> 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.


[...]
> 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/>

Best regards,
Lars
-- 
Semagia 
<http://www.semagia.com>

<http://www.topicmaps.de/mailinglist/> German Topic Maps mailing list
<http://tinytim.sourceforge.net/> Open Source Topic Maps engine
<http://mappa.semagia.com/> Mappa - Python Topic Maps engine