Proposed Use Case 1: Retrieve RDF representation of a BPR

I have looked into developing a single use case to see how the new structure will work. Working with the first user story, "Maintaining Social Contact Information", I developed the simplest use case (Retrieve RDF representation of a BPR). This will be common to many of the user stories and corresponds to a simple BPR GET in the LDP submission. Working through use-cases in this way should raise issues that can be discussed on the call. 

The issues identified include whether or not BPR URIs are resolvable, and if the LDP should compute owl:sameAs Closure to support merging of contact details as described in the user story.

Apologies in advance - I can't make the next call (2012.09.10) but I'd love to see discussion of these issues.
I'll hold off adding the use-case to the wiki until these issues are discussed.

Steve.


==User Stories==
===Maintaining Social Contact Information===
...
====Analysis====
The user story includes the the following functional requirements:

* A user should be able to read contact details so that they are able to interact with a contact. This is an example of use-case UC1: Retrieve RDF representation of a BPR.
** It should be possible to merge contact information, "Regardless of whether a contact collection is my own, [or] shared."

==Use Cases==
===UC1:  Retrieve RDF representation of a BPR===

The LDP server accepts a GET request for a particular Basic Profile Resource URI, returning an RDF representation comprising triples relevant to that BPR. The request accept header specifies the required media type for the returned RDF serialization.

===Actors===

User, LDP server

===Assumptions===

The user is authenticated (enterprise user authentication).

==== Steps ====

In the simplest case, the BPR is a directly resolvable HTTP resource:

# The client performs a GET request on a URI identifying a resolvable HTTP resource. If the client requires a Turtle representation, then it provides an accept header requesting media type "text/turtle".

# The user is authorised to view information about the requested resource.

# The server answers with a HTTP response code 200 OK and returns the requested representation, describing the BPR in the requested format.

====Scenarios====

The LDP holds social contact information about Alice and Bob, and the client requests contact details for Alice.

:alice a foaf:Person;
   rdfs:label "Alice";
   foaf:mbox <mailto:alice@example.com>;
   foaf:knows :bob.

:bob a foaf:Person;
   rdfs:label "Bob";
   foaf:mbox <mailto:bob@example.com>.

The /people/alice.rdf BPR is a resolvable URI; it is not to be confused with /people/alice

GET /people/alice.rdf HTTP/1.1
Host: example.com
Accept: text/turtle

The response should describe Alice, but not Bob :

HTTP/1.1 200 OK 
Content-Type: text/turtle

:alice a foaf:Person;
   rdfs:label "Alice";
   foaf:mbox <mailto:alice@example.com>;
   foaf:knows :bob.

=====Variations=====

TBD: Alternate scenarios will include requests on the non-resolvable URI /people/alice; requests for RDF/XML; data including blank data nodes; authorisation failure;

====Non-Functional====

* The response represents a Concise Bounded Description of the requested resource <http://www.w3.org/Submission/CBD/>.

====Issues====

* We assume that in the simplest case, the BPR URI is a resolvable HTTP URI. Are non-resolvable URIs for real world things and abstract concepts supported, and are they redirected to BPRs?

* owl:sameAs Closure: Should OWL sameAs predicate be used transparently, to assert the equivalence of equivalent resources (e.g. merged contacts). See also <http://journal.webscience.org/403/2/websci10_submission_123.pdf>

-- 
Steve Battle
Semantic Engineer

E-mail: steve.battle@sysemia.co.uk
Web: www.sysemia.com

Sysemia Limited
The Innovation Centre, Bristol&  Bath Science Park, Dirac Crescent, Emerson's Green, Bristol BS16 7FR
Registered in England and Wales. Company Number: 7555456

DISCLAIMER

Information contained in this e-mail is intended for the use of the addressee only, and is confidential and may also be privileged. If you receive this message in error, please advise us immediately. If you are not the intended recipient(s), please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. Attachments to this e-mail may contain software viruses which may damage your systems. Sysemia Ltd have taken reasonable steps to minimise this risk, but we advise that any attachments are virus checked before they are opened.