Re: ldp-ISSUE-90 (Named Graph): An LDPC/LDPR is a Named Graph [Linked Data Platform Spec]

On 23 Nov 2013, at 23:59, Ashok Malhotra <ashok.malhotra@oracle.com> wrote:

> If we are brainstorming, then why not consider a URI scheme
> where  LDPC-URI#n retrieves the nth member of the container?

That cannot be implemented in HTTP. A #n URI cannot be passed over HTTP.
Requests in HTTP MUST remove the fragment identifier, before making a request.

Henry

> All the best, Ashok
> On 11/23/2013 4:14 PM, Henry Story wrote:
>> On 22 Nov 2013, at 22:22, Linked Data Platform (LDP) Working Group Issue Tracker <sysbot+tracker@w3.org> wrote:
>> 
>>> ldp-ISSUE-90 (Named Graph): An LDPC/LDPR is a Named Graph [Linked Data Platform Spec]
>>> 
>>> http://www.w3.org/2012/ldp/track/issues/90
>>> 
>>> Raised by: Alexandre Bertails
>>> On product: Linked Data Platform Spec
>>> 
>>> An LDPC/LDPR acts as a Named Graph (now defined in RDF 1.1 [1]). An HTTP GET on an LDPR URL should return its representation, and *nothing* else.
>>> 
>>> The specification currently says:
>>> [[
>>> 4.3.3 LDP servers MUST provide a text/turtle representation of the requested LDPR [TURTLE].
>>> ]]
>>> 
>>> I propose that the specification explicitly refers to RDF Named Graphs and makes the constraint on the GET explicit.
>>> 
>>> This does not prevent one to later define a service (eg. SPARQL) which would allow a user to retrieve the representations of an LDPC and its LDPR in one single request.
>> ==== warning: future think! (slightly off topic, looking for ideas)  ======
>> 
>>  Thinking along these lines made me realise that  I don't think one could POST something
>> to an LDPC to query a resource, as this should create a new resource with the right
>> content-type. It follows that a bit  like for PATCH a new HTTP verb will be required
>> in the future. Something like SEARCH which  seems to have been considered in 1992
>> 
>>   http://www.w3.org/Protocols/HTTP/Methods.html
>> 
>> I would not mind implementing something along those lines to try things out. Though feedback
>> is welcome.
>> 
>> So I'd imagine in a future spec one could do something like
>> 
>> ~~~~~~~~~~~~~~~~~~~~~
>> SEARCH /container HTTP/2.0
>> Host: localhost:443
>> Content-Type: application/sparql-query
>> Accept: application/sparql-results+json
>> 
>> SELECT ?member
>> WHERE {
>>   <> ldp:xyz ?member .
>> }
>> ~~~~~~~~~~~~~~~~~~~~~~~
>> 
>> One could imagine something even more advanced such as
>> 
>> ~~~~~~~~~~~~~~~~~~~~~
>> SEARCH /joe/likes HTTP/2.0
>> Host: localhost:443
>> Content-Type: application/sparql-query
>> Accept: application/sparql-results+json
>> 
>> prefix foaf: <http://xmlns.com/foaf/0.1/>
>> CONSTRUCT {
>>   </joe/card#i> foaf:likes ?topic .
>> } WHERE {
>>   <> ldp:xyz ?member .
>>   ?member a ldp:Graph .
>>   GRAPH ?member {
>>     ?member foaf:primaryTopic ?topic .
>>   }
>> }
>> ~~~~~~~~~~~~~~~~~~~~~~~
>> 
>> 
>> 
>> ========================================
>> 
>>> Also, all the examples (eg. 1, 2, 9, etc.) with GETs on LDPCs must not return the content of the "contained" LDPRs. They should be rewritten in terms of several GETs, one for the LDPC and one for each LDPR.
>>> 
>>> Alexandre.
>>> 
>>> [1] http://www.w3.org/TR/rdf11-concepts/#dfn-named-graph
>>> 
>>> 
>>> 
>> Social Web Architect
>> http://bblfish.net/
>> 
>> 
> 
> 

Social Web Architect
http://bblfish.net/

Received on Sunday, 24 November 2013 11:12:52 UTC