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

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

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


I this e-mail here http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jun/0084.html
I asked "what is the profile adding?"
You then answered that you don't really know what it is, but that Erik Wilde would know.
Then he directly quoted RFC6906

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

Why do you say I imagine a use? I clearly don't: I used the example in the spec Erik Wilde pointed
us to when I asked for clarification on what profiles are.


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

So perhaps you can go back to my example, and tell me why it does
not do that. http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jun/0090.html

What is the interaction model issue you want to make explicit?

> 
> 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 only thing we have to go on about his idea of use of profiles is his RFC6906. 
When we then use that, you tell us we should not. Is this just a blank check for
Erik Wilde to put anything in here, even if nobody understands, or can we perhaps build 
something here?

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

My example showed how one can explain one interaction model: how one can let
the client know that he should only POST certain types of documents to an LDPC.

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

If I don't know what they want to do, how can I know if it is harmless?

I thought I knew what they wanted to do, and I tried to make that explicit
here: 

  http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jun/0090.html

What was wrong with that? 

Also this has nothing to do with headers or not. If you can put it in the body, you
can always also put it in a Link Header.


Henry

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

Social Web Architect
http://bblfish.net/