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

Henry,

I understand what the example you cited is about. I just don't understand 
what this has to do with the problem we are trying to solve. I don't 
believe this example represents the only possible use of profiles.

The question isn't "oh, we've got a tool called profiles, what could we do 
with them?" and then imagine what we might do with them. The question is: 
"how can one find out the LDP interaction model is applicable from the 
HTTP layer, without creating a new mediatype". I believe one possible 
answer is to use an LDP profile.

Given Erik's response to my earlier message I have no reasons to believe 
he has a problem with the way I propose to use profiles. If that's not the 
case I'm sure he will let us know.

The problem we are discussing is primarily a matter of nailing down how 
one finds out whether the LDP interaction model is applicable. This is 
orthogonal to what you're talking about. I know that from your point of 
view the interaction model is tied to the LDP vocabulary but we've heard 
loud and clear that others don't want to do that. So I'm looking for a 
compromise where both groups can use LDP the way they want.

I've put forward a very simple proposal. Please, just take it for what it 
is.

If you could only accept that this marker is harmless to what you want to 
do - as I said you can ignore it if you want - and people like Alexandre 
think it solves their problem we could be done with this and move on.

Regards.
--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group


Henry Story <henry.story@bblfish.net> wrote on 06/11/2013 08:41:18 AM:

> From: Henry Story <henry.story@bblfish.net>
> To: Arnaud Le Hors/Cupertino/IBM@IBMUS, 
> Cc: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
> Date: 06/11/2013 08:47 AM
> Subject: 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 ofan 
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/
> 
>