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

Hi Erik,

On Sat, Jan 26, 2013 at 12:40 PM, Wilde, Erik <Erik.Wilde@emc.com> wrote:

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

Yes; by "capturing the constraints", I was mostly considering describing
those constraints in the LDP recommendation, as anyway there is no way
(that I know of) to formally describe them.

Another nice thing that I like about profiles is that they are orthogonal
to content-types. So the LDP profile could be used with various RDF
serialization, not just with turtle.

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

For the moment, I don't see any need to specify it anywhere else than in
the HTTP headers.

And even if we wanted to specify it in the RDF graph, nothing prevents us
from defining an IRI ldp:profile with the same meaning as the RFC5988-Link
"profile". Of course, a better solution would be to have a common IRI
prefix for all link relation types registered according to RFC 5988. But
defining it is obviously out of scope for this WG.

  pa


> cheers,
>
> dret.
>
>