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

* 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 dute.


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



> cheers,
> 
> dret.
> 

-- 
-ericP

Received on Friday, 25 January 2013 15:55:22 UTC