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

hello pierre-antoine.

On 2013-01-25 19:54 , "Pierre-Antoine Champin"
<pierre-antoine.champin@liris.cnrs.fr> wrote:
>At the risk of joining you on the stake, I find this interesting as well.
>However, I think Erik's proposal in another thread, to use the notion of
>profile [1], sounds like a more general approach to me: the client may
>not only expect the primaryNode to
> be of the primaryType. It will also expect that the primaryNode will
>have a number of "mandatory" properties. This kind of constraint may be
>captured by the notion of profile.

yes, that's what this mechanism is supposed to do. the (original) idea was
to make the specialization of media types a bit more self-describing,
without requiring all specializations to mint new media types. the
mechanism is fairly simple and general, and in particular only talks about
how to signal specializations (by using "profile" links), and not how to
define/describe them (the link target does not have to be dereferencable,
it's just an identifier).

come to think of it, currently this is very much a web-targeted spec,
defining and registering the "profile" link relation in the RFC 5988
registry. thus this will create the usual problem of how to use registered
link relations (which are strings and not URIs) in RDF. if LDP was going
the profile route, which might serve as a blueprint for other RDF-based
specs that also want to expose more information through the uniform
interface, would we only use HTTP headers for this, and thus the string
identifier would suffice?

cheers,

dret.

Received on Saturday, 26 January 2013 11:41:13 UTC