Re: ldp-ISSUE-70 (simple LDPCs): simple LDPCs [Linked Data Platform core]

On 18 May 2013, at 13:00, "Linked Data Platform (LDP) Working Group Issue Tracker" <sysbot+tracker@w3.org> wrote:

> ldp-ISSUE-70 (simple LDPCs): simple LDPCs [Linked Data Platform core]
> 
> http://www.w3.org/2012/ldp/track/issues/70
> 
> Raised by: Henry Story
> On product: Linked Data Platform core
> 
> We need to explore if there is a way of solving the use cases we have with only simple LDPCs.
> Simple LDPCs would act nearly like directories on a file system:
> 
>   - they can list the members
>   - optionally metadata about the members (creation/update time, author, summary, quoted content )
>   - optionally the type of graphs that can be posted to the LDPC
> 
> An LDPC restricted to this would be something that could be shipped with web servers by
> default and would not require any ontology enginneer with advanced owl reasoning knowledge
> to verify its correctness. 
> 
>   Henry

Below is an example of how one can fill in the section "Keeping Track of Personal 
and Business Relationships"
  http://www.w3.org/TR/ldp-ucr/#keeping-track-of-personal-and-business-relationships
which I am working on myself. 

Which Use Cases do people think cannot be solved with a simple LDPC? 

Here is an example:

0. presupositions

   The collection http://myserver.net/joe/ has been set up and only joe's client has access 
to that directory.

1. Joe publishes his card by POSTing  the following to the collection

~~~~~~~~~~~~~~~
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix cert: <http://www.w3.org/ns/auth/cert#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<#me> foaf:name "Your Name";
     foaf:knows <http://bblfish.net/people/henry/card#me> ;
     cert:key [ a cert:RSAPublicKey;
                cert:exponent 65537 ;
                cert:modulus "C13AB88098CF47FCE6B3463FC7E8762036154FE616B956544D50EE63133CC8748D692A00DAFF5331D2564BB1DD5AEF94636ED09EFFA9E776CA6B4A92022BB060BF18FC709936EF43D345289A7FD91C81801A921376D7BCC1C63BD3335FB385A01EC0B71877FCBD1E4525393CCD5F2922D68840945943A675CCAE245222E3EB99B87B180807002063CB78174C1605EA1ECFECF57264F7F60CD8C270175A1D8DD58DFC7D3C56DB273B0494B034EC185B09977CBB530E7E407206107A73CD4B49E17610559F2A81EA8E3F613C3D3C161C06FE5CB114A8522D20DED77CAAA8C761090022F9CD4AF2C8F21DF7CF05287E379225AEA6A3A6610D02C4A44AA7CEED2CC3"^^xsd:hexBinary;
                ] .
~~~~~~~~~~~~~~~

as a result a GET on <http://myserver.net/joe/> reads

~~~~~~~~~~~~~~~
<> a ldp:Container;
   rdf:member <card> .

<card> foaf:maker <card#me>;
       atom:updated "2013-05-18T15:32:01Z"^^xsd:dateTime .
~~~~~~~~~~~~~~~
       

2. Perhaps later Joe wishes to publish a collection of pictures, so he can create a container 
for pictures by POSTing with the header "Slug: pix" the container

~~~~~~~~~~~~~~~
<> a ldp:Container;
   acceptContent "image/*" .
~~~~~~~~~~~~~~~

( Here we define the restriction of mime types one can post in terms of a yet undefined relation acceptContent .  I am not saying that is
the right way to do things, but one should consider it)

This creates the container and a GET on <http://myserver.net/joe/> reads

~~~~~~~~~~~~~~~
<> a ldp:Container;
   rdf:member <card>, <pix/> .

<card> foaf:maker <card#me>;
       atom:updated "2013-05-18T15:32:01Z"^^xsd:dateTime .

<pix/> a ldp:Container;
   acceptContent "image/*" .
~~~~~~~~~~~~~~~

3. It is easy to see how to POST pictures to the <pix/> container. 
Pictures can have mime type relations to describe them, so clients can know
what mime type they prefer. Perhaps after such a POST the <pix/> container says:

~~~~~~~~~~~~~~~
<> a ldp:Container;
   acceptContent "image/*" .
   rdf:member <mugshot1> .

<mugshot1> mime "image/jpeg","image/gif" ;
       atom:updated "2013-05-18T15:35:37Z"^^xsd:dateTime .
~~~~~~~~~~~~~~~

4. Now having posted that the user wants to add that relation to his card so he
PATCHES his </joe/card> to add the relation 

<#me> foaf:depiction <pix/mugshot1> .

 



  



Social Web Architect
http://bblfish.net/

Received on Saturday, 18 May 2013 12:14:53 UTC