Re: Discovery/Affordances

On 6/10/13 12:04 PM, Henry Story wrote:
>
> On 10 Jun 2013, at 17:18, Arnaud Le Hors <lehors@us.ibm.com 
> <mailto:lehors@us.ibm.com>> wrote:
>
>> Hi,
>>
>> We all agree that somehow a client needs to be able to figure out it 
>> is dealing with an LDP server. The argument seems to be about how the 
>> client makes that determination. From what I've seen we have two 
>> groups of people.
>>
>> One group thinks that RDF provides all the client needs. The RDF 
>> typing a la ldp:Container is the indicator. I believe this would mean 
>> that an LDPR must also be typed with something LDP specific but I'll 
>> leave that out for now.
>
> That's me
>
>>
>> The other group argues that this is something the client should be 
>> able to figure out just from the information contained in the HTTP 
>> layer. Using a new mediatype would be one way to do that. It could be 
>> a new mediatype entirely or one derived from existing mediatypes 
>> using the profile mechanism.
>>
>> I believe both techniques can work but they have different pros and 
>> cons. 
>
> The second technique contains 2 different proposals, one of which I am 
> for the other against.
>
> I argue strongly against using mediatypes as it is mistaking syntax 
> with semantics. Simply put: the content in bytes sent from the server 
> to the client
> is known as a representation of the resource ( it has a syntax defined 
> by its mime type ) One CANNOT apply the method
> GET/POST/DELETE, etc on a representation - a stream of bytes - one can 
> only do that on a resource, which is what the
> URI ( Uniform Resource Identifier ) refers to in  { <> a ldp:Container }
>
> But I am not against using HTTP headers to express something about the 
> resource that is the container.
> As it turns out one can use the Link relation to do that with  ( 
> http://tools.ietf.org/html/rfc5988 )
>
> Link: <http://www.w3.org/ns/ldp#Container>; 
> rel="http://www.w3.org/1999/02/22-rdf-syntax-ns#type"
>
> Perhaps we could do the HTTP/RDF community a favor to register the 
> relation
> http://www.w3.org/1999/02/22-rdf-syntax-ns#type to the shorthand 
> "type" so that
> the above could become
>
> Link: <http://www.w3.org/ns/ldp#Container>; rel="type"

+1

>
>> Here is my analysis:
>>
>> Relying on RDF alone has the advantage of not requiring anything new 
>> at the HTTP level. On the other hand it requires everything to be 
>> typed for LDP specifically and it ties the interaction model to the 
>> LDP vocabulary which can be seen as limiting. 
>
> Why would that be limiting? And why should we care if people wrongly 
> see it to be tied to ldp vocabulary?
> Other vocabualries can be invented and add more restrictions, that's 
> just the nature of RDF.

+1

>
>>
>> For instance, if I happen to retrieve some LDP content from an LDP 
>> server and decide to store it into a vanilla, non-LDP enabled, triple 
>> store a client accessing that triple store would be misled to think 
>> it is talking to an LDP server when it's not. The counter argument to 
>> this is that this is simply something one shouldn't do: one shouldn't 
>> serve LDP content from a non-LDP server.
>
> exactly. That is no different than if an IBM employee mistyped a form 
> on IBMs e-commerce site. We don't try to make
> forms meaningless in order to avoid such accidents happening. We 
> rather give forms a meaning in human readable
> text surrounding it, and then set up test suites and feedback 
> mechanisms to catch errors.

+1

>
>>
>> Relying on HTTP to provide the indicator that this an LDP server has 
>> the advantage of allowing the LDP interaction model to be applied on 
>> resources that are not specifically typed for LDP (the spec doesn't 
>> currently require typing of LDPRs). It also allows LDP content to be 
>> served by non-LDP servers without implying support of the LDP 
>> interaction model.
>
> But then you have just pushed the problem one little step further 
> along, because however you describe your
> interaction model, once you allow it to describe something - ie to 
> make some distinction in the world -
> then you inevitably allow the distinction to be made truely or 
> falsely, ie for the description to correspond
> to the way the world is or not.  So your distinction will imply 
> support of some interaction model then, and you'll have the
> same problem.

+1


>
>>
>> On the other hand this requires defining something beyond the 
>> existing RDF mediatypes already in use for non-LDP purposes. Defining 
>> a new mediatype entirely or as a profile seems pretty heavy to me. 
>> But that's not the only way. Another way to communicate that the 
>> server supports the LDP interaction model would be to add an HTTP 
>> header. One such possibility would be to have a Link header with a 
>> rel=profile and a link to an LDP specific profile a la 
>> http://www.w3.org/ns/ldp/profileas the target.
>
> So as argued above you can use the Link header and also use the 
> ldp:Container there in the same
> way as you do with the body. What is the profile adding?
+1



> What vocabulary would need to be used to
> describe the profile?  Do we need this now or can we add it later? 
>  Unless those questions are answered
> this seems like a lot of work to do when we can just use ldp:Container 
> to mean: you can POST to this
> container.

+1


Kingsley
>
>>
>> According to Erik while this isn't common (the spec is very recent) 
>> it would be reasonable.
>>
>> I think this is the way we should go. If some people want to ignore 
>> the Link header they are welcome to do so and it is there for those 
>> who care.
>>
>> Comments?
>>
>> Thanks.
>> --
>> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
>
> Social Web Architect
> http://bblfish.net/
>


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen