Re: ldp-ISSUE-57 (LDP Service ID): How can a client determine that it is in communication with an LDP service? [Linked Data Platform core]

On 3/15/13 2:35 PM, Wilde, Erik wrote:
> hello david.
>
> On 2013-03-15 10:35 , "Linked Data Platform (LDP) Working Group Issue
> Tracker" <sysbot+tracker@w3.org> wrote:
>> ldp-ISSUE-57 (LDP Service ID): How can a client determine that it is in
>> communication with an LDP service? [Linked Data Platform core]
>>
>> I contend that several possible communications between client and LDP
>> server would benefit from a client knowing that it is speaking with an
>> LDP service.  If that statement turns out to be true, LDP servers may
>> wish to advertise their LDP compliance (e.g. via an HTTP header).
> absolutely agreed, and i hate to sound like a broken record again, but
> that header would be the Content-Type header. speaking LDP should be
> exposed at that level (so that any HTTP client can find out).

Yes, this is where the conflation issue could be addressed using the 
content-types suggested for RDF (Lite) based Linked Data.

If, for instance, it returns "application/ld+turtle" the client 
understands that it is dealing with RDF based Linked Data in Turtle format.

>   it seems
> that the group majority dislikes the idea of a media type, but there's
> still the possibility to use a profile (if RDF media types were updated to
> support a profile media type parameter).

Media types will do.

>
>> A client will need to discover (either via a discovery mechanism or a
>> priori) a URL to POST, PUT or PATCH an LDPR.  It will also need to know
>> the formats it can POST, PUT or PATCH and any server version restrictions
>> (e.g. whether a particular server supports modifications to the PATCH
>> format).  Those particular concerns may be addressed by the answers to
>> ISSUE-17 and ISSUE-56.
> one thing is exposing LDP as a service on the web level (Content-Type).
> the next one would be to expose a home resource providing those
> affordances that you are mentioning. this is a very common pattern for any
> web service, and thus
> http://tools.ietf.org/html/draft-nottingham-json-home is trying to come up
> with a way how to expose this home resource. the current representations
> of this model are JSON and XML, but deriving RDF from it would be a simple
> mapping exercise.

I think it would be the other way round i.e, expressing the entity 
relationship semantics using the RDF model. Once that's in place the 
syntax notations and serialization formats will just slot it, and by 
that I am including the suggested media types for RDF based Linked Data 
that reflect the loose coupling of RDF and Linked Data.

>
> in case somebody wan to see the draft's JSON example in XML, here it is:
> https://github.com/dret/I-D-1/blob/dret/home-schema2/json-home/home-documen
> ts-03.xml
>
>> However, a client may POST, PUT or PATCH a binary object to an LDPC and
>> MAY (in accordance with ISSUE-15) get back both Location: and Link:
>> headers in a 201 Created response.  The client will not know how to deal
>> with the possible Link: header, nor its relationship to the binary
>> object's URI, unless it knows that the server is an LDP server.
> but that's fine as long as the context of where the client found the link
> clearly indicates that the client is about to engage in a LDP interaction.
> and it absolutely should be doing this by providing a typed link that
> identified the LDP interaction semantics.

That's really the whole point of RDF based Linked Data. By looking up a 
Link that denotes a Relation you end up with a graph that describes its 
semantics. This graph is human and machine comprehensible since all it 
does is explain how two things are related.

## Turtle based RBox examples ##

<http://www.w3.org/2002/07/owl#sameAs> a 
<http://www.w3.org/2002/07/owl#TransitiveProperty> .
<http://xmlns.com/foaf/0.1/mbox> a 
<http://www.w3.org/2002/07/owl#InverseFunctionalProperty> .
<http://xmlns.com/foaf/0.1/gender> a 
<http://www.w3.org/2002/07/owl#FunctionalProperty> .

## End ##

>
>> It seems to me that these concerns would be best addressed by the server
>> advertising via an HTTP header that it supports a particular version of
>> the LDP spec.
> mostly, people in REST try to steer clear of putting versioning into
> headers (i.e., media types) and instead try to version the vocabulary.
> that is unless you introduce breaking changes, at which point you're
> essentially creating a new media type.
> http://www.mnot.net/blog/2012/12/04/api-evolution describes this nicely.

Nobody likes placing literal identifiers into new HTTP headers, when the 
problem addressed by URI based entity identifiers, entity types, and 
entity relationship semantics surfaces. Basically, It doesn't scale, and 
the concern predates the REST moniker :-)
>
> cheers,
>
> dret.
>
>
>
>


-- 

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