W3C home > Mailing lists > Public > public-ldp-wg@w3.org > November 2013

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

From: Henry Story <henry.story@bblfish.net>
Date: Sat, 23 Nov 2013 22:14:55 +0100
Message-Id: <741C917D-FE6A-444A-B96F-610FBAB6E6B4@bblfish.net>
To: "Linked Data Platform (LDP) Working Group" <public-ldp-wg@w3.org>

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/
Received on Saturday, 23 November 2013 21:15:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:53 UTC