- From: Henry Story <henry.story@bblfish.net>
- Date: Tue, 11 Jun 2013 17:41:18 +0200
- To: Arnaud Le Hors <lehors@us.ibm.com>
- Cc: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
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