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

In the mean time I have implemented MKCOL on my server, and it works 
nicely. The great thing is that is it all nicely documented, following as it
does a famous IETF standard. So at least I have a solution ready now.

https://github.com/read-write-web/rww-play/blob/master/app/org/www/readwriteweb/play/ReadWriteWeb.scala#L89

But I am following the discussion here with interest...

On 26 Jan 2013, at 20:50, Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr> wrote:

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

Its not just a nice thing, it's essential.  The mime type extension idea was clearly 
a big "attrape-nigaud"@fr .

The idea of a link type or another header is a quite reasonable idea, since
HTTP headers are just relations describing the content in a pretty old 
fashioned Property Value Syntax. Property of what? The resource or a 
particular state of the resource of course.

So one could create a ldp relation for that profile, and it would be interesting
to thing about how one could define a profile semantically.  In the semantic
web we already have a few profiles like this, though they are not 
well defined such as the foaf:PersonalProfileDocument .
 
One could define these by for example relating them to SPARQL queries which
such profiles ought to be able to answer. The one could associate profiles
with any sort of content whatever.

Futhermore one can define links by URIs, so it is very flexbile.

Link: </>; rel="http://example.net/foo"

I agree with Kingsley though that such a profile, should be linked data,
and hopefully the descriptions for a profile should be machine processable
(using SPARQL or some well know standard )

I think one could even start immediately with the following relation

Link: <http://www.w3.org/ns/ldp#Container>; rel="http://www.w3.org/1999/02/22-rdf-syntax-ns#type"


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

Social Web Architect
http://bblfish.net/