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

On 11/23/2013 05:59 PM, Ashok Malhotra wrote:
> If we are brainstorming, then why not consider a URI scheme
> where  LDPC-URI#n retrieves the nth member of the container?

This approach would clash with a potential <#n> in the LDPC
representation. Of course, we could define a service as a new possible
interaction for an LDPC, but I think we should resist the temptation
of adding plenty of small additions for small use-cases.

LDP already defines too many of those and makes the technology not as
modular as it could be. It's inherited from the Submission and the
desire of not depending of SPARQL for the pre-existing use-cases. The
fact is that all are subsumed by SPARQL (eg. ordering,
ldp:membershipXXX, etc).

The good thing is that SPARQL is well-defined and well understood as a
technology. If the LDP data model says exactly where things are and
how they are connected together, then it's easy to handle your
use-case, as well as many others.

Alexandre.

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

Received on Saturday, 23 November 2013 23:16:18 UTC