Re: proposal on ldp:profile ( Issue-48 ) -- was: Discovery/Affordances (Issue-32/Issue-57)

On 11 Jun 2013, at 17:20, Arnaud Le Hors <lehors@us.ibm.com> wrote:

> Hi Henry, 
> 
> Henry Story <henry.story@bblfish.net> wrote on 06/10/2013 11:57:22 PM:
> 
> > >> I see this is as a simple marker that doesn't require much anything else
> > >> than be defined in the spec as a way the server can advertise it is
> > >> supporting LDP.
> > 
> > I think the problems in our discussions comes from this way of 
> > phrasing things, 
> > as it confuses two seperate topics:
> > 
> >   a) how do you know a resource is an LDPC/LDPR ? ("that it is 
> > supporting LDP")
> >   b) how do you constrain what types of resources can be member of an LDPC .
> > 
> > The profile is doing the second thing (b) 
> > ...
> 
> I don't understand why you pick that particular constraint and decide that this is what the LDP profile would be about. 
> 
> This is especially confusing because there is no such constraint that I know of in LDP today. Any type of resource can be a member of an LDPC. 
> 
> And this is not at all the what I'm hearing people say about why they want something to identify LDP resources beyond RDF.

Do you mean constraint (b) ?
I explained that in the paragraph that followed right after the piece of my e-mail that you cut.

I cite RFC6906 entitled "The 'profile' Link Relation Type" which is written by a certain 
E. Wilde of EMC Corporation, which our Erik Wilde linked to in the mail I was responding to  
  http://tools.ietf.org/html/rfc6906
The end of the introduction has the following text

[[
   As one example, consider the case of podcasts, where a specific kind
   of feed uses additional fields for media-related metadata.  Using a
   'profile' link, it would be easily possible for clients to understand
   that a specific feed is supposed to be a podcast feed, and that it
   may contain entries using podcast-specific fields.  This may allow a
   client to behave differently when handling such a feed (such as
   rendering a podcast-specific UI), even when the current set of
   entries in the feed may not contain any podcast entries.  (
   Section 5.3 gives more details for this example.)
]]

this passage was also cited by Kingsley Idehen in the thread 
"Discovery/Affordances (Issue-32/Issue-57)"
http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jun/0085.html

If you read this carefully it is clear that the aim of this profile
is to constrain the type of elements that appear in a podcast feed.

I have often heard Erik Wilde ask for such constraints. They can 
be useful in that you may want a LDPC to be a place people POST 
specific types of RDF graphs, eg:

  - card addition events
  - shopping orders
  - bug report additions
  - etc....

Furthermore it is not the first time that Erik Wilde makes this
request. In Issue-48 I point to a few places where he voiced
this request. I happen to think it is not a bad idea.
  http://www.w3.org/2012/ldp/track/issues/48

Does this help, or have I missed something?

Henry

Social Web Architect
http://bblfish.net/

Received on Tuesday, 11 June 2013 15:41:49 UTC