Re: ISSUE-36: Summary of ways of making containers

hello eric.

On 2013-01-25 16:54 , "Eric Prud'hommeaux" <eric@w3.org> wrote:
>* Wilde, Erik <Erik.Wilde@emc.com> [2013-01-25 10:29-0500]
>> hello eric.
>> 
>> On 2013-01-24 19:30 , "Eric Prud'hommeaux" <eric@w3.org> wrote:
>> >text/ldp-container+turtle
>> >text/ldp-resource+turtle
>> >and of course the bastard combo text/ldp-cresource+turtle
>> 
>> please keep in mind that you don't have to (and in fact shouldn't)
>>define
>> a new media type for each "kind" or resource you're exposing. the media
>> type identifies the protocol, and thus covers whatever "kinds" of
>> resources you are exchanging in the scope of the protocol. for
>> understanding what you're actually dealing with, REST says that
>>resources
>> need to be "self-describing", and in the REST sense of this word in this
>> context, this simply means that you look at the "protocol identifier"
>>(the
>> media type) and the resource (the "payload"), and then you know what
>> you're dealing with.
>yeah, these were mostly tongue-in-cheek media types, intended to
>illustrate that we might have some things which do double duty.

i wasn't quite sure, so i fell for it ;-) but you're actually close to
what a lot of people would suggest: if you define and expose new ways of
interactions that clients and servers can engage in, make them
identifiable on the level of the uniform interface, i.e. as a media type
that's exposed in HTTP.

>>some media types (such as atompub, see
>> http://tools.ietf.org/html/rfc5023#section-12.1) have felt the need (for
>> protocol reasons) to make resource "kinds" identifiable in the media
>>type,
>> but then the preferred route is to use media type parameters instead of
>> minting individual media types.
>interesting point. the Turtle media type currently has only a charset
>optional parameter. it could also have, e.g. (flame bait follows):
>  primaryType ‹ this parameter identifies the intended purpose of the
>  graph encoded in a Turtle document. This could be, for instance, a
>  product description or a purchase order.
>this would invite also a primaryNode.
>some folks here might find that a practical way to route messages to
>the appropriate handler. the RDF WG, which pretty much owns the media
>type, may well burn me as a heretic for even proposing this.

that's a different way to approach the issue i guess. i'd argue that a
profile covers this, just on a more abstract level. a profile is just an
identifier (just like a media type), and anybody recognizing this
identifier would have knowledge on what the capabilities are in a
conversation where the context is identified by that profile. part of that
knowledge would be the protocol definition of what matters in the
conversation on the protocol level, and that may come close to your
"primaryType".

cheers,

dret.

Received on Saturday, 26 January 2013 11:31:14 UTC