Linked Data Platform - User contributions [en]

F2F3

Sbattle2 — Mon, 29 Apr 2013 14:10:37 GMT

Sbattle2:

= Third Face to Face meeting =

'''CONFIRMED:'''
Per the [http://www.w3.org/2012/ldp/meeting/2012-12-10#resolution_2 December 10, 2012 proposal], confirmed on [http://www.w3.org/2012/ldp/meeting/2013-04-08#resolution_2 April 8, 2013], this face to face will be held at the Center for Open Middleware in Madrid on June 18-20, 2013 (3 days).

__TOC__

== Participants ==

Below is the list of expected participants.

==== People planning to be in Madrid: ====
# Arnaud Le Hors
# Raúl García Castro
# Steve Speicher
# Nandana Mihindukulasooriya
# [[User:Cburleso|Cody Burleson]]
# Roger Menday
# John Arwe

==== People planning to participate remotely: ====
# [[Users:Tthibodeau|Ted Thibodeau]]
# [[User:Bvanleeu3| Bart van Leeuwen]] for at least 18 and 20 ( Maybe in madrid as well )
# Steve Battle
# <change this>

==== People sending regrets: ====
# <change this>

== Venue ==

The meeting will be held at the [http://www.centeropenmiddleware.com Center for Open Middleware].

The Center for Open Middleware is located near Madrid (there are buses
from different places in Madrid and the metro can also be used but
requires walking a bit):

[https://maps.google.es/maps?ie=UTF8&cid=2071452775163188547&q=Center+for+Open+Middleware&gl=ES&hl=es&t=m&source=embed&ll=40.406904,-3.833349&spn=0.006813,0.018915&z=17&vpsrc=6&iwloc=A Google Map]

More information about the [http://www.centeropenmiddleware.com/home/contact location, how to get to the COM premises, and suggested list of hotels].

== Remote Participation ==

'''TO BE CONFIRMED'''
A teleconference bridge has been reserved to provide for remote participation.
[http://www.timeanddate.com/worldclock/fixedtime.html?month=06&day=18&year=2013&hour=06&min=30&sec=0&p1=0 06:30-15:00 UTC] (8:30am-5:00pm Madrid local) - 8 ports
* Dial +1-617-761-6200 or sip:zakim@voip.w3.org then conference code LDPWG (53794) followed by #
* As usual we will also be using [http://www.w3.org/Project/IRC/ IRC] channel: [irc://irc.w3.org:6665/#ldp #ldp].

== Objectives ==

* Linked Data Platform specification
** Discuss and close as many open issues as possible
** Identify any remaining issues
** Identify steps to Last Call Working Draft (LCWD) (scheduled for 2013-05)
* Use Cases & Requirements document
** Identify steps to WD2
* Test Suite and/or Validator
** Identify editors
** Identify steps to get it complete
* Access Control WG Note
** Identify editors
** Identify steps to FPWD
* Deployment Guide
** Identify/confirm editors
** Identify steps to FPWD
* Primer
** Identify editors
** Identify steps to FPWD
* Next Face to Face Meeting
** Identify possible dates and venues+hosts (scheduled for 2013-06)

== References ==

* [http://www.w3.org/2012/ldp/hg/ldp.html LDP Editor's draft] [http://www.w3.org/TR/2013/WD-ldp-20130307/ LDP WD2]

* [http://www.w3.org/2012/ldp/hg/ldp-ucr.html UC&R Editor's draft]

* [http://www.w3.org/2012/ldp/wiki/AccessControl Access Control wiki]

* [http://www.w3.org/2012/ldp/wiki/Testing Testing wiki]

* [http://www.w3.org/2012/ldp/wiki/Deployment_Guide Deployment Guide wiki]

* [http://www.w3.org/2012/ldp/track/issues Issues]

* [http://www.w3.org/2012/ldp/charter#deliverables Deliverables per our charter]

* [http://www.w3.org/2012/ldp/charter#schedule Schedule per our charter]

== Agenda ==

=== Day 1 - Tuesday June 18 ===

; 09.00-09.30
: Welcome, logistics, short intro round, recap of meeting goals, agenda amendments.
; 9.30-10.30
: Use Cases & Requirements ([http://www.w3.org/2012/ldp/hg/ldp-ucr.html Editor's draft]) - status, steps towards WD2
; 10.30-11.00
: COFFEE/TEA BREAK
; 11.00-12.00
: LDP specification ([http://www.w3.org/2012/ldp/hg/ldp.html Editor's draft], [http://www.w3.org/TR/2013/WD-ldp-20130307/ WD2]) - steps towards LCWD, review of open issues, identify MUST-HAVEs
; 12.00-13.00
: LUNCH
; 13.00-13.30
: Primer - steps towards FWD
; 13.30-15.00
: LDP specification - pending issues
; 15.00-15.30
: COFFEE/TEA BREAK
; 15.30-16.30
: LDP specification - pending issues continues
; 16.30-17.00
: Day 1 recap, adjustments to agenda for day 2, dinner plans
; 18.30-20.30
: WG Dinner?

=== Day 2 - Wednesday June 19 ===

; 09.00-09.30
: Breakout sessions set up
; 09.30-10.00
: Access Control WG Note - steps towards FWD
; 10.00-10.30
: Deployment Guide - steps towards FWD
; 10.30-11.00
: COFFEE/TEA BREAK
; 11.00-11.30
: Test Suite & Validator - steps to completion
; 11.30-12.00
: Break out sessions
; 12.00-13.00
: LUNCH
; 13.00-15.00
: LDP specification - pending issues continues
; 15.00-15.30
: COFFEE/TEA BREAK
; 15.30-16.30
: LDP specification - pending issues continues
; 16.30-17.00
: Day 2 recap, adjustments to agenda for day 3, dinner plans
; 18.30-20.30
: WG Dinner?

=== Day 3 - Thursday June 20 ===

; 09.00-09.30
: Next Face to Face Meeting: when and where?
; 09.30-10.30
: LDP specification - pending issues continues
; 10.30-11.00
: COFFEE/TEA BREAK
; 11.00-12.00
: LDP specification - pending issues continues
; 12.00-13.00
: LUNCH
; 13.00-15.30
: LDP specification - pending issues continues
; 15.30-16.00
: Wrap-up

F2F2

Sbattle2 — Mon, 21 Jan 2013 15:01:59 GMT

Sbattle2: /* People planning to be in Boston: */

= Second Face to Face meeting =

In accordance with our [http://www.w3.org/2012/ldp/charter#schedule charter] a Face to Face meeting is expected in March 2013.

Per the [http://www.w3.org/2012/ldp/meeting/2012-12-10#resolution_2 December 10, 2012 resolution], confirmed on [http://www.w3.org/2012/ldp/meeting/2013-01-07#resolution_2 January 7, 2013], this face to face will be held at MIT in Boston on March 13-15 (3 days).

'''If you can sponsor the event with some financial support to cover catering and/or dinner, [mailto:lehors@us.ibm.com,Erik.Wilde@emc.com,eric@w3.org,yves@w3.org?Subject=LDP%20F2F2%20Sponsoring please let us know]!'''

__TOC__

== Participants ==

Below is the list of expected participants.

==== People planning to be in Boston: ====
# Arnaud Le Hors
# Ashok Malhotra
# Sandro Hawke
# Steve Speicher
# John Arwe
# [[User:Tthibodeau|Ted Thibodeau]]
# Roger Menday
# Richard Cyganiak (pending travel approval)
# [https://www.w3.org/users/36320 David Wood]
# Steve Battle

==== People planning to participate remotely: ====
# Erik Wilde
# [[User:Fsergio|Sergio Fernández]]

==== People sending regrets: ====
# [[User:Bvanleeu3|Bart van Leeuwen]]

== Venue ==

The meeting will be held at

[http://www.csail.mit.edu/news/stata Ray and Maria Stata Center], MIT<br />
Building 32<br />
Gates Tower, G449<br />
[http://whereis.mit.edu/map-jpg?mapterms=32&mapsearch=go 32 Vassar Street]<br />
Cambridge, MA 02139

Room TBD.

We will provide coffee, lunch, refreshments during the breaks, and dinner. There will be wireless Internet access. [ '''Note: To be confirmed''' ]

=== A few notes about the building===

The Stata Center can be a bit confusing as there are two towers: Gates and Dreyfoos. This workshop will be held in the Gates Tower, the entrance to which is on the corner of Vassar and Main Streets.

The building is on an automatic locking system. Doors to the elevator foyers on the 4th floor will be opened for the workshop but the stairwells automatically lock at 5pm (with the only unlocked exit door on the first floor).

Please be careful of your belongings even when stepping away even for a short while. The building is open to the public and there have, unfortunately, been thefts.

=== How to get to the Stata Center ===

The MIT Computer Science and Artificial Intelligence Laboratory ([http://www.csail.mit.edu/ CSAIL]) is [http://whereis.mit.edu/map-jpg?mapterms=32&mapsearch=go located] at the northeastern edge of the MIT campus on Vassar Street near the intersection with Main Street.

Boston [http://www.massport.com/logan/ Logan International Airport] is the closest international airport to MIT. The travel time between the airport and hotels in Cambridge will vary between 30 minutes to one hour depending on traffic conditions. Taxis from the airport are plentiful and fares will range around $30-40.

The Stata Center is located a few blocks away from the [http://www.mbta.com/ MBTA] Red line Kendall/MIT stop ([http://www.csail.mit.edu/node/95 directions]). We strongly suggest that visitors use public transportation. Alternately, several of the the hotels provide shuttle service to MIT. Information on parking is located below.

=== Parking ===

The [http://web.mit.edu/facilities/transportation/index.html MIT Parking and Transportation Office] does not offer pay lots for visitors. They note: "Because the number of visitor parking spaces on campus is limited, it may not be possible to accommodate every visitor who wishes to park at MIT.... We strongly recommend using public transportation when visiting the MIT campus." There is hourly on-street parking available around the Stata Center though Cambridge is a busy area and parking may be difficult to find, especially in inclement weather.

Information on paid parking lots near campus can be found on MIT's [http://web.mit.edu/facilities/transportation/parking/visitors/public_parking.html parking site].

=== Hotels ===

MIT also has a list of [http://web.mit.edu/visit/hotels.html nearby hotels].

== Remote Participation ==

'''Note: To be confirmed''' A teleconference bridge has been reserved to provide for remote participation.
[http://www.timeanddate.com/worldclock/fixedtime.html?month=11&day=01&year=2012&hour=06&min=30&sec=0&p1=0 06:30-16:00 UTC] (2:30am-12:00pm Boston local) - 9 ports
* Dial +1-617-761-6200 or sip:zakim@voip.w3.org then conference code LDPWG (53794) followed by #
* As usual we will also be using [http://www.w3.org/Project/IRC/ IRC] channel: [irc://irc.w3.org:6665/#ldp #ldp].

== Objectives ==

* TBD

== References ==

* TBD

* [http://www.w3.org/2012/ldp/hg/ldp.html Linked Data Platform spec]

* [http://www.w3.org/2012/ldp/wiki/Use_Cases_And_Requirements Use Cases & Requirements]

* [http://www.w3.org/2012/ldp/wiki/Examples Examples]

* [http://www.w3.org/2012/ldp/track/issues Issues]

* [http://www.w3.org/2012/ldp/charter#deliverables Deliverables per our charter]

* [http://www.w3.org/2012/ldp/charter#schedule Schedule per our charter]

* [http://lists.w3.org/Archives/Public/public-ldp-wg/2012Oct/0195.html Andy's list of topics of special interest]

== Agenda ==

* TBD

Use Cases And Requirements

Sbattle2 — Mon, 10 Dec 2012 17:45:51 GMT

Sbattle2: /* Status of this Document */

= Linked Data Platform Use Cases And Requirements =

This is a working document used to collect use cases and requirements for consideration by the WG.
The starting point comes from [http://www.w3.org/Submission/2012/SUBM-ldbpucr-20120326/ Linked Data Basic Profile Use Cases and Requirements].

== Status of this Document ==

This document is currently under review pending release as a First Public Working Draft. While the editors have made every effort to identify a set of use-cases that are both evidenced in user-stories and in-scope of the charter, the document may yet be missing some key unidentified use-cases, or indeed, may include use-cases that ought to be removed. Furthermore, the coarse grouping of use-cases to avoid CRUDdy operations may not be to people's taste and is open to challenge.

Following feedback from the face-to-face, the use-cases are captured in a narrative style that describes a behaviour, or set of behaviours drawn from user-stories. They are embellished with concrete examples drawn from representative user-stories. The aim throughout has been to avoid details of protocol (specifically the HTTP protocol), and use of any specific vocabulary that might be introduced by the LDP specification.

===Timetable===
* <strike>Nov 26? WG to confirm User Story content: add, remove, refine (see process below). Note: this is ONLY User Stories (not Use Cases, Use Case Scenarios or Requirements)</strike>
** <strike>Issues before Nov 26th? will be included into FPWD</strike>
* Editors to:
** <strike>Dec 3 refine User Stories based on feedback</strike>
** <strike>Dec 5 elaborate on Use Cases in support of User Stories</strike>
* Dec 10 - WG to review prior to FPWD
** Review period ends Dec 15th
** insert open issues into draft for FPWD
* Dec 17 - Publish FPWD
** convert wiki page to ReSpec for FPWD
* Dec ?? Deadline for publications by year end 2012

===To Be Done===
* <strike>Move [[#LDP_and_Authentication.2FAuthorization| LDP and Authentication]] to [http://www.w3.org/2012/ldp/wiki/AccessControl AccessControl]</strike>
* <strike>Complete [[#Alternative_scenario:_moving_contained_resources| moving contained resources]] scenario with content from ericP on issue-30.</strike>
* <strike>Augment [[#Cloud_Infrastructure_Management| Cloud Infrastructure Management]] scenario with content from Roger Menday.</strike>
* <strike>Ensure issue-40/41 are fully covered in [[#UC8:_Managing_non-RDF_Resources| UC8: Managing non-RDF Resources]]. 2 scenarios (single v multiple attachments) ?</strike>
* <strike>Contact owner of [[#Data_Sharing| Data Sharing]] user-story to determine if we keep or not.</strike>
* <strike>Review [[#Requirements| Requirements]] section for functional/non-functional requirements arising in UCs.</strike>
* <strike>Propose resolutions to open issues against UC&R where possible.</strike>
* <strike>Identify and acknowledge user-story contributors.</strike>
* <strike>Check hyperlinks</strike>
* Convert to ReSpec
* Annotate document with open issues against UC&R
** <strike>[http://www.w3.org/2012/ldp/track/issues/30 ISSUE-30] (OPEN)</strike>
** [http://www.w3.org/2012/ldp/track/issues/40 ISSUE-40] (PENDING REVIEW)
** [http://www.w3.org/2012/ldp/track/issues/41 ISSUE-41] (PENDING REVIEW)

=== Process to introduce new User Stories & Use Cases ===

Open an Issue in the tracker against the UC&R product. The WG will review these and decide whether they are valid.

== Scope and Motivation ==

Linked Data was defined by Tim Berners-Lee with the following guidelines [http://www.w3.org/DesignIssues/LinkedData.html]:

# Use URIs as names for things
# Use HTTP URIs so that people can look up those names
# When someone looks up a URI, provide useful information, using the standards (RDF*, SPARQL)
# Include links to other URIs. so that they can discover more things

These four rules have proven very effective in guiding and inspiring people to publish Linked Data on the web. The amount of data, especially public data, available on the web has grown rapidly, and an impressive number of extremely creative and useful “mashups” have been created using this data as result.

There has been much less focus on the potential of Linked Data as a model for managing data on the web - the majority of the Application Programming Interfaces (APIs) available on the Internet for creating and updating data follow a Remote Procedure Call (RPC) model rather than a Linked Data model.

If Linked Data were just another model for doing something that RPC models can already do, it would be of only marginal interest. Interest in Linked Data arises from the fact that applications with an interface defined using Linked Data can be much more easily and seamlessly integrated with each other than applications that offer an RPC interface. In many problem domains, the most important problems and the greatest value are found not in the implementation of new applications, but in the successful integration of multiple applications into larger systems.

Some of the features that make Linked Data exceptionally well suited for integration include:

* A single interface – defined by a common set of HTTP methods – that is universally understood and is constant across all applications. This is in contrast with the RPC architecture where each application has a unique interface that has to be learned and coded to.
* A universal addressing scheme – provided by HTTP URLs – for both identifying and accessing all “entities”. This is in contrast with the RPC architecture where there is no uniform way to either identify or access data.
* A simple yet extensible data model – provided by RDF – for describing data about a resource in a way which doesn’t require prior knowledge of vocabulary being used.

Experience implementing applications and integrating them using Linked Data has shown very promising results, but has also demonstrated that the original four rules defined by Tim Berners-Lee for Linked Data are not sufficient to guide and constrain a writable Linked Data API. As was the case with the original four rules, the need generally is not for the invention of fundamental new technologies, but rather for a series of additional rules and patterns that guide and constrain the use of existing technologies in the construction of a Basic Profile for Linked Data to achieve interoperability.

The following list illustrates a few of the issues that require additional rules and patterns:
* What URLs do I post to in order to create new resources?
* How do I get lists of existing resources, and how do I get basic information about them without having to access each one?
* How should I detect and deal with race conditions on write?
* What media-types/representations should I use?
* What standard vocabularies should I use?
* What primitive data types should I use?

A good goal for the Basic Profile for Linked Data would be to define a specification required to allow the definition of a writable Linked Data API equivalent to the simple application APIs that are often written on the web today using the Atom Publishing Protocol (APP). APP shares some characteristics with Linked Data, such as the use of HTTP and URLs. One difference is that Linked Data relies on a flexible data model with RDF, which allows for multiple representations.

== Organization of this Document ==

This document is organized as follows:

* '''[[#User Stories| User Stories]]''' capture statements about system requirements written from a user or application perspective. They are typically lightweight and informal and can run from one line to a paragraph or two (sometimes described as an 'epic') [http://www.agilemodeling.com/artifacts/userStory.htm]. Analysis of each user story will reveal a number of (functional) use-cases and other non-functional requirements. See [http://www.w3.org/TR/dap-policy-reqs/| Device API Access Control Use Cases and Requirements] for a good example of user stories and their analysis.

* '''[[#Use Cases| Use Cases]]''' are used to capture and model functional requirements. Use cases describe the system’s behavior under various conditions [http://alistair.cockburn.us/get/2465], cataloguing who does what with the system, for what purpose, but without concern for system design or implementation [http://www.bredemeyer.com/pdf_files/functreq.pdf]. Each use case is identified by a reference number to aid cross-reference from other documentation; use-case indexing in this document is based on [http://www.w3.org/TR/rdb2rdf-ucr/ rdb2rdf use-cases]. A variety of styles may be used to capture use-cases, from a simple narrative to a structured description with actors, pre/post conditions, and step-by-step behaviours as in [http://www.w3.org/TR/powder-use-cases/ POWDER: Use Cases and Requirements], and non-functional requirements raised by the use-case. Use cases act like the hub of a wheel, with spokes supporting requirements analysis, scenario-based evaluation, testing, and integration with non-functional, or quality requirements.

* '''Scenarios''' are more focused still, representing a single instance of a use case in action. Scenarios may range from lightweight narratives as seen in [http://www.w3.org/TR/media-frags-reqs/ Use cases and requirements for Media Fragments], to being formally modeled as interaction diagrams. Each use-case should include at least a primary scenario, and possibly other alternative scenarios.

* '''[[#Requirements| Requirements]]''' lists non-functional or quality requirements, and the use cases they may be derived from. This approach is exemplified in the [http://dvcs.w3.org/hg/gld/raw-file/default/dcat-ucr/index.html Use Cases and Requirements for the Data Catalog Vocabulary]. It also lists functional requirements that stem from use-cases. It is also possible at this stage to explicitly identify some use-cases as non-requirements.

== User Stories ==

=== Maintaining Social Contact Information ===

Many of us have multiple email accounts that include information about the people and organizations we interact with – names, email addresses, telephone numbers, instant messenger identities and so on. When someone’s email address or telephone number changes (or they acquire a new one), our lives would be much simpler if we could update that information in one spot and all copies of it would automatically be updated. In other words, those copies would all be linked to some definition of “the contact.” There might also be good reasons (like off-line email addressing) to maintain a local copy of the contact, but ideally any copies would still be linked to some central “master.”

Agreeing on a format for “the contact” is not enough, however. Even if all our email providers agreed on the format of a contact, we would still need to use each provider’s custom interface to update or replace the provider’s copy, or we would have to agree on a way for each email provider to link to the “master”. If we look outside our own personal interests, it would be even more useful if the person or organization exposed their own contact information so we could link to it.

What would work in either case is a common understanding of the resource, a few formats needed, and access guidance for these resources. This would support how to acquire a link to a contact, and how to use those links to interact with a contact (including [[#UC3: Retrieve resource description|reading]], [[#UC4: Update existing resource|updating]], and [[#Alternative scenario: delete resource|deleting]] it), as well as how to easily [[#Primary scenario: create resource|create a new contact]] and add it to my contacts and when deleting a contact, how it would be removed from my list of contacts. It would also be good to be able to add some application-specific data about my contacts that the original design didn’t consider. Ideally we’d like to eliminate multiple copies of contacts, there would be additional valuable information about my contacts that may be stored on separate servers and need a simple way to link this information back to the contacts. Regardless of whether a contact collection is my own, shared by an organization, or all contacts known to an email provider (or to a single email account at an email provider), it would be nice if they all worked pretty much the same way.

=== Keeping Track of Personal and Business Relationships ===

In our daily lives, we deal with many different organizations in many different relationships, and they each have data about us. However, it is unlikely that any one organization has all the information about us. Each of them typically gives us access to the information (at least some of it), many through websites where we are uniquely identified by some string – an account number, user ID, and so on. We have to use their applications to interact with the data about us, however, and we have to use their identifier(s) for us. If we want to build any semblance of a holistic picture of ourselves (more accurately, collect all the data about us that they externalize), we as humans must use their custom applications to find the data, copy it, and organize it to suit our needs.

Would it not be simpler if at least the Web-addressable portion of that data could be linked to consistently, so that instead of maintaining various identifiers in different formats and instead of having to manually supply those identifiers to each one’s corresponding custom application, we could essentially build a set of bookmarks to it all? When we want to [[#UC3: Retrieve resource description|examine]] or [[#UC4: Update existing resource|change]] their contents, would it not be simpler if there were a single consistent application interface that they all supported? Of course it would.

Our set of links would probably be a [[#UC6: Aggregate resources|simple collection]]. The information held by any single organization might be a mix of simple data and [[#UC6: Aggregate resources|collections of other data]], for example, a bank account balance and a collection of historical transactions. Our bank might easily have [[#Alternative scenario: create a nested container|a collection of accounts for each of its collection of customers]].

=== System and Software Development Tool Integration ===

System and software development tools typically come from a diverse set of vendors and are built on various architectures and technologies. These tools are purpose built to meet the needs for a specific domain scenario (modeling, design, requirements and so on.) Often tool vendors view integrations with other tools as a necessary evil rather than providing additional value to their end-users. Even more of an afterthought is how these tools’ data -- such as people, projects, customer-reported problems and needs -- integrate and relate to corporate and external applications that manage data such as customers, business priorities and market trends. The problem can be isolated by standardizing on a small set of tools or a set of tools from a single vendor, but this rarely occurs and if does it usually does so only within small organizations. As these organizations grow both in size and complexity, they have needs to work with outsourced development and diverse internal other organizations with their own set of tools and processes. There is a need for better support of more complete business processes (system and software development processes) that span the roles, tasks, and data addressed by multiple tools. This demand has existed for many years, and the tools vendor industry has tried several different architectural approaches to address the problem. Here are a few:

* Implement an API for each application, and then, in each application, implement “glue code” that exploits the APIs of other applications to link them together.
* Design a single database to store the data of multiple applications, and implement each of the applications against this database. In the software development tools business, these databases are often called “repositories.”
* Implement a central “hub” or “bus” that orchestrates the broader business process by exploiting the APIs described previously.

It is fair to say that although each of those approaches has its adherents and can point to some successes, none of them is wholly satisfactory. The use of Linked Data as an application integration technology has a strong appeal. [http://open-services.net/ OSLC]

=== Library Linked Data ===

The W3C Library Linked Data working group has a number of use cases cited in their Use Case Report. [http://www.w3.org/2005/Incubator/lld/wiki/UseCaseReport LLD-UC] These referenced use cases focus on the need to extract and correlate library data from disparate sources. Variants of these use cases that can provide consistent formats, as well as ways to improve or update the data, would enable simplified methods for both efficiently sharing this data as well as producing incremental updates without the need for repeated full extractions and import of data.

The 'Digital Objects Cluster' contains a number of relevant use-cases:

* Grouping: This should "Allow the end-users to define [[#UC6: Aggregate resources|groups of resources]] on the web that for some reason belong together. The relationship that exists between the resources is often left unspecified. Some of the resources in a group may not be under control of the institution that defines the groups."

* Enrichment: "Enable end-users to [[#UC4: Update existing resource|link resources together]]."

* Browsing: "[[#UC7: Filter resource description|Support end-user browsing through groups]] and resources that belong to the groups."

* Re-use: "Users should have the capability to re-use all or parts of a collection, with all or part of its metadata, elsewhere on the linked Web."

The 'Collections' cluster also contains a number of relevant use-cases:

* Collection-level description: "Provide [[#UC7: Filter resource description|metadata pertaining to a collection as a whole]], in contrast to item-level description."

* Collections discovery: "Enable innovative collection discovery such as identification of nearest location of a physical collection where a specific information resource is found or mobile device applications ... based on collection-level descriptions."

* Community information services: Identify and classify collections of special interest to the community.

=== Municipality Operational Monitoring ===

Across various cities, towns, counties, and various municipalities there is a growing number of services managed and run by municipalities that produce and consume a vast amount of information. This information is used to help monitor services, predict problems, and handle logistics. In order to effectively and efficiently collect, produce, and analyze all this data, a fundamental set of loosely coupled standard data sources are needed. A simple, low-cost way to [[#UC3: Retrieve resource description|expose data]] from the diverse set of monitored services is needed, one that can easily integrate into the municipalities of other systems that inspect and analyze the data. All these services have links and dependencies on other data and services, so having a simple and scalable linking model is key.

=== Healthcare ===

For physicians to analyze, diagnose, and propose treatment for patients requires a vast amount of complex, changing and growing knowledge. This knowledge needs to come from a number of sources, including physicians’ own subject knowledge, consultation with their network of other healthcare professionals, public health sources, food and drug regulators, and other repositories of medical research and recommendations.

To diagnose a patient’s condition requires current data on the patient’s medications and medical history. In addition, recent pharmaceutical advisories about these medications are linked into the patient’s data. If the patient experiences adverse affects from medications, these physicians need to publish information about this to an appropriate regulatory source. Other medical professionals require access to both validated and emerging effects of the medication. Similarly, if there are geographical patterns around outbreaks that allow both the awareness of new symptoms and treatments, this information needs to quickly reach a very distributed and diverse set of medical information systems. Also, reporting back to these regulatory agencies regarding new occurrences of an outbreak, including additional details of symptoms and causes, is critical in producing the most effective treatment for future incidents.

=== Metadata Enrichment in Broadcasting ===

There are many different use cases when broadcasters show interest in metadata [[#UC4: Update existing resource| enrichment]]:

* enrich archive or news metadata by linking facts, events, locations and personalities
* enrich metadata generated by automatic extraction tools such as person identification, etc.
* enrich definitions of terms in classification schemes or enumeration lists

This comes in support of more effective information management and data/content mining (if you can't find your content, it' like if you don't have and must either recreate or acquire it again, which is not financially effective).

However, there is a need for solutions facilitating linkage to other data sources and taking care of the issues such as discovery, automation, disambiguation. Etc. Other important issues that broadcasters would face are the editorial quality of the linked data, its persistence, and usage rights.

=== Aggregation and Mashups of Infrastructure Data ===

For infrastructure management (such as storage systems, virtual machine environments, and similar IaaS and PaaS concepts), it is important to provide an environment in which information from different sources can be [[#UC6: Aggregate resources|aggregated]], [[#UC7: Filter resource description|filtered]], and visualized effectively. Specifically, the following use cases need to be taken into account:

* While some data sources are based on Linked Data, others are not, and aggregation and mashups must work across these different sources.
* Consumers of the data sources and aggregated/filtered data streams are not necessarily implementing Linked Data themselves, they may be off-the-shelf components such as dashboard frameworks for composing visualizations.
* Simple versions of this scenario are pull-based, where the data is requested from data sources. In more advanced settings, without a major change in architecture it should be possible to move to a push-based interaction model, where data sources push notifications to subscribers, and data sources provide different services that consumers can subscribe to (such as "informational messages" or "critical alerts only").

In this scenario, the important factors are to have abstractions that allow easy aggregation and filtering, are independent from the internal data model of the sources that are being combined, and can be used for pull-based interactions as well as for push-based interactions.

=== Sharing payload of RDF data among low-end devices ===

Several projects around the idea of [http://worldwidesemanticweb.wordpress.com/ downscaling the Semantic Web] need to be able to ship payloads of RDF across the nodes member of a given network. The transfers are done in a constrained context in terms of bandwidth, scope of the local semantics employed by the nodes and computing capabilities of the nodes. In a P2P style, every node has the capability to act either as a data consumer or a data provider, serving its own data or acting as a relay to pass other's data along (typically in mesh networks).

The transfer of an arbitrary payload of RDF data could be implemented through the container mechanism, adding and removing sets of RDF triples to it. Currently, one of the project "SemanticXO" uses named graphs and the graph protocol to create/delete/copy graphs across the nodes but this (almost) imposes the usage of a triple store. Unfortunately, triple store are rather demanding piece of software that are not always usable on limited hardware. Some generic ReST like interaction backed up with a lightweight column store would be better approach.

=== Sharing Binary Resources and Metadata ===

When publishing datasets about stars one may want to publish links to the pictures in which those stars appear, and this may well require publishing the pictures themselves. Vice versa: when publishing a picture of space we need to know which telescope took the picture, which part of the sky it was pointing at, what filters were used, which identified stars are visible, who can read it, who can write to it, ...

If LinkedData contains information about resources that are most naturally expressed in non-rdf formats (be they binary such as pictures or videos, or human readable documents in XML formats), those non RDF formats should be just as easy to publish to the LinkedData server as the RDF relations that link those resources up. A LinkedData server should therefore allow publishing of non linked data resources too, and make it easy to publish and edit metadata about those resources.

The resource comes in two parts - the image and information about the image (which may in the image file but better external to it as it's more general). The information about the image is vital. It's a compound item of image data and other data (being application metadata about the image does not distinguish from the platform's point-of-view.

=== Data Catalogs ===

The Asset Description Metadata Schema ([http://joinup.ec.europa.eu/asset/adms/home ADMS]) provides the data model to describe semantic assets repositories contents, but this leaves many open challenges when building a federation of these repositories to serve the need of assets reuse. These include accessing and querying individual repositories and efficiently retrieving [[#UC5: Determine if a resource has changed| updated content]] without having to retrieve the whole content. Hence, we chose to build the integration solution capitalizing on the Data Warehousing integration approach. This allows us to cope with heterogeneity of sources technologies and to benefit from the optimized performance it offers, given that individual repositories do not usually change frequently. With Data Warehousing, the federation requires to:

* understand the data, i.e. understand their semantic descriptions, and other systems.
* seamlessly exchange the semantic assets metadata from different repositories
* keep itself up-to-date.

Repositories owners can maintain de-referenceable URIs for their repository description and contained assets in a Linked Data compatible manner. ADMS provides the necessary data model to enable meaningful exchange of data. However, This leaves the challenge of efficient access to the data not fully addressed.

Related: [http://spec.datacatalogs.org/ Data Catalog Schema and Protocol]

=== Constrained Devices and Networks ===

Information coming from resource constrained devices in the Web of Things ([http://en.wikipedia.org/wiki/Web_of_Things WoT]) has been identified as a major driver in many domains, from smart cities to environmental monitoring to real-time tracking. The amount of information produced by these devices is growing exponentially and needs to be accessed and integrated in a systematic, standardized and cost efficient way. By using the same standards as on the Web, integration with applications will be simplified and higher-level interactions among resource constrained devices, abstracting away heterogeneities, will become possible. Up-coming IoT/WoT standards such as [http://datatracker.ietf.org/wg/6lowpan/ 6LowPAN] - IPv6 for resource constrained devices - and the Constrained Application Protocol ([http://tools.ietf.org/html/draft-ietf-core-coap CoAP]), which provides a downscaled version of HTTP on top of UDP for the use on constrained devices, are already at a mature stage. The next step now is to support RESTful interfaces also on resource constrained devices, adhering to the Linked Data principles. Due to the limited resources available, both on the device and in the network (such as bandwidth, energy, memory) a solution based on SPARQL Update is at the current point in time considered not to be useful and/or feasible. An approach based on the [http://tools.ietf.org/html/draft-castellani-core-http-mapping HTTP-CoAP Mapping] would enable constrained devices to directly participate in a Linked Data-based environment.

=== Services Supporting the Process of Science ===
Many fields of science now include branches with in silico data-intensive methods, e.g. bioinformatics, astronomy. To support these new methods we look to move beyond the established platforms provided by scientific workflow systems to capture, assist, and preserve the complete lifecycle from record of the experiment, through local trusted sharing, analysis, dissemination (including publishing of experimental data "beyond the PDF"), and re-use.

* [[#UC6: Aggregate resources|Aggregations]], specifically ''Research Objects (ROs)'' that are exchanged between services and clients bringing together workflows, data sets, annotations, and provenance. We use an RDF model for this. While some aggregated contents are encoded using RDF and in increasing number are linked data sources, others are not; while some are stored locally "within" the RO, others are remote (in both cases this is often due to size of the resources or access policies).
* Services that are distributed and linked. Some may be centralising for e.g. publication, others may be local, e.g. per lab. We need lightweight services that can be simply and easily integrated into and scale across the wide variety of softwares and data used in science: we have adopted a RESTful approach where possible.
** Foundation services that collect and expose ROs for storage, modification, exploration, and reuse.
** Services that provide added-value to ROs such as seamless import/export from scientific workflow systems, automated stability evaluation, or recommendation (and therefore interact with the foundation services to retrieve/store/modify/ROs).

seeAlso: [http://www.wf4ever-project.org/ Wf4Ever]

=== Project Membership Information : Information Evolution ===

Information about people and projects changes as roles change, as organisations change
and as contact details change. Finding the current state of a project is important
in enabling people to contact the right person in the right role. It can also be
useful to look back and see who was performing what role in the past.

A use of a Linked Data Platform could be to give responsibility for managing
such information with the project team itself, not requiring updates to be
requested of a centralised website administrator.

This could be achieved with:

* Resource descriptions for each person and project
* A container resource to describe roles/membership in the project.

To retain the history of the project, the old version of a resources,
including container resources, should be retained so there is a need to address both specific items
and also have a notion of "current".

Access to information has two aspects:
* Access to the "current" state, regardless of the version of the resource description
* Access to historical state, via access to a specific version of the resource description

=== Cloud Infrastructure Management===

Cloud operators offer API support to provide customers with remote access for the management of Cloud infrastructure (IaaS). Infrastructure consists of Systems, Computers, Networks, Discs, etc. The overall structure can be seen as mostly hierarchical, (Cloud contains Systems, Systems contain Machines, etc), complemented with crossing links (e.g. multiple Machines connected to a Network).

The IaaS scenario makes specific requirements on lifecycle management and discovery, handling non-instant changes, history capture and query:

* Many aspects of Cloud infrastructure have associated lifecycle, e.g. a Computer can be transitioned between Running and Shutdown. This should be manageable through the API, which should include how a client discovers dynamic lifecycle options and thus help steering through an application.
* It is often the case that attaining a new lifecycle state is not instantaneous. Clients require a universal mechanism for monitoring such changes.
* A facility to retrieve all events in the lifecycle of a resource can be useful.
* Query provides the means to interrogate the resources behind the API, as well as finding new entry points into the application.

Infrastructure management may be viewed as the manipulation of the underlying graph of resources.

== Use Cases ==
The following use-cases are each derived from one or more of the user-stories above. These use-cases are explored in detail through the development of scenarios, each motivated by some key aspect exemplified by a single user-story. The examples they contain are included purely for illustrative purposes, and should not be interpreted normatively.

===UC1: Manage containers===
A number of user-stories introduce the idea of a ''container'' as a mechanism for creating and managing resources within the context of an application. Resources grouped together within the same container would typically belong to the same application. A container is identified by a URI so is a resource in its own right.
The properties of a container may also represent the ''affordances'' of that container, enabling clients to determine what other operations they can do on that container. These operations may include descriptions of application specific services that can be invoked by exchanging RDF documents.

* Provide "access guidance for ... resources" (affordances) (from user-story, [[#Maintaining Social Contact Information|Maintaining Social Contact Information]]).

====Primary scenario: create container====
Create a new container resource within the LDP server.
In [[#Services Supporting the Process of Science|Services supporting the process of science]], [http://wf4ever.github.com/ro-primer/ Research Objects] are semantically rich aggregations of resources that bring together data, methods and people in scientific investigations. A basic workflow research object will be created to aggegate [http://ceur-ws.org/Vol-903/paper-01.pdf scientific workflows] and the artefacts that result from this workflow. The research object begins life as an empty container into which workflows, datasets, results and other data will be added throughout the lifecycle of the project.

<nowiki>
@prefix ro: http://purl.org/wf4ever/ro#
@prefix dct: http://purl.org/dc/terms/
@prefix ore: http://www.openarchives.org/ore/

<> a ro:ResearchObject, ore:Aggregation ;
dct:created "2012-12-01"^^xsd:dateTime .
</nowiki>

====Alternative scenario: create a nested container====
The motivation for nested containers comes from the [[#System and Software Development Tool Integration| System and Software Development Tool Integration]] user-story. The OSLC Change Management vocabulary allows bug reports to have attachments referenced by the membership predicate <nowiki>oslc_cm:attachment</nowiki>. The 'top-level-container' contains issues, and each issue resource has its own container of attachment resources.

<nowiki>
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix oslc_cm: <http://open-services.net/ns/cm#>.
@prefix : <http://example.org/>.

:top-level-container rdfs:member :issue1234 .

:issue1234 a oslc_cm:ChangeRequest;
dcterms:identifier "1234";
dcterms:type "a bug";
dcterms:related :issue1235 ;
oslc_cm:attachments :attachments123.

:issue1235 a oslc_cm:ChangeRequest;
dcterms:title "a related bug".

:attachments a oslc_cm:AttachmentList;
oslc_cm:attachment :attachment324, :attachment251.
</nowiki>

===UC2: Manage resources===
This use-case addresses the managed lifecycle of a resource and is concerned with resource ''ownership''. The responsibility for managing resources belongs with their container.
For example, a container may accept a request from a client to make a new resource.
This use-case focuses on creation and deletion of resources in the context of a container, and the potential for transfer of ownership by moving resources between containers.
The ownership of a resource should always be clear; no resource managed in this way should ever be owned by more than one container.

Once a new resource has been created it should be identified by a URI. Clients may defer responsibility for establishing dereferenceable URIs to the container of their data.
The container is a natural choice for the endpoint for this interface as it will already have some application-specific knowledge about the contained resources.
While the LDP has ultimate control over resource naming, some applications may require more control over naming, perhaps to provide a more human-readable URI. An LDP server could support something like the [http://tools.ietf.org/html/rfc5023 Atom Publishing Protocol] slug header to convey a user defined naming 'hint'.

* Non-duplication of resources: "Eliminate multiple copies", representing resources in a single place (from [[#Maintaining Social Contact Information]]).
* Distribution of resources: Linked aata "may be stored on separate servers" (from [[#Maintaining Social Contact Information]]).
* Consistent, global naming: Resources should be "linked to consistently, ... instead of maintaining various identifiers in different formats" (from [[#Keeping Track of Personal and Business Relationships]]).

====Primary scenario: create resource====
Resources begin life by being created within a container. From user-story, [[#Maintaining Social Contact Information|Maintaining Social Contact Information]], It should be possible to "easily create a new contact and add it to my contacts." This suggests that resource creation is closely linked to the application context. The new resource is created in a container representing "my contacts." The lifecycle of the resource is linked to the lifecycle of it's container. So, for example, if "my contacts" is deleted then a user would also reasonably expect that all contacts within it would also be deleted.

Contact details are captured as an RDF description and it's properties, including "names, email addresses, telephone numbers, instant messenger identities and so on." The description may include non-standard RDF; "data about my contacts that the original design didn’t consider."
The following RDF could be used to describe contact information using the [http://www.foaf-project.org FOAF] vocabulary. A contact is represented here by a <nowiki>foaf:PersonalProfileDocument</nowiki> defining a resource that can be created and updated as a single-unit, even though it may describe ancillary resources, such as a <nowiki>foaf:Person</nowiki>, below.

<nowiki>
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

<> a foaf:PersonalProfileDocument;
foaf:PrimaryTopic [
a foaf:Person;
foaf:name "Timothy Berners-Lee";
foaf:title "Sir";
foaf:firstName "Timothy";
foaf:surname "Berners-Lee";
foaf:nick "TimBL", "timbl";
foaf:homepage <http://www.w3.org/People/Berners-Lee/>;
foaf:weblog <http://dig.csail.mit.edu/breadcrumbs/blog/4>;
foaf:mbox <mailto:timbl@w3.org>;
foaf:workplaceHomepage <http://www.w3.org/>.
]
</nowiki>

====Alternative scenario: delete resource====
Delete a resource and all it's properties. If the resource resides within a container it will be removed from that container, however other links to the deleted resource may be left as dangling references.
In the case where the resource is a container, the server may also delete any or all contained resources.
In normal practice, a deleted resource cannot be reinstated. There are however, edge-cases where limited undelete may be desirable.
Best practice states that "[http://www.w3.org/TR/cooluris/| Cool URIs don't change]", which implies that deleted URIs shouldn't be recycled.

====Alternative scenario: moving contained resources====
Many resources may have value beyond the life of their membership in a container. This implies methods to add references to revise container membership.
Cloning container members for use in other containers results in duplication of information and maintenance problems; web practice is to encourage the creation of one resource, which may be referenced as many places as necessary. A change of ownership may - or may not - imply a change of URI, depending upon the specific LDP naming policy. While assigning a new URI to a resource is discouraged [http://www.w3.org/DesignIssues/Architecture.html#HTTP], it is possible to indicate that a resource has moved with an appropriate HTTP response.

===UC3: Retrieve resource description===
Access the current description of a resource, containing properties of that resource and links to related resources. The representation may include descriptions of related resources that cannot be accessed directly.
Depending upon the application, an LDP may enrich the retrieved RDF with additional triples. Examples include adding incoming links, sameAs closure and type closure.
The HTTP response should also include versioning information (i.e. last update or entity tag) so that subsequent updates can ensure they are being applied to the correct version.

* Use standard vocabularies as appropriate to enable a "common understanding of the resource" (from [[#Maintaining Social Contact Information|Maintaining Social Contact Information]]).
* A "scalable linking model is key" (from [[#Municipality Operational Monitoring]]).

====Primary scenario====
The user-story [[#Project Membership Information : Information Evolution| Project Membership Information]] discusses the representation of information about people and projects. It calls for "Resource descriptions for each person and project" allowing project teams to review information held about these resources. The example below illustrates the kinds of information that might be held about organizational structures based on the [http://www.epimorphics.com Epimorphics] [http://www.epimorphics.com/public/vocabulary/org.html organizational ontology].

Note that the example below defines two resources (shown as separate sections below) that will be hosted on an LDP based at <nowiki>http://example.com/</nowiki>. The representations of these resources may include descriptions of related resources, such as <nowiki>http://www.w3.org/</nowiki>, that that fall under a different authority and therefore can't be served from the LDP at this location.

<nowiki>
@prefix org: <http://www.w3.org/ns/org#> .
@prefix owltime: <http://www.w3.org/2006/time> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@base <http://example.com/> .

<member1> a org:Membership ;
org:member <http://www.w3.org/People/Berners-Lee/card#i> ;
org:organization http://www.w3.org/> ;
org:role <director> ;
org:memberDuring [a owltime:Interval; owltime:hasBeginning [
owltime:inXSDDateTime "1994-10-01T00:00:00Z"^^xsd:dateTime]] .

<http://www.w3.org/> a org:FormalOrganization ;
skos:prefLabel "The World Wide Web Consortium"@en ;
skos:altLabel "W3C" .
</nowiki>

<nowiki>
@prefix org: <http://www.w3.org/ns/org#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@base <http://example.com/> .

<director> a org:Role ;
rdfs:label "Director" .
</nowiki>

====Alternative scenario: retrieve description of a non-document resource====
In many cases, the things that are of interest are not always the things that are resolvable. The example below demonstrates how a foaf profile may be used to distinguish between the person and the profile; the former being the topic of the latter. This begs the question as to what a client should do with such non-document resources. In this case the HTTP protocol requires that the fragment part be stripped off before requesting the URI from the server. The result is a resolvable URI for the profile.

<nowiki>
@base <http://www.w3.org/People/Berners-Lee/card>
@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@prefix dc: <http://purl.org/dc/elements/1.1/>.

<> a foaf:PersonalProfileDocument ;
dc:title "Tim Berners-Lee's FOAF file" ;
foaf:homepage <http://www.w3.org/People/Berners-Lee/> ;
foaf:primaryTopic <#i> .
</nowiki>

===UC4: Update existing resource===
Change the RDF description of a LDP resource, potentially removing or overwriting existing data. This allows applications to ''enrich'' the representation of a resource by addling additional links to other resources.

* Unrestricted vocabulary: It should be possible be "able to add ... application-specific data" to resources (from [[#Maintaining Social Contact Information]]).

====Primary scenario: enrichment====
This relates to user-story [[#Metadata Enrichment in Broadcasting| Metadata Enrichment in Broadcasting]] and is based on the [http://www.bbc.co.uk/ontologies/sport/ BBC Sports Ontology]. The ''resource-centric'' view of linked-data provides a natural granularity for substituting, or overwriting a resource and its data. The simplest kind of update would simply replace what is currently known about a resource with a new representation. There are two distinct resources in the example below; a sporting event and an associated award. The granularity of the LDP would allow a user to replace the information about the award without disturbing the information about the event.

<nowiki>
@prefix sport: <http://www.bbc.co.uk/ontologies/sport/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

:mens_sprint a sport:MultiStageCompetition;
rdfs:label "Men's Sprint";
sport:award <#gold_medal> .

<#gold_medal> a sport:Award .
</nowiki>

We can enrich the description as events unfold, linking to the winner of the gold medal by substituting the above description with the following.

<nowiki>
@prefix sport: <http://www.bbc.co.uk/ontologies/sport/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

:mens_sprint a sport:MultiStageCompetition;
rdfs:label "Men's Sprint";
sport:award <#gold_medal> .
<#gold_medal> a sport:Award;
sport:awarded_to [
a foaf:Agent ;
foaf:name "Chris Hoy" .
] .
</nowiki>

====Alternative scenario: selective update of a resource====
This relates to user-story [[#Data Catalogs|Data Catalogs]], based on the [http://vocab.deri.ie/dcat Data Catalog Vocabulary].
A catalogue is described by the following RDF model.

<nowiki>
@prefix dcat: <http://www.w3.org/ns/dcat#> .
@prefix dcterms: <http://purl.org/dc/terms/> .

:catalog a dcat:Catalog ;
dcat:dataset :dataset/001;
dcterms:issued "2012-12-11"^^xsd:date.
</nowiki>

A catalog may contain multiple datasets, so when linking to new datasets it would be simpler and preferable to selectively add just the new dataset links.
A Talis ''changeset'' [http://docs.api.talis.com/getting-started/changesets][http://www.w3.org/2009/12/rdf-ws/papers/ws07] could be used to add a new <nowiki>dc:title</nowiki> to the dataset. The following update would be directed to the catalogue to add an additional dataset.

<nowiki>
@prefix : <http://example.com/>.
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix cs: <http://purl.org/vocab/changeset/schema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.

<change1>
a cs:ChangeSet ;
cs:subjectOfChange :catalog ;
cs:createdDate "2012-01-01T00:00:00Z" ;
cs:changeReason "Update catalog datasets" ;
cs:addition [
a rdf:Statement ;
rdf:subject :catalog ;
rdf:predicate dcat:dataset ;
rdf:object :dataset/002 .
] .
</nowiki>

===UC5: Determine if a resource has changed===
It should be possible to retrieve versioning information about a resource (e.g. last modified or entity tag) without having to download a representation of the resource.
This information can then be compared with previous information held about that resource to determine if it has changed.
This versioning information can also be used in subsequent ''conditional'' requests to ensure they are only applied if the version is unchanged.

====Primary scenario====
Based on the user-story, [[#Constrained Devices and Networks| Constrained Devices and Networks]], an LDP could be configured to act as a proxy for a [http://tools.ietf.org/html/draft-ietf-core-coap CoAP] based [http://en.wikipedia.org/wiki/Web_of_Things Web of Things]. As an observer of CoAP resources, the LDP registers its interest so that it will be notified whenever the sensor reading changes. Clients of the LDP can interrogate the LDP to determine if the state has changed.

In this example, the information about a sensor and corresponding sensor readings can be represented as RDF resources. The first resource below, represents a sensor described using the [http://www.w3.org/2005/Incubator/ssn/ Semantic Sensor Network] ontology.
<nowiki>
@prefix : <http://example.com/energy-management/>.

<> a :MainsFrequencySensor;
rdfs:comment "Sense grid load based on mains frequency";
ssn:hasMeasurementCapability [
a :FrequencyMeasurementCapability;
ssn:hasMeasurementProperty <#property_1> .
] .
</nowiki>

The value of the sensor changes in real-time as measurements are taken. The LDP client can interrogate the resource below to determine if it has changed, ''without'' necessarily having to download the RDF representation. As different sensor properties are represented disjointly (separate RDF representations) they may change independently.

<nowiki>
@prefix : <http://example.com/energy-management/>.

<http://example.com/energy-management#property_1> :hasMeasurementPropertyValue <> .
<> a :FrequencyValue;
:hasQuantityValue "50"^^xsd:float.
</nowiki>

===UC6: Aggregate resources===
There is a requirement to be able to manage ''collections'' of resources. The concept of a collection overlaps with, but is distinct from that of a container. These collections are (weak) aggregations, unrelated to the lifecycle management of resources, and distinct from the ownership between a resource and its container. However, the composition of a container may be reflected as a collection to support navigation of the container and its contents. There is a need to be able to create collections by adding and deleting individual membership properties. Resources may belong to multiple collections, or to none.

* Resource descriptions are a "mix of simple data and collections" (from [[#Keeping Track of Personal and Business Relationships]]).
* Relative URIs: It should be possible to "ship payloads of RDF" for a collection as a whole without breaking internal links (from [[#Constrained Devices and Networks]]).

====Primary scenario: add a resource to a collection====
This example is from [[#Library Linked Data|Library Linked Data]] and [http://www.w3.org/2005/Incubator/lld/wiki/UseCaseReport LLD-UC], specifically [http://www.w3.org/2005/Incubator/lld/wiki/Use_Case_Subject_Search Subject Search].

There is an existing collection at <nowiki><http://example.com/concept-scheme/subject-heading></nowiki> that defines a collection of subject headings. This collection is defined as a skos:ConceptScheme and
the client wishes to insert a new concept into the scheme. which will be related to the collection via a <nowiki>skos:inScheme</nowiki> link. The new subject-heading, "outer space exploration", is not necessarily owned by a container. The following RDF would be added to the (item-level) description of the collection.

<nowiki>
@prefix scheme : <http://example.com/concept-scheme/>.
@prefix concept : <http://example.com/concept/>.

scheme:subject-heading a skos:ConceptScheme.

concept:Outer+space+Exploration skos:inScheme scheme:subject-heading.
</nowiki>

====Alternative scenario: add a resource to multiple collections====
Logically, a resource should not be owned by more than one container. however, it may be a member of multiple collections which define a weaker form of ''aggregation''. As this is simply a manipulation of the RDF description of a collection, it should be possible to add the same resource to multiple collections.

As a machine-readable collection of medical terms, the [http://www.ihtsdo.org| SNOMED] ontology is of key importance in [[#Healthcare | healthcare]]. SNOMED CT allows concepts with more than one parent that don't fall into a lattice.
In the example below, the same concept may fall under two different parent concepts.
The example uses skos:narrowerTransitive to elide intervening concepts.

<nowiki>
@prefix : <http://example.com/snomed/>.

:_119376003 a skos:Concept ;
skos:prefLabel "Tissue specimen"
skos:narrowerTransitive :TissueSpecimenFromHeart.

:_127462005 a skos:Concept ;
skos:prefLabel "Specimen from heart"
skos:narrowerTransitive :TissueSpecimenFromHeart.

:_128166000 a skos:Concept;
rdfs:label "Tissue specimen from heart".
</nowiki>

===UC7: Filter resource description===
This use-case extends the normal behaviour of retrieving an RDF description of a resource, by dynamically excluding specific (membership) properties.
For containers, it is often desirable to be able to read a collection, or item-level description that excludes the container membership.

====Primary scenario: retrieve collection-level description====
This scenario, based on [[#Library Linked Data| Library Linked Data]], uses the Dublin Core Metadata Initiative [http://dublincore.org/groups/collections/collection-application-profile/| Collection-Level] description.
A collection can refer to any aggregation of physical or digital items.
This scenario covers the case whereby a client can request a collection-level description as typified by the example below, without necessarily having to download a full listing of the items within the collection.

<nowiki>
@prefix rdf: <rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">.
@prefix dc: <http://purl.org/dc/elements/1.1/>.
@prefix : <http://example.org/bookshelf/>.
@prefix dcmitype: <http://purl.org/dc/dcmitype/>.
@prefix cld: <http://purl.org/cld/terms/>.
@prefix dcterms: <http://purl.org/dc/terms/>.

<> dc:type dcmitype:Collection ;
dc:title "Directory of organizations working with Linked Data" ;
dcterms:abstract "This is a directory of organisations specializing in Linked Data."
cld:isLocatedAt <http://dir.w3.org>
cld:isAccessedVia <http://dir.w3.org/rdf/2012/directory/directory-list.xhtml?construct>
</nowiki>

====Alternative scenario: retrieve item-level description of a collection====
This use-case scenario, also based on [[#Library Linked Data| Library Linked Data]], focuses on obtaining an item-level description of the resources aggregated by a collection.
The simplest scenario is where the members of a collection are returned within a single representation, so that a client can explore the data by following these links. Different applications may use different membership predicates to capture this aggregation. The example below uses <nowiki>rdfs:member</nowiki>, but many different membership predicates are in common use, including RDF Lists.
Item-level descriptions can be captured using the Functional Requirements for Bibliographic Records ([http://www.ifla.org/publications/functional-requirements-for-bibliographic-records FRBR]) [http://vocab.org/frbr/core.html ontology].

<nowiki>
@prefix frbr: <http://purl.org/vocab/frbr/core#>.

<> rdfs:member <#ebooks97>, <#ebooks21279>.

<#work97> a frbr:LiteraryWork;
dc:title "Flatland: a romance of many dimensions" ;
frbr:creator <#Abbott_Edwin>;
frbr:manifestation <ebook97>.

<#work21279> a frbr:LiteraryWork;
dc:title "2 B R 0 2 B" ;
frbr:creator <#Vonnegut_Kurt>;
frbr:manifestation <ebook21279>.
</nowiki>

Collections are potentially very large, so some means may be required to limit the size of RDF representation returned by the LDP (e.g. pagination).

===UC8: Manage media resources===
It should be possible to easily add non-RDF media resources to containers that accept them. Media resources may be updated and removed during the lifecycle of the container.

====Primary scenario: access media resources====
From the User Story [[#Sharing Binary Resources and Metadata| Sharing Binary Resources and Metadata]] it should be possible to easily add non RDF resources to a containers that accept them. Clients submit a non-RDF representation to a container in a media type accepted by that container. The container creates a URI to represent this media resource, and creates a link from the container to the new URI.The media resource may have an explicit representation of the media type. It should be possible to find the metadata about such a resource and to access and edit it in the usual ways.

This example uses the [http://www.w3.org/TR/mediaont-10/#ont-ttl Ontology for Media Resources] to describe a media resource added to a collection.
<nowiki>
@prefix ma: <http://www.w3.org/ns/ma-ont#> .

<dataset> a ma:Collection ;
:hasMember <dataset/image1.jpg>

<dataset/image1.jpg> a ma:MediaResource ;
ma:hasFormat "image/jpeg" .
</nowiki>

====Alternative scenario: media-resource attachments====
A resource may have multiple ''renditions''; the idea that you can have a PDF and a JPEG representing the same thing. A user is trying to create a work order along with an attached image showing a faulty machine part. To the user and to the work order system, these two artifacts are managed as a set. A single request may create the work order, the attachment, and the relationship between them, atomically.
When the user retrieves the work order later, they expect a single request by default to retrieve the work order plus all attachments.
When the user updates the work order, e.g. to mark it completed, they only want to update the work order proper, not its attachments.
Users may add/remove/replace attachments to the work order during its lifetime.

== Requirements ==

===Functional Requirements===
# Create Containers, from [[#UC1: Manage containers]]
# Creation of nested containers, from [[#UC1: Manage containers]]
# Creation of resources (within a container), from [[#UC2: Manage resources]]
# Deletion of resources, from [[#UC2: Manage resources]]
# Moving contained resources, from [[#UC2: Manage resources]]
# Retrieve resource description, from [[#UC3: Retrieve resource description]]
# Retrieve description of a non-document resource, from [[#UC3: Retrieve resource description]]
# Enrichment (substituting update of existing resource), from [[#UC4: Update existing resource]]
# Selective update of a resource, from [[#UC4: Update existing resource]]
# Determine if a resource has changed, from [[#UC5: Determine if a resource has changed]]
# Add a resource to a collection, from [[#UC6: Aggregate resources]]
# Add a resource to multiple collections, from [[#UC6: Aggregate resources]]
# Retrieve collection-level description, from [[#UC7: Filter resource description]]
# Retrieve item-level description of a collection, from [[#UC7: Filter resource description]]
# Access media resources, from [[#UC8: Manage media resources]]
# Media-resource attachments, from [[#UC8: Manage media resources]]

===Non-Functional Requirements===

# Provide access guidance to resources, from [[#UC1: Manage containers]]
# Non-duplication of resources, from [[#UC2: Manage resources]]
# Distribution of resources, from [[#UC2: Manage resources]]
# Consistent, global naming, from [[#UC2: Manage resources]]
# Use standard vocabularies as appropriate, from [[#UC3: Retrieve resource description]]
# Scalable linking model, from [[#UC3: Retrieve resource description]]
# Unrestricted vocabulary, from [[#UC4: Update existing resource]]
# Resource descriptions are a "mix of simple data and collections", from [[#UC6: Aggregate resources]]
# Relative URIs enabling sharing of collections, from [[#UC6: Aggregate resources]]

== Acknowledgements ==
We would like to acknowledge the contributions of user-story authors; Christophe Guéret, Roger Menday, Eric Prud'hommeaux, Steve Speicher.

== References ==

Use Cases And Requirements

Sbattle2 — Mon, 10 Dec 2012 17:40:34 GMT

Sbattle2: /* Status of this Document */

= Linked Data Platform Use Cases And Requirements =

This is a working document used to collect use cases and requirements for consideration by the WG.
The starting point comes from [http://www.w3.org/Submission/2012/SUBM-ldbpucr-20120326/ Linked Data Basic Profile Use Cases and Requirements].

== Status of this Document ==

This document is currently under review pending release as a First Public Working Draft. While the editors have made every effort to identify a set of use-cases that are both evidenced in user-stories and in-scope of the charter, the document may yet be missing some key unidentified use-cases, or indeed, may include use-cases that ought to be removed. Furthermore, the coarse grouping of use-cases to avoid CRUDdy operations may not be to people's taste and is open to challenge.

Following feedback from the face-to-face, the use-cases are captured in a narrative style that describes a behaviour, or set of behaviours drawn from the user-stories. They are embellished with concrete examples drawn from representative user-stories. The aim throughout has been to avoid details of protocol (specifically the HTTP protocol), and use of any specific vocabulary that might be introduced by the LDP specification.

===Timetable===
* <strike>Nov 26? WG to confirm User Story content: add, remove, refine (see process below). Note: this is ONLY User Stories (not Use Cases, Use Case Scenarios or Requirements)</strike>
** <strike>Issues before Nov 26th? will be included into FPWD</strike>
* Editors to:
** <strike>Dec 3 refine User Stories based on feedback</strike>
** <strike>Dec 5 elaborate on Use Cases in support of User Stories</strike>
* Dec 10 - WG to review prior to FPWD
** Review period ends Dec 15th
** insert open issues into draft for FPWD
* Dec 17 - Publish FPWD
** convert wiki page to ReSpec for FPWD
* Dec ?? Deadline for publications by year end 2012

===To Be Done===
* <strike>Move [[#LDP_and_Authentication.2FAuthorization| LDP and Authentication]] to [http://www.w3.org/2012/ldp/wiki/AccessControl AccessControl]</strike>
* <strike>Complete [[#Alternative_scenario:_moving_contained_resources| moving contained resources]] scenario with content from ericP on issue-30.</strike>
* <strike>Augment [[#Cloud_Infrastructure_Management| Cloud Infrastructure Management]] scenario with content from Roger Menday.</strike>
* <strike>Ensure issue-40/41 are fully covered in [[#UC8:_Managing_non-RDF_Resources| UC8: Managing non-RDF Resources]]. 2 scenarios (single v multiple attachments) ?</strike>
* <strike>Contact owner of [[#Data_Sharing| Data Sharing]] user-story to determine if we keep or not.</strike>
* <strike>Review [[#Requirements| Requirements]] section for functional/non-functional requirements arising in UCs.</strike>
* <strike>Propose resolutions to open issues against UC&R where possible.</strike>
* <strike>Identify and acknowledge user-story contributors.</strike>
* <strike>Check hyperlinks</strike>
* Convert to ReSpec
* Annotate document with open issues against UC&R
** <strike>[http://www.w3.org/2012/ldp/track/issues/30 ISSUE-30] (OPEN)</strike>
** [http://www.w3.org/2012/ldp/track/issues/40 ISSUE-40] (PENDING REVIEW)
** [http://www.w3.org/2012/ldp/track/issues/41 ISSUE-41] (PENDING REVIEW)

=== Process to introduce new User Stories & Use Cases ===

Open an Issue in the tracker against the UC&R product. The WG will review these and decide whether they are valid.

== Scope and Motivation ==

Linked Data was defined by Tim Berners-Lee with the following guidelines [http://www.w3.org/DesignIssues/LinkedData.html]:

# Use URIs as names for things
# Use HTTP URIs so that people can look up those names
# When someone looks up a URI, provide useful information, using the standards (RDF*, SPARQL)
# Include links to other URIs. so that they can discover more things

These four rules have proven very effective in guiding and inspiring people to publish Linked Data on the web. The amount of data, especially public data, available on the web has grown rapidly, and an impressive number of extremely creative and useful “mashups” have been created using this data as result.

There has been much less focus on the potential of Linked Data as a model for managing data on the web - the majority of the Application Programming Interfaces (APIs) available on the Internet for creating and updating data follow a Remote Procedure Call (RPC) model rather than a Linked Data model.

If Linked Data were just another model for doing something that RPC models can already do, it would be of only marginal interest. Interest in Linked Data arises from the fact that applications with an interface defined using Linked Data can be much more easily and seamlessly integrated with each other than applications that offer an RPC interface. In many problem domains, the most important problems and the greatest value are found not in the implementation of new applications, but in the successful integration of multiple applications into larger systems.

Some of the features that make Linked Data exceptionally well suited for integration include:

* A single interface – defined by a common set of HTTP methods – that is universally understood and is constant across all applications. This is in contrast with the RPC architecture where each application has a unique interface that has to be learned and coded to.
* A universal addressing scheme – provided by HTTP URLs – for both identifying and accessing all “entities”. This is in contrast with the RPC architecture where there is no uniform way to either identify or access data.
* A simple yet extensible data model – provided by RDF – for describing data about a resource in a way which doesn’t require prior knowledge of vocabulary being used.

Experience implementing applications and integrating them using Linked Data has shown very promising results, but has also demonstrated that the original four rules defined by Tim Berners-Lee for Linked Data are not sufficient to guide and constrain a writable Linked Data API. As was the case with the original four rules, the need generally is not for the invention of fundamental new technologies, but rather for a series of additional rules and patterns that guide and constrain the use of existing technologies in the construction of a Basic Profile for Linked Data to achieve interoperability.

The following list illustrates a few of the issues that require additional rules and patterns:
* What URLs do I post to in order to create new resources?
* How do I get lists of existing resources, and how do I get basic information about them without having to access each one?
* How should I detect and deal with race conditions on write?
* What media-types/representations should I use?
* What standard vocabularies should I use?
* What primitive data types should I use?

A good goal for the Basic Profile for Linked Data would be to define a specification required to allow the definition of a writable Linked Data API equivalent to the simple application APIs that are often written on the web today using the Atom Publishing Protocol (APP). APP shares some characteristics with Linked Data, such as the use of HTTP and URLs. One difference is that Linked Data relies on a flexible data model with RDF, which allows for multiple representations.

== Organization of this Document ==

This document is organized as follows:

* '''[[#User Stories| User Stories]]''' capture statements about system requirements written from a user or application perspective. They are typically lightweight and informal and can run from one line to a paragraph or two (sometimes described as an 'epic') [http://www.agilemodeling.com/artifacts/userStory.htm]. Analysis of each user story will reveal a number of (functional) use-cases and other non-functional requirements. See [http://www.w3.org/TR/dap-policy-reqs/| Device API Access Control Use Cases and Requirements] for a good example of user stories and their analysis.

* '''[[#Use Cases| Use Cases]]''' are used to capture and model functional requirements. Use cases describe the system’s behavior under various conditions [http://alistair.cockburn.us/get/2465], cataloguing who does what with the system, for what purpose, but without concern for system design or implementation [http://www.bredemeyer.com/pdf_files/functreq.pdf]. Each use case is identified by a reference number to aid cross-reference from other documentation; use-case indexing in this document is based on [http://www.w3.org/TR/rdb2rdf-ucr/ rdb2rdf use-cases]. A variety of styles may be used to capture use-cases, from a simple narrative to a structured description with actors, pre/post conditions, and step-by-step behaviours as in [http://www.w3.org/TR/powder-use-cases/ POWDER: Use Cases and Requirements], and non-functional requirements raised by the use-case. Use cases act like the hub of a wheel, with spokes supporting requirements analysis, scenario-based evaluation, testing, and integration with non-functional, or quality requirements.

* '''Scenarios''' are more focused still, representing a single instance of a use case in action. Scenarios may range from lightweight narratives as seen in [http://www.w3.org/TR/media-frags-reqs/ Use cases and requirements for Media Fragments], to being formally modeled as interaction diagrams. Each use-case should include at least a primary scenario, and possibly other alternative scenarios.

* '''[[#Requirements| Requirements]]''' lists non-functional or quality requirements, and the use cases they may be derived from. This approach is exemplified in the [http://dvcs.w3.org/hg/gld/raw-file/default/dcat-ucr/index.html Use Cases and Requirements for the Data Catalog Vocabulary]. It also lists functional requirements that stem from use-cases. It is also possible at this stage to explicitly identify some use-cases as non-requirements.

== User Stories ==

=== Maintaining Social Contact Information ===

Many of us have multiple email accounts that include information about the people and organizations we interact with – names, email addresses, telephone numbers, instant messenger identities and so on. When someone’s email address or telephone number changes (or they acquire a new one), our lives would be much simpler if we could update that information in one spot and all copies of it would automatically be updated. In other words, those copies would all be linked to some definition of “the contact.” There might also be good reasons (like off-line email addressing) to maintain a local copy of the contact, but ideally any copies would still be linked to some central “master.”

Agreeing on a format for “the contact” is not enough, however. Even if all our email providers agreed on the format of a contact, we would still need to use each provider’s custom interface to update or replace the provider’s copy, or we would have to agree on a way for each email provider to link to the “master”. If we look outside our own personal interests, it would be even more useful if the person or organization exposed their own contact information so we could link to it.

What would work in either case is a common understanding of the resource, a few formats needed, and access guidance for these resources. This would support how to acquire a link to a contact, and how to use those links to interact with a contact (including [[#UC3: Retrieve resource description|reading]], [[#UC4: Update existing resource|updating]], and [[#Alternative scenario: delete resource|deleting]] it), as well as how to easily [[#Primary scenario: create resource|create a new contact]] and add it to my contacts and when deleting a contact, how it would be removed from my list of contacts. It would also be good to be able to add some application-specific data about my contacts that the original design didn’t consider. Ideally we’d like to eliminate multiple copies of contacts, there would be additional valuable information about my contacts that may be stored on separate servers and need a simple way to link this information back to the contacts. Regardless of whether a contact collection is my own, shared by an organization, or all contacts known to an email provider (or to a single email account at an email provider), it would be nice if they all worked pretty much the same way.

=== Keeping Track of Personal and Business Relationships ===

In our daily lives, we deal with many different organizations in many different relationships, and they each have data about us. However, it is unlikely that any one organization has all the information about us. Each of them typically gives us access to the information (at least some of it), many through websites where we are uniquely identified by some string – an account number, user ID, and so on. We have to use their applications to interact with the data about us, however, and we have to use their identifier(s) for us. If we want to build any semblance of a holistic picture of ourselves (more accurately, collect all the data about us that they externalize), we as humans must use their custom applications to find the data, copy it, and organize it to suit our needs.

Would it not be simpler if at least the Web-addressable portion of that data could be linked to consistently, so that instead of maintaining various identifiers in different formats and instead of having to manually supply those identifiers to each one’s corresponding custom application, we could essentially build a set of bookmarks to it all? When we want to [[#UC3: Retrieve resource description|examine]] or [[#UC4: Update existing resource|change]] their contents, would it not be simpler if there were a single consistent application interface that they all supported? Of course it would.

Our set of links would probably be a [[#UC6: Aggregate resources|simple collection]]. The information held by any single organization might be a mix of simple data and [[#UC6: Aggregate resources|collections of other data]], for example, a bank account balance and a collection of historical transactions. Our bank might easily have [[#Alternative scenario: create a nested container|a collection of accounts for each of its collection of customers]].

=== System and Software Development Tool Integration ===

System and software development tools typically come from a diverse set of vendors and are built on various architectures and technologies. These tools are purpose built to meet the needs for a specific domain scenario (modeling, design, requirements and so on.) Often tool vendors view integrations with other tools as a necessary evil rather than providing additional value to their end-users. Even more of an afterthought is how these tools’ data -- such as people, projects, customer-reported problems and needs -- integrate and relate to corporate and external applications that manage data such as customers, business priorities and market trends. The problem can be isolated by standardizing on a small set of tools or a set of tools from a single vendor, but this rarely occurs and if does it usually does so only within small organizations. As these organizations grow both in size and complexity, they have needs to work with outsourced development and diverse internal other organizations with their own set of tools and processes. There is a need for better support of more complete business processes (system and software development processes) that span the roles, tasks, and data addressed by multiple tools. This demand has existed for many years, and the tools vendor industry has tried several different architectural approaches to address the problem. Here are a few:

* Implement an API for each application, and then, in each application, implement “glue code” that exploits the APIs of other applications to link them together.
* Design a single database to store the data of multiple applications, and implement each of the applications against this database. In the software development tools business, these databases are often called “repositories.”
* Implement a central “hub” or “bus” that orchestrates the broader business process by exploiting the APIs described previously.

It is fair to say that although each of those approaches has its adherents and can point to some successes, none of them is wholly satisfactory. The use of Linked Data as an application integration technology has a strong appeal. [http://open-services.net/ OSLC]

=== Library Linked Data ===

The W3C Library Linked Data working group has a number of use cases cited in their Use Case Report. [http://www.w3.org/2005/Incubator/lld/wiki/UseCaseReport LLD-UC] These referenced use cases focus on the need to extract and correlate library data from disparate sources. Variants of these use cases that can provide consistent formats, as well as ways to improve or update the data, would enable simplified methods for both efficiently sharing this data as well as producing incremental updates without the need for repeated full extractions and import of data.

The 'Digital Objects Cluster' contains a number of relevant use-cases:

* Grouping: This should "Allow the end-users to define [[#UC6: Aggregate resources|groups of resources]] on the web that for some reason belong together. The relationship that exists between the resources is often left unspecified. Some of the resources in a group may not be under control of the institution that defines the groups."

* Enrichment: "Enable end-users to [[#UC4: Update existing resource|link resources together]]."

* Browsing: "[[#UC7: Filter resource description|Support end-user browsing through groups]] and resources that belong to the groups."

* Re-use: "Users should have the capability to re-use all or parts of a collection, with all or part of its metadata, elsewhere on the linked Web."

The 'Collections' cluster also contains a number of relevant use-cases:

* Collection-level description: "Provide [[#UC7: Filter resource description|metadata pertaining to a collection as a whole]], in contrast to item-level description."

* Collections discovery: "Enable innovative collection discovery such as identification of nearest location of a physical collection where a specific information resource is found or mobile device applications ... based on collection-level descriptions."

* Community information services: Identify and classify collections of special interest to the community.

=== Municipality Operational Monitoring ===

Across various cities, towns, counties, and various municipalities there is a growing number of services managed and run by municipalities that produce and consume a vast amount of information. This information is used to help monitor services, predict problems, and handle logistics. In order to effectively and efficiently collect, produce, and analyze all this data, a fundamental set of loosely coupled standard data sources are needed. A simple, low-cost way to [[#UC3: Retrieve resource description|expose data]] from the diverse set of monitored services is needed, one that can easily integrate into the municipalities of other systems that inspect and analyze the data. All these services have links and dependencies on other data and services, so having a simple and scalable linking model is key.

=== Healthcare ===

For physicians to analyze, diagnose, and propose treatment for patients requires a vast amount of complex, changing and growing knowledge. This knowledge needs to come from a number of sources, including physicians’ own subject knowledge, consultation with their network of other healthcare professionals, public health sources, food and drug regulators, and other repositories of medical research and recommendations.

To diagnose a patient’s condition requires current data on the patient’s medications and medical history. In addition, recent pharmaceutical advisories about these medications are linked into the patient’s data. If the patient experiences adverse affects from medications, these physicians need to publish information about this to an appropriate regulatory source. Other medical professionals require access to both validated and emerging effects of the medication. Similarly, if there are geographical patterns around outbreaks that allow both the awareness of new symptoms and treatments, this information needs to quickly reach a very distributed and diverse set of medical information systems. Also, reporting back to these regulatory agencies regarding new occurrences of an outbreak, including additional details of symptoms and causes, is critical in producing the most effective treatment for future incidents.

=== Metadata Enrichment in Broadcasting ===

There are many different use cases when broadcasters show interest in metadata [[#UC4: Update existing resource| enrichment]]:

* enrich archive or news metadata by linking facts, events, locations and personalities
* enrich metadata generated by automatic extraction tools such as person identification, etc.
* enrich definitions of terms in classification schemes or enumeration lists

This comes in support of more effective information management and data/content mining (if you can't find your content, it' like if you don't have and must either recreate or acquire it again, which is not financially effective).

However, there is a need for solutions facilitating linkage to other data sources and taking care of the issues such as discovery, automation, disambiguation. Etc. Other important issues that broadcasters would face are the editorial quality of the linked data, its persistence, and usage rights.

=== Aggregation and Mashups of Infrastructure Data ===

For infrastructure management (such as storage systems, virtual machine environments, and similar IaaS and PaaS concepts), it is important to provide an environment in which information from different sources can be [[#UC6: Aggregate resources|aggregated]], [[#UC7: Filter resource description|filtered]], and visualized effectively. Specifically, the following use cases need to be taken into account:

* While some data sources are based on Linked Data, others are not, and aggregation and mashups must work across these different sources.
* Consumers of the data sources and aggregated/filtered data streams are not necessarily implementing Linked Data themselves, they may be off-the-shelf components such as dashboard frameworks for composing visualizations.
* Simple versions of this scenario are pull-based, where the data is requested from data sources. In more advanced settings, without a major change in architecture it should be possible to move to a push-based interaction model, where data sources push notifications to subscribers, and data sources provide different services that consumers can subscribe to (such as "informational messages" or "critical alerts only").

In this scenario, the important factors are to have abstractions that allow easy aggregation and filtering, are independent from the internal data model of the sources that are being combined, and can be used for pull-based interactions as well as for push-based interactions.

=== Sharing payload of RDF data among low-end devices ===

Several projects around the idea of [http://worldwidesemanticweb.wordpress.com/ downscaling the Semantic Web] need to be able to ship payloads of RDF across the nodes member of a given network. The transfers are done in a constrained context in terms of bandwidth, scope of the local semantics employed by the nodes and computing capabilities of the nodes. In a P2P style, every node has the capability to act either as a data consumer or a data provider, serving its own data or acting as a relay to pass other's data along (typically in mesh networks).

The transfer of an arbitrary payload of RDF data could be implemented through the container mechanism, adding and removing sets of RDF triples to it. Currently, one of the project "SemanticXO" uses named graphs and the graph protocol to create/delete/copy graphs across the nodes but this (almost) imposes the usage of a triple store. Unfortunately, triple store are rather demanding piece of software that are not always usable on limited hardware. Some generic ReST like interaction backed up with a lightweight column store would be better approach.

=== Sharing Binary Resources and Metadata ===

When publishing datasets about stars one may want to publish links to the pictures in which those stars appear, and this may well require publishing the pictures themselves. Vice versa: when publishing a picture of space we need to know which telescope took the picture, which part of the sky it was pointing at, what filters were used, which identified stars are visible, who can read it, who can write to it, ...

If LinkedData contains information about resources that are most naturally expressed in non-rdf formats (be they binary such as pictures or videos, or human readable documents in XML formats), those non RDF formats should be just as easy to publish to the LinkedData server as the RDF relations that link those resources up. A LinkedData server should therefore allow publishing of non linked data resources too, and make it easy to publish and edit metadata about those resources.

The resource comes in two parts - the image and information about the image (which may in the image file but better external to it as it's more general). The information about the image is vital. It's a compound item of image data and other data (being application metadata about the image does not distinguish from the platform's point-of-view.

=== Data Catalogs ===

The Asset Description Metadata Schema ([http://joinup.ec.europa.eu/asset/adms/home ADMS]) provides the data model to describe semantic assets repositories contents, but this leaves many open challenges when building a federation of these repositories to serve the need of assets reuse. These include accessing and querying individual repositories and efficiently retrieving [[#UC5: Determine if a resource has changed| updated content]] without having to retrieve the whole content. Hence, we chose to build the integration solution capitalizing on the Data Warehousing integration approach. This allows us to cope with heterogeneity of sources technologies and to benefit from the optimized performance it offers, given that individual repositories do not usually change frequently. With Data Warehousing, the federation requires to:

* understand the data, i.e. understand their semantic descriptions, and other systems.
* seamlessly exchange the semantic assets metadata from different repositories
* keep itself up-to-date.

Repositories owners can maintain de-referenceable URIs for their repository description and contained assets in a Linked Data compatible manner. ADMS provides the necessary data model to enable meaningful exchange of data. However, This leaves the challenge of efficient access to the data not fully addressed.

Related: [http://spec.datacatalogs.org/ Data Catalog Schema and Protocol]

=== Constrained Devices and Networks ===

Information coming from resource constrained devices in the Web of Things ([http://en.wikipedia.org/wiki/Web_of_Things WoT]) has been identified as a major driver in many domains, from smart cities to environmental monitoring to real-time tracking. The amount of information produced by these devices is growing exponentially and needs to be accessed and integrated in a systematic, standardized and cost efficient way. By using the same standards as on the Web, integration with applications will be simplified and higher-level interactions among resource constrained devices, abstracting away heterogeneities, will become possible. Up-coming IoT/WoT standards such as [http://datatracker.ietf.org/wg/6lowpan/ 6LowPAN] - IPv6 for resource constrained devices - and the Constrained Application Protocol ([http://tools.ietf.org/html/draft-ietf-core-coap CoAP]), which provides a downscaled version of HTTP on top of UDP for the use on constrained devices, are already at a mature stage. The next step now is to support RESTful interfaces also on resource constrained devices, adhering to the Linked Data principles. Due to the limited resources available, both on the device and in the network (such as bandwidth, energy, memory) a solution based on SPARQL Update is at the current point in time considered not to be useful and/or feasible. An approach based on the [http://tools.ietf.org/html/draft-castellani-core-http-mapping HTTP-CoAP Mapping] would enable constrained devices to directly participate in a Linked Data-based environment.

=== Services Supporting the Process of Science ===
Many fields of science now include branches with in silico data-intensive methods, e.g. bioinformatics, astronomy. To support these new methods we look to move beyond the established platforms provided by scientific workflow systems to capture, assist, and preserve the complete lifecycle from record of the experiment, through local trusted sharing, analysis, dissemination (including publishing of experimental data "beyond the PDF"), and re-use.

* [[#UC6: Aggregate resources|Aggregations]], specifically ''Research Objects (ROs)'' that are exchanged between services and clients bringing together workflows, data sets, annotations, and provenance. We use an RDF model for this. While some aggregated contents are encoded using RDF and in increasing number are linked data sources, others are not; while some are stored locally "within" the RO, others are remote (in both cases this is often due to size of the resources or access policies).
* Services that are distributed and linked. Some may be centralising for e.g. publication, others may be local, e.g. per lab. We need lightweight services that can be simply and easily integrated into and scale across the wide variety of softwares and data used in science: we have adopted a RESTful approach where possible.
** Foundation services that collect and expose ROs for storage, modification, exploration, and reuse.
** Services that provide added-value to ROs such as seamless import/export from scientific workflow systems, automated stability evaluation, or recommendation (and therefore interact with the foundation services to retrieve/store/modify/ROs).

seeAlso: [http://www.wf4ever-project.org/ Wf4Ever]

=== Project Membership Information : Information Evolution ===

Information about people and projects changes as roles change, as organisations change
and as contact details change. Finding the current state of a project is important
in enabling people to contact the right person in the right role. It can also be
useful to look back and see who was performing what role in the past.

A use of a Linked Data Platform could be to give responsibility for managing
such information with the project team itself, not requiring updates to be
requested of a centralised website administrator.

This could be achieved with:

* Resource descriptions for each person and project
* A container resource to describe roles/membership in the project.

To retain the history of the project, the old version of a resources,
including container resources, should be retained so there is a need to address both specific items
and also have a notion of "current".

Access to information has two aspects:
* Access to the "current" state, regardless of the version of the resource description
* Access to historical state, via access to a specific version of the resource description

=== Cloud Infrastructure Management===

Cloud operators offer API support to provide customers with remote access for the management of Cloud infrastructure (IaaS). Infrastructure consists of Systems, Computers, Networks, Discs, etc. The overall structure can be seen as mostly hierarchical, (Cloud contains Systems, Systems contain Machines, etc), complemented with crossing links (e.g. multiple Machines connected to a Network).

The IaaS scenario makes specific requirements on lifecycle management and discovery, handling non-instant changes, history capture and query:

* Many aspects of Cloud infrastructure have associated lifecycle, e.g. a Computer can be transitioned between Running and Shutdown. This should be manageable through the API, which should include how a client discovers dynamic lifecycle options and thus help steering through an application.
* It is often the case that attaining a new lifecycle state is not instantaneous. Clients require a universal mechanism for monitoring such changes.
* A facility to retrieve all events in the lifecycle of a resource can be useful.
* Query provides the means to interrogate the resources behind the API, as well as finding new entry points into the application.

Infrastructure management may be viewed as the manipulation of the underlying graph of resources.

== Use Cases ==
The following use-cases are each derived from one or more of the user-stories above. These use-cases are explored in detail through the development of scenarios, each motivated by some key aspect exemplified by a single user-story. The examples they contain are included purely for illustrative purposes, and should not be interpreted normatively.

===UC1: Manage containers===
A number of user-stories introduce the idea of a ''container'' as a mechanism for creating and managing resources within the context of an application. Resources grouped together within the same container would typically belong to the same application. A container is identified by a URI so is a resource in its own right.
The properties of a container may also represent the ''affordances'' of that container, enabling clients to determine what other operations they can do on that container. These operations may include descriptions of application specific services that can be invoked by exchanging RDF documents.

* Provide "access guidance for ... resources" (affordances) (from user-story, [[#Maintaining Social Contact Information|Maintaining Social Contact Information]]).

====Primary scenario: create container====
Create a new container resource within the LDP server.
In [[#Services Supporting the Process of Science|Services supporting the process of science]], [http://wf4ever.github.com/ro-primer/ Research Objects] are semantically rich aggregations of resources that bring together data, methods and people in scientific investigations. A basic workflow research object will be created to aggegate [http://ceur-ws.org/Vol-903/paper-01.pdf scientific workflows] and the artefacts that result from this workflow. The research object begins life as an empty container into which workflows, datasets, results and other data will be added throughout the lifecycle of the project.

<nowiki>
@prefix ro: http://purl.org/wf4ever/ro#
@prefix dct: http://purl.org/dc/terms/
@prefix ore: http://www.openarchives.org/ore/

<> a ro:ResearchObject, ore:Aggregation ;
dct:created "2012-12-01"^^xsd:dateTime .
</nowiki>

====Alternative scenario: create a nested container====
The motivation for nested containers comes from the [[#System and Software Development Tool Integration| System and Software Development Tool Integration]] user-story. The OSLC Change Management vocabulary allows bug reports to have attachments referenced by the membership predicate <nowiki>oslc_cm:attachment</nowiki>. The 'top-level-container' contains issues, and each issue resource has its own container of attachment resources.

<nowiki>
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix oslc_cm: <http://open-services.net/ns/cm#>.
@prefix : <http://example.org/>.

:top-level-container rdfs:member :issue1234 .

:issue1234 a oslc_cm:ChangeRequest;
dcterms:identifier "1234";
dcterms:type "a bug";
dcterms:related :issue1235 ;
oslc_cm:attachments :attachments123.

:issue1235 a oslc_cm:ChangeRequest;
dcterms:title "a related bug".

:attachments a oslc_cm:AttachmentList;
oslc_cm:attachment :attachment324, :attachment251.
</nowiki>

===UC2: Manage resources===
This use-case addresses the managed lifecycle of a resource and is concerned with resource ''ownership''. The responsibility for managing resources belongs with their container.
For example, a container may accept a request from a client to make a new resource.
This use-case focuses on creation and deletion of resources in the context of a container, and the potential for transfer of ownership by moving resources between containers.
The ownership of a resource should always be clear; no resource managed in this way should ever be owned by more than one container.

Once a new resource has been created it should be identified by a URI. Clients may defer responsibility for establishing dereferenceable URIs to the container of their data.
The container is a natural choice for the endpoint for this interface as it will already have some application-specific knowledge about the contained resources.
While the LDP has ultimate control over resource naming, some applications may require more control over naming, perhaps to provide a more human-readable URI. An LDP server could support something like the [http://tools.ietf.org/html/rfc5023 Atom Publishing Protocol] slug header to convey a user defined naming 'hint'.

* Non-duplication of resources: "Eliminate multiple copies", representing resources in a single place (from [[#Maintaining Social Contact Information]]).
* Distribution of resources: Linked aata "may be stored on separate servers" (from [[#Maintaining Social Contact Information]]).
* Consistent, global naming: Resources should be "linked to consistently, ... instead of maintaining various identifiers in different formats" (from [[#Keeping Track of Personal and Business Relationships]]).

====Primary scenario: create resource====
Resources begin life by being created within a container. From user-story, [[#Maintaining Social Contact Information|Maintaining Social Contact Information]], It should be possible to "easily create a new contact and add it to my contacts." This suggests that resource creation is closely linked to the application context. The new resource is created in a container representing "my contacts." The lifecycle of the resource is linked to the lifecycle of it's container. So, for example, if "my contacts" is deleted then a user would also reasonably expect that all contacts within it would also be deleted.

Contact details are captured as an RDF description and it's properties, including "names, email addresses, telephone numbers, instant messenger identities and so on." The description may include non-standard RDF; "data about my contacts that the original design didn’t consider."
The following RDF could be used to describe contact information using the [http://www.foaf-project.org FOAF] vocabulary. A contact is represented here by a <nowiki>foaf:PersonalProfileDocument</nowiki> defining a resource that can be created and updated as a single-unit, even though it may describe ancillary resources, such as a <nowiki>foaf:Person</nowiki>, below.

<nowiki>
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

<> a foaf:PersonalProfileDocument;
foaf:PrimaryTopic [
a foaf:Person;
foaf:name "Timothy Berners-Lee";
foaf:title "Sir";
foaf:firstName "Timothy";
foaf:surname "Berners-Lee";
foaf:nick "TimBL", "timbl";
foaf:homepage <http://www.w3.org/People/Berners-Lee/>;
foaf:weblog <http://dig.csail.mit.edu/breadcrumbs/blog/4>;
foaf:mbox <mailto:timbl@w3.org>;
foaf:workplaceHomepage <http://www.w3.org/>.
]
</nowiki>

====Alternative scenario: delete resource====
Delete a resource and all it's properties. If the resource resides within a container it will be removed from that container, however other links to the deleted resource may be left as dangling references.
In the case where the resource is a container, the server may also delete any or all contained resources.
In normal practice, a deleted resource cannot be reinstated. There are however, edge-cases where limited undelete may be desirable.
Best practice states that "[http://www.w3.org/TR/cooluris/| Cool URIs don't change]", which implies that deleted URIs shouldn't be recycled.

====Alternative scenario: moving contained resources====
Many resources may have value beyond the life of their membership in a container. This implies methods to add references to revise container membership.
Cloning container members for use in other containers results in duplication of information and maintenance problems; web practice is to encourage the creation of one resource, which may be referenced as many places as necessary. A change of ownership may - or may not - imply a change of URI, depending upon the specific LDP naming policy. While assigning a new URI to a resource is discouraged [http://www.w3.org/DesignIssues/Architecture.html#HTTP], it is possible to indicate that a resource has moved with an appropriate HTTP response.

===UC3: Retrieve resource description===
Access the current description of a resource, containing properties of that resource and links to related resources. The representation may include descriptions of related resources that cannot be accessed directly.
Depending upon the application, an LDP may enrich the retrieved RDF with additional triples. Examples include adding incoming links, sameAs closure and type closure.
The HTTP response should also include versioning information (i.e. last update or entity tag) so that subsequent updates can ensure they are being applied to the correct version.

* Use standard vocabularies as appropriate to enable a "common understanding of the resource" (from [[#Maintaining Social Contact Information|Maintaining Social Contact Information]]).
* A "scalable linking model is key" (from [[#Municipality Operational Monitoring]]).

====Primary scenario====
The user-story [[#Project Membership Information : Information Evolution| Project Membership Information]] discusses the representation of information about people and projects. It calls for "Resource descriptions for each person and project" allowing project teams to review information held about these resources. The example below illustrates the kinds of information that might be held about organizational structures based on the [http://www.epimorphics.com Epimorphics] [http://www.epimorphics.com/public/vocabulary/org.html organizational ontology].

Note that the example below defines two resources (shown as separate sections below) that will be hosted on an LDP based at <nowiki>http://example.com/</nowiki>. The representations of these resources may include descriptions of related resources, such as <nowiki>http://www.w3.org/</nowiki>, that that fall under a different authority and therefore can't be served from the LDP at this location.

<nowiki>
@prefix org: <http://www.w3.org/ns/org#> .
@prefix owltime: <http://www.w3.org/2006/time> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@base <http://example.com/> .

<member1> a org:Membership ;
org:member <http://www.w3.org/People/Berners-Lee/card#i> ;
org:organization http://www.w3.org/> ;
org:role <director> ;
org:memberDuring [a owltime:Interval; owltime:hasBeginning [
owltime:inXSDDateTime "1994-10-01T00:00:00Z"^^xsd:dateTime]] .

<http://www.w3.org/> a org:FormalOrganization ;
skos:prefLabel "The World Wide Web Consortium"@en ;
skos:altLabel "W3C" .
</nowiki>

<nowiki>
@prefix org: <http://www.w3.org/ns/org#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@base <http://example.com/> .

<director> a org:Role ;
rdfs:label "Director" .
</nowiki>

====Alternative scenario: retrieve description of a non-document resource====
In many cases, the things that are of interest are not always the things that are resolvable. The example below demonstrates how a foaf profile may be used to distinguish between the person and the profile; the former being the topic of the latter. This begs the question as to what a client should do with such non-document resources. In this case the HTTP protocol requires that the fragment part be stripped off before requesting the URI from the server. The result is a resolvable URI for the profile.

<nowiki>
@base <http://www.w3.org/People/Berners-Lee/card>
@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@prefix dc: <http://purl.org/dc/elements/1.1/>.

<> a foaf:PersonalProfileDocument ;
dc:title "Tim Berners-Lee's FOAF file" ;
foaf:homepage <http://www.w3.org/People/Berners-Lee/> ;
foaf:primaryTopic <#i> .
</nowiki>

===UC4: Update existing resource===
Change the RDF description of a LDP resource, potentially removing or overwriting existing data. This allows applications to ''enrich'' the representation of a resource by addling additional links to other resources.

* Unrestricted vocabulary: It should be possible be "able to add ... application-specific data" to resources (from [[#Maintaining Social Contact Information]]).

====Primary scenario: enrichment====
This relates to user-story [[#Metadata Enrichment in Broadcasting| Metadata Enrichment in Broadcasting]] and is based on the [http://www.bbc.co.uk/ontologies/sport/ BBC Sports Ontology]. The ''resource-centric'' view of linked-data provides a natural granularity for substituting, or overwriting a resource and its data. The simplest kind of update would simply replace what is currently known about a resource with a new representation. There are two distinct resources in the example below; a sporting event and an associated award. The granularity of the LDP would allow a user to replace the information about the award without disturbing the information about the event.

<nowiki>
@prefix sport: <http://www.bbc.co.uk/ontologies/sport/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

:mens_sprint a sport:MultiStageCompetition;
rdfs:label "Men's Sprint";
sport:award <#gold_medal> .

<#gold_medal> a sport:Award .
</nowiki>

We can enrich the description as events unfold, linking to the winner of the gold medal by substituting the above description with the following.

<nowiki>
@prefix sport: <http://www.bbc.co.uk/ontologies/sport/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

:mens_sprint a sport:MultiStageCompetition;
rdfs:label "Men's Sprint";
sport:award <#gold_medal> .
<#gold_medal> a sport:Award;
sport:awarded_to [
a foaf:Agent ;
foaf:name "Chris Hoy" .
] .
</nowiki>

====Alternative scenario: selective update of a resource====
This relates to user-story [[#Data Catalogs|Data Catalogs]], based on the [http://vocab.deri.ie/dcat Data Catalog Vocabulary].
A catalogue is described by the following RDF model.

<nowiki>
@prefix dcat: <http://www.w3.org/ns/dcat#> .
@prefix dcterms: <http://purl.org/dc/terms/> .

:catalog a dcat:Catalog ;
dcat:dataset :dataset/001;
dcterms:issued "2012-12-11"^^xsd:date.
</nowiki>

A catalog may contain multiple datasets, so when linking to new datasets it would be simpler and preferable to selectively add just the new dataset links.
A Talis ''changeset'' [http://docs.api.talis.com/getting-started/changesets][http://www.w3.org/2009/12/rdf-ws/papers/ws07] could be used to add a new <nowiki>dc:title</nowiki> to the dataset. The following update would be directed to the catalogue to add an additional dataset.

<nowiki>
@prefix : <http://example.com/>.
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix cs: <http://purl.org/vocab/changeset/schema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.

<change1>
a cs:ChangeSet ;
cs:subjectOfChange :catalog ;
cs:createdDate "2012-01-01T00:00:00Z" ;
cs:changeReason "Update catalog datasets" ;
cs:addition [
a rdf:Statement ;
rdf:subject :catalog ;
rdf:predicate dcat:dataset ;
rdf:object :dataset/002 .
] .
</nowiki>

===UC5: Determine if a resource has changed===
It should be possible to retrieve versioning information about a resource (e.g. last modified or entity tag) without having to download a representation of the resource.
This information can then be compared with previous information held about that resource to determine if it has changed.
This versioning information can also be used in subsequent ''conditional'' requests to ensure they are only applied if the version is unchanged.

====Primary scenario====
Based on the user-story, [[#Constrained Devices and Networks| Constrained Devices and Networks]], an LDP could be configured to act as a proxy for a [http://tools.ietf.org/html/draft-ietf-core-coap CoAP] based [http://en.wikipedia.org/wiki/Web_of_Things Web of Things]. As an observer of CoAP resources, the LDP registers its interest so that it will be notified whenever the sensor reading changes. Clients of the LDP can interrogate the LDP to determine if the state has changed.

In this example, the information about a sensor and corresponding sensor readings can be represented as RDF resources. The first resource below, represents a sensor described using the [http://www.w3.org/2005/Incubator/ssn/ Semantic Sensor Network] ontology.
<nowiki>
@prefix : <http://example.com/energy-management/>.

<> a :MainsFrequencySensor;
rdfs:comment "Sense grid load based on mains frequency";
ssn:hasMeasurementCapability [
a :FrequencyMeasurementCapability;
ssn:hasMeasurementProperty <#property_1> .
] .
</nowiki>

The value of the sensor changes in real-time as measurements are taken. The LDP client can interrogate the resource below to determine if it has changed, ''without'' necessarily having to download the RDF representation. As different sensor properties are represented disjointly (separate RDF representations) they may change independently.

<nowiki>
@prefix : <http://example.com/energy-management/>.

<http://example.com/energy-management#property_1> :hasMeasurementPropertyValue <> .
<> a :FrequencyValue;
:hasQuantityValue "50"^^xsd:float.
</nowiki>

===UC6: Aggregate resources===
There is a requirement to be able to manage ''collections'' of resources. The concept of a collection overlaps with, but is distinct from that of a container. These collections are (weak) aggregations, unrelated to the lifecycle management of resources, and distinct from the ownership between a resource and its container. However, the composition of a container may be reflected as a collection to support navigation of the container and its contents. There is a need to be able to create collections by adding and deleting individual membership properties. Resources may belong to multiple collections, or to none.

* Resource descriptions are a "mix of simple data and collections" (from [[#Keeping Track of Personal and Business Relationships]]).
* Relative URIs: It should be possible to "ship payloads of RDF" for a collection as a whole without breaking internal links (from [[#Constrained Devices and Networks]]).

====Primary scenario: add a resource to a collection====
This example is from [[#Library Linked Data|Library Linked Data]] and [http://www.w3.org/2005/Incubator/lld/wiki/UseCaseReport LLD-UC], specifically [http://www.w3.org/2005/Incubator/lld/wiki/Use_Case_Subject_Search Subject Search].

There is an existing collection at <nowiki><http://example.com/concept-scheme/subject-heading></nowiki> that defines a collection of subject headings. This collection is defined as a skos:ConceptScheme and
the client wishes to insert a new concept into the scheme. which will be related to the collection via a <nowiki>skos:inScheme</nowiki> link. The new subject-heading, "outer space exploration", is not necessarily owned by a container. The following RDF would be added to the (item-level) description of the collection.

<nowiki>
@prefix scheme : <http://example.com/concept-scheme/>.
@prefix concept : <http://example.com/concept/>.

scheme:subject-heading a skos:ConceptScheme.

concept:Outer+space+Exploration skos:inScheme scheme:subject-heading.
</nowiki>

====Alternative scenario: add a resource to multiple collections====
Logically, a resource should not be owned by more than one container. however, it may be a member of multiple collections which define a weaker form of ''aggregation''. As this is simply a manipulation of the RDF description of a collection, it should be possible to add the same resource to multiple collections.

As a machine-readable collection of medical terms, the [http://www.ihtsdo.org| SNOMED] ontology is of key importance in [[#Healthcare | healthcare]]. SNOMED CT allows concepts with more than one parent that don't fall into a lattice.
In the example below, the same concept may fall under two different parent concepts.
The example uses skos:narrowerTransitive to elide intervening concepts.

<nowiki>
@prefix : <http://example.com/snomed/>.

:_119376003 a skos:Concept ;
skos:prefLabel "Tissue specimen"
skos:narrowerTransitive :TissueSpecimenFromHeart.

:_127462005 a skos:Concept ;
skos:prefLabel "Specimen from heart"
skos:narrowerTransitive :TissueSpecimenFromHeart.

:_128166000 a skos:Concept;
rdfs:label "Tissue specimen from heart".
</nowiki>

===UC7: Filter resource description===
This use-case extends the normal behaviour of retrieving an RDF description of a resource, by dynamically excluding specific (membership) properties.
For containers, it is often desirable to be able to read a collection, or item-level description that excludes the container membership.

====Primary scenario: retrieve collection-level description====
This scenario, based on [[#Library Linked Data| Library Linked Data]], uses the Dublin Core Metadata Initiative [http://dublincore.org/groups/collections/collection-application-profile/| Collection-Level] description.
A collection can refer to any aggregation of physical or digital items.
This scenario covers the case whereby a client can request a collection-level description as typified by the example below, without necessarily having to download a full listing of the items within the collection.

<nowiki>
@prefix rdf: <rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">.
@prefix dc: <http://purl.org/dc/elements/1.1/>.
@prefix : <http://example.org/bookshelf/>.
@prefix dcmitype: <http://purl.org/dc/dcmitype/>.
@prefix cld: <http://purl.org/cld/terms/>.
@prefix dcterms: <http://purl.org/dc/terms/>.

<> dc:type dcmitype:Collection ;
dc:title "Directory of organizations working with Linked Data" ;
dcterms:abstract "This is a directory of organisations specializing in Linked Data."
cld:isLocatedAt <http://dir.w3.org>
cld:isAccessedVia <http://dir.w3.org/rdf/2012/directory/directory-list.xhtml?construct>
</nowiki>

====Alternative scenario: retrieve item-level description of a collection====
This use-case scenario, also based on [[#Library Linked Data| Library Linked Data]], focuses on obtaining an item-level description of the resources aggregated by a collection.
The simplest scenario is where the members of a collection are returned within a single representation, so that a client can explore the data by following these links. Different applications may use different membership predicates to capture this aggregation. The example below uses <nowiki>rdfs:member</nowiki>, but many different membership predicates are in common use, including RDF Lists.
Item-level descriptions can be captured using the Functional Requirements for Bibliographic Records ([http://www.ifla.org/publications/functional-requirements-for-bibliographic-records FRBR]) [http://vocab.org/frbr/core.html ontology].

<nowiki>
@prefix frbr: <http://purl.org/vocab/frbr/core#>.

<> rdfs:member <#ebooks97>, <#ebooks21279>.

<#work97> a frbr:LiteraryWork;
dc:title "Flatland: a romance of many dimensions" ;
frbr:creator <#Abbott_Edwin>;
frbr:manifestation <ebook97>.

<#work21279> a frbr:LiteraryWork;
dc:title "2 B R 0 2 B" ;
frbr:creator <#Vonnegut_Kurt>;
frbr:manifestation <ebook21279>.
</nowiki>

Collections are potentially very large, so some means may be required to limit the size of RDF representation returned by the LDP (e.g. pagination).

===UC8: Manage media resources===
It should be possible to easily add non-RDF media resources to containers that accept them. Media resources may be updated and removed during the lifecycle of the container.

====Primary scenario: access media resources====
From the User Story [[#Sharing Binary Resources and Metadata| Sharing Binary Resources and Metadata]] it should be possible to easily add non RDF resources to a containers that accept them. Clients submit a non-RDF representation to a container in a media type accepted by that container. The container creates a URI to represent this media resource, and creates a link from the container to the new URI.The media resource may have an explicit representation of the media type. It should be possible to find the metadata about such a resource and to access and edit it in the usual ways.

This example uses the [http://www.w3.org/TR/mediaont-10/#ont-ttl Ontology for Media Resources] to describe a media resource added to a collection.
<nowiki>
@prefix ma: <http://www.w3.org/ns/ma-ont#> .

<dataset> a ma:Collection ;
:hasMember <dataset/image1.jpg>

<dataset/image1.jpg> a ma:MediaResource ;
ma:hasFormat "image/jpeg" .
</nowiki>

====Alternative scenario: media-resource attachments====
A resource may have multiple ''renditions''; the idea that you can have a PDF and a JPEG representing the same thing. A user is trying to create a work order along with an attached image showing a faulty machine part. To the user and to the work order system, these two artifacts are managed as a set. A single request may create the work order, the attachment, and the relationship between them, atomically.
When the user retrieves the work order later, they expect a single request by default to retrieve the work order plus all attachments.
When the user updates the work order, e.g. to mark it completed, they only want to update the work order proper, not its attachments.
Users may add/remove/replace attachments to the work order during its lifetime.

== Requirements ==

===Functional Requirements===
# Create Containers, from [[#UC1: Manage containers]]
# Creation of nested containers, from [[#UC1: Manage containers]]
# Creation of resources (within a container), from [[#UC2: Manage resources]]
# Deletion of resources, from [[#UC2: Manage resources]]
# Moving contained resources, from [[#UC2: Manage resources]]
# Retrieve resource description, from [[#UC3: Retrieve resource description]]
# Retrieve description of a non-document resource, from [[#UC3: Retrieve resource description]]
# Enrichment (substituting update of existing resource), from [[#UC4: Update existing resource]]
# Selective update of a resource, from [[#UC4: Update existing resource]]
# Determine if a resource has changed, from [[#UC5: Determine if a resource has changed]]
# Add a resource to a collection, from [[#UC6: Aggregate resources]]
# Add a resource to multiple collections, from [[#UC6: Aggregate resources]]
# Retrieve collection-level description, from [[#UC7: Filter resource description]]
# Retrieve item-level description of a collection, from [[#UC7: Filter resource description]]
# Access media resources, from [[#UC8: Manage media resources]]
# Media-resource attachments, from [[#UC8: Manage media resources]]

===Non-Functional Requirements===

# Provide access guidance to resources, from [[#UC1: Manage containers]]
# Non-duplication of resources, from [[#UC2: Manage resources]]
# Distribution of resources, from [[#UC2: Manage resources]]
# Consistent, global naming, from [[#UC2: Manage resources]]
# Use standard vocabularies as appropriate, from [[#UC3: Retrieve resource description]]
# Scalable linking model, from [[#UC3: Retrieve resource description]]
# Unrestricted vocabulary, from [[#UC4: Update existing resource]]
# Resource descriptions are a "mix of simple data and collections", from [[#UC6: Aggregate resources]]
# Relative URIs enabling sharing of collections, from [[#UC6: Aggregate resources]]

== Acknowledgements ==
We would like to acknowledge the contributions of user-story authors; Christophe Guéret, Roger Menday, Eric Prud'hommeaux, Steve Speicher.

== References ==

Use Cases And Requirements

Sbattle2 — Mon, 10 Dec 2012 17:31:06 GMT

Sbattle2: /* Organization of this Document */

= Linked Data Platform Use Cases And Requirements =

This is a working document used to collect use cases and requirements for consideration by the WG.
The starting point comes from [http://www.w3.org/Submission/2012/SUBM-ldbpucr-20120326/ Linked Data Basic Profile Use Cases and Requirements].

== Status of this Document ==

This document is currently under review pending release as a First Public Working Draft. While the editors have made every effort to identify a set of use-cases that are both evidenced in user-stories and in-scope of the charter, the document may yet be missing some key unidentified use-cases, or indeed, may include use-cases that ought to be removed. Furthermore, the coarse grouping of use-cases to avoid CRUDdy operations may not be to people's taste and is open to challenge.

===Timetable===
* <strike>Nov 26? WG to confirm User Story content: add, remove, refine (see process below). Note: this is ONLY User Stories (not Use Cases, Use Case Scenarios or Requirements)</strike>
** <strike>Issues before Nov 26th? will be included into FPWD</strike>
* Editors to:
** <strike>Dec 3 refine User Stories based on feedback</strike>
** <strike>Dec 5 elaborate on Use Cases in support of User Stories</strike>
* Dec 10 - WG to review prior to FPWD
** Review period ends Dec 15th
** insert open issues into draft for FPWD
* Dec 17 - Publish FPWD
** convert wiki page to ReSpec for FPWD
* Dec ?? Deadline for publications by year end 2012

===To Be Done===
* <strike>Move [[#LDP_and_Authentication.2FAuthorization| LDP and Authentication]] to [http://www.w3.org/2012/ldp/wiki/AccessControl AccessControl]</strike>
* <strike>Complete [[#Alternative_scenario:_moving_contained_resources| moving contained resources]] scenario with content from ericP on issue-30.</strike>
* <strike>Augment [[#Cloud_Infrastructure_Management| Cloud Infrastructure Management]] scenario with content from Roger Menday.</strike>
* <strike>Ensure issue-40/41 are fully covered in [[#UC8:_Managing_non-RDF_Resources| UC8: Managing non-RDF Resources]]. 2 scenarios (single v multiple attachments) ?</strike>
* <strike>Contact owner of [[#Data_Sharing| Data Sharing]] user-story to determine if we keep or not.</strike>
* <strike>Review [[#Requirements| Requirements]] section for functional/non-functional requirements arising in UCs.</strike>
* <strike>Propose resolutions to open issues against UC&R where possible.</strike>
* <strike>Identify and acknowledge user-story contributors.</strike>
* <strike>Check hyperlinks</strike>
* Convert to ReSpec
* Annotate document with open issues against UC&R
** <strike>[http://www.w3.org/2012/ldp/track/issues/30 ISSUE-30] (OPEN)</strike>
** [http://www.w3.org/2012/ldp/track/issues/40 ISSUE-40] (PENDING REVIEW)
** [http://www.w3.org/2012/ldp/track/issues/41 ISSUE-41] (PENDING REVIEW)

=== Process to introduce new User Stories & Use Cases ===

Open an Issue in the tracker against the UC&R product. The WG will review these and decide whether they are valid.

== Scope and Motivation ==

Linked Data was defined by Tim Berners-Lee with the following guidelines [http://www.w3.org/DesignIssues/LinkedData.html]:

# Use URIs as names for things
# Use HTTP URIs so that people can look up those names
# When someone looks up a URI, provide useful information, using the standards (RDF*, SPARQL)
# Include links to other URIs. so that they can discover more things

These four rules have proven very effective in guiding and inspiring people to publish Linked Data on the web. The amount of data, especially public data, available on the web has grown rapidly, and an impressive number of extremely creative and useful “mashups” have been created using this data as result.

There has been much less focus on the potential of Linked Data as a model for managing data on the web - the majority of the Application Programming Interfaces (APIs) available on the Internet for creating and updating data follow a Remote Procedure Call (RPC) model rather than a Linked Data model.

If Linked Data were just another model for doing something that RPC models can already do, it would be of only marginal interest. Interest in Linked Data arises from the fact that applications with an interface defined using Linked Data can be much more easily and seamlessly integrated with each other than applications that offer an RPC interface. In many problem domains, the most important problems and the greatest value are found not in the implementation of new applications, but in the successful integration of multiple applications into larger systems.

Some of the features that make Linked Data exceptionally well suited for integration include:

* A single interface – defined by a common set of HTTP methods – that is universally understood and is constant across all applications. This is in contrast with the RPC architecture where each application has a unique interface that has to be learned and coded to.
* A universal addressing scheme – provided by HTTP URLs – for both identifying and accessing all “entities”. This is in contrast with the RPC architecture where there is no uniform way to either identify or access data.
* A simple yet extensible data model – provided by RDF – for describing data about a resource in a way which doesn’t require prior knowledge of vocabulary being used.

Experience implementing applications and integrating them using Linked Data has shown very promising results, but has also demonstrated that the original four rules defined by Tim Berners-Lee for Linked Data are not sufficient to guide and constrain a writable Linked Data API. As was the case with the original four rules, the need generally is not for the invention of fundamental new technologies, but rather for a series of additional rules and patterns that guide and constrain the use of existing technologies in the construction of a Basic Profile for Linked Data to achieve interoperability.

The following list illustrates a few of the issues that require additional rules and patterns:
* What URLs do I post to in order to create new resources?
* How do I get lists of existing resources, and how do I get basic information about them without having to access each one?
* How should I detect and deal with race conditions on write?
* What media-types/representations should I use?
* What standard vocabularies should I use?
* What primitive data types should I use?

A good goal for the Basic Profile for Linked Data would be to define a specification required to allow the definition of a writable Linked Data API equivalent to the simple application APIs that are often written on the web today using the Atom Publishing Protocol (APP). APP shares some characteristics with Linked Data, such as the use of HTTP and URLs. One difference is that Linked Data relies on a flexible data model with RDF, which allows for multiple representations.

== Organization of this Document ==

This document is organized as follows:

* '''[[#User Stories| User Stories]]''' capture statements about system requirements written from a user or application perspective. They are typically lightweight and informal and can run from one line to a paragraph or two (sometimes described as an 'epic') [http://www.agilemodeling.com/artifacts/userStory.htm]. Analysis of each user story will reveal a number of (functional) use-cases and other non-functional requirements. See [http://www.w3.org/TR/dap-policy-reqs/| Device API Access Control Use Cases and Requirements] for a good example of user stories and their analysis.

* '''[[#Use Cases| Use Cases]]''' are used to capture and model functional requirements. Use cases describe the system’s behavior under various conditions [http://alistair.cockburn.us/get/2465], cataloguing who does what with the system, for what purpose, but without concern for system design or implementation [http://www.bredemeyer.com/pdf_files/functreq.pdf]. Each use case is identified by a reference number to aid cross-reference from other documentation; use-case indexing in this document is based on [http://www.w3.org/TR/rdb2rdf-ucr/ rdb2rdf use-cases]. A variety of styles may be used to capture use-cases, from a simple narrative to a structured description with actors, pre/post conditions, and step-by-step behaviours as in [http://www.w3.org/TR/powder-use-cases/ POWDER: Use Cases and Requirements], and non-functional requirements raised by the use-case. Use cases act like the hub of a wheel, with spokes supporting requirements analysis, scenario-based evaluation, testing, and integration with non-functional, or quality requirements.

* '''Scenarios''' are more focused still, representing a single instance of a use case in action. Scenarios may range from lightweight narratives as seen in [http://www.w3.org/TR/media-frags-reqs/ Use cases and requirements for Media Fragments], to being formally modeled as interaction diagrams. Each use-case should include at least a primary scenario, and possibly other alternative scenarios.

* '''[[#Requirements| Requirements]]''' lists non-functional or quality requirements, and the use cases they may be derived from. This approach is exemplified in the [http://dvcs.w3.org/hg/gld/raw-file/default/dcat-ucr/index.html Use Cases and Requirements for the Data Catalog Vocabulary]. It also lists functional requirements that stem from use-cases. It is also possible at this stage to explicitly identify some use-cases as non-requirements.

== User Stories ==

=== Maintaining Social Contact Information ===

Many of us have multiple email accounts that include information about the people and organizations we interact with – names, email addresses, telephone numbers, instant messenger identities and so on. When someone’s email address or telephone number changes (or they acquire a new one), our lives would be much simpler if we could update that information in one spot and all copies of it would automatically be updated. In other words, those copies would all be linked to some definition of “the contact.” There might also be good reasons (like off-line email addressing) to maintain a local copy of the contact, but ideally any copies would still be linked to some central “master.”

Agreeing on a format for “the contact” is not enough, however. Even if all our email providers agreed on the format of a contact, we would still need to use each provider’s custom interface to update or replace the provider’s copy, or we would have to agree on a way for each email provider to link to the “master”. If we look outside our own personal interests, it would be even more useful if the person or organization exposed their own contact information so we could link to it.

What would work in either case is a common understanding of the resource, a few formats needed, and access guidance for these resources. This would support how to acquire a link to a contact, and how to use those links to interact with a contact (including [[#UC3: Retrieve resource description|reading]], [[#UC4: Update existing resource|updating]], and [[#Alternative scenario: delete resource|deleting]] it), as well as how to easily [[#Primary scenario: create resource|create a new contact]] and add it to my contacts and when deleting a contact, how it would be removed from my list of contacts. It would also be good to be able to add some application-specific data about my contacts that the original design didn’t consider. Ideally we’d like to eliminate multiple copies of contacts, there would be additional valuable information about my contacts that may be stored on separate servers and need a simple way to link this information back to the contacts. Regardless of whether a contact collection is my own, shared by an organization, or all contacts known to an email provider (or to a single email account at an email provider), it would be nice if they all worked pretty much the same way.

=== Keeping Track of Personal and Business Relationships ===

In our daily lives, we deal with many different organizations in many different relationships, and they each have data about us. However, it is unlikely that any one organization has all the information about us. Each of them typically gives us access to the information (at least some of it), many through websites where we are uniquely identified by some string – an account number, user ID, and so on. We have to use their applications to interact with the data about us, however, and we have to use their identifier(s) for us. If we want to build any semblance of a holistic picture of ourselves (more accurately, collect all the data about us that they externalize), we as humans must use their custom applications to find the data, copy it, and organize it to suit our needs.

Would it not be simpler if at least the Web-addressable portion of that data could be linked to consistently, so that instead of maintaining various identifiers in different formats and instead of having to manually supply those identifiers to each one’s corresponding custom application, we could essentially build a set of bookmarks to it all? When we want to [[#UC3: Retrieve resource description|examine]] or [[#UC4: Update existing resource|change]] their contents, would it not be simpler if there were a single consistent application interface that they all supported? Of course it would.

Our set of links would probably be a [[#UC6: Aggregate resources|simple collection]]. The information held by any single organization might be a mix of simple data and [[#UC6: Aggregate resources|collections of other data]], for example, a bank account balance and a collection of historical transactions. Our bank might easily have [[#Alternative scenario: create a nested container|a collection of accounts for each of its collection of customers]].

=== System and Software Development Tool Integration ===

System and software development tools typically come from a diverse set of vendors and are built on various architectures and technologies. These tools are purpose built to meet the needs for a specific domain scenario (modeling, design, requirements and so on.) Often tool vendors view integrations with other tools as a necessary evil rather than providing additional value to their end-users. Even more of an afterthought is how these tools’ data -- such as people, projects, customer-reported problems and needs -- integrate and relate to corporate and external applications that manage data such as customers, business priorities and market trends. The problem can be isolated by standardizing on a small set of tools or a set of tools from a single vendor, but this rarely occurs and if does it usually does so only within small organizations. As these organizations grow both in size and complexity, they have needs to work with outsourced development and diverse internal other organizations with their own set of tools and processes. There is a need for better support of more complete business processes (system and software development processes) that span the roles, tasks, and data addressed by multiple tools. This demand has existed for many years, and the tools vendor industry has tried several different architectural approaches to address the problem. Here are a few:

* Implement an API for each application, and then, in each application, implement “glue code” that exploits the APIs of other applications to link them together.
* Design a single database to store the data of multiple applications, and implement each of the applications against this database. In the software development tools business, these databases are often called “repositories.”
* Implement a central “hub” or “bus” that orchestrates the broader business process by exploiting the APIs described previously.

It is fair to say that although each of those approaches has its adherents and can point to some successes, none of them is wholly satisfactory. The use of Linked Data as an application integration technology has a strong appeal. [http://open-services.net/ OSLC]

=== Library Linked Data ===

The W3C Library Linked Data working group has a number of use cases cited in their Use Case Report. [http://www.w3.org/2005/Incubator/lld/wiki/UseCaseReport LLD-UC] These referenced use cases focus on the need to extract and correlate library data from disparate sources. Variants of these use cases that can provide consistent formats, as well as ways to improve or update the data, would enable simplified methods for both efficiently sharing this data as well as producing incremental updates without the need for repeated full extractions and import of data.

The 'Digital Objects Cluster' contains a number of relevant use-cases:

* Grouping: This should "Allow the end-users to define [[#UC6: Aggregate resources|groups of resources]] on the web that for some reason belong together. The relationship that exists between the resources is often left unspecified. Some of the resources in a group may not be under control of the institution that defines the groups."

* Enrichment: "Enable end-users to [[#UC4: Update existing resource|link resources together]]."

* Browsing: "[[#UC7: Filter resource description|Support end-user browsing through groups]] and resources that belong to the groups."

* Re-use: "Users should have the capability to re-use all or parts of a collection, with all or part of its metadata, elsewhere on the linked Web."

The 'Collections' cluster also contains a number of relevant use-cases:

* Collection-level description: "Provide [[#UC7: Filter resource description|metadata pertaining to a collection as a whole]], in contrast to item-level description."

* Collections discovery: "Enable innovative collection discovery such as identification of nearest location of a physical collection where a specific information resource is found or mobile device applications ... based on collection-level descriptions."

* Community information services: Identify and classify collections of special interest to the community.

=== Municipality Operational Monitoring ===

Across various cities, towns, counties, and various municipalities there is a growing number of services managed and run by municipalities that produce and consume a vast amount of information. This information is used to help monitor services, predict problems, and handle logistics. In order to effectively and efficiently collect, produce, and analyze all this data, a fundamental set of loosely coupled standard data sources are needed. A simple, low-cost way to [[#UC3: Retrieve resource description|expose data]] from the diverse set of monitored services is needed, one that can easily integrate into the municipalities of other systems that inspect and analyze the data. All these services have links and dependencies on other data and services, so having a simple and scalable linking model is key.

=== Healthcare ===

For physicians to analyze, diagnose, and propose treatment for patients requires a vast amount of complex, changing and growing knowledge. This knowledge needs to come from a number of sources, including physicians’ own subject knowledge, consultation with their network of other healthcare professionals, public health sources, food and drug regulators, and other repositories of medical research and recommendations.

To diagnose a patient’s condition requires current data on the patient’s medications and medical history. In addition, recent pharmaceutical advisories about these medications are linked into the patient’s data. If the patient experiences adverse affects from medications, these physicians need to publish information about this to an appropriate regulatory source. Other medical professionals require access to both validated and emerging effects of the medication. Similarly, if there are geographical patterns around outbreaks that allow both the awareness of new symptoms and treatments, this information needs to quickly reach a very distributed and diverse set of medical information systems. Also, reporting back to these regulatory agencies regarding new occurrences of an outbreak, including additional details of symptoms and causes, is critical in producing the most effective treatment for future incidents.

=== Metadata Enrichment in Broadcasting ===

There are many different use cases when broadcasters show interest in metadata [[#UC4: Update existing resource| enrichment]]:

* enrich archive or news metadata by linking facts, events, locations and personalities
* enrich metadata generated by automatic extraction tools such as person identification, etc.
* enrich definitions of terms in classification schemes or enumeration lists

This comes in support of more effective information management and data/content mining (if you can't find your content, it' like if you don't have and must either recreate or acquire it again, which is not financially effective).

However, there is a need for solutions facilitating linkage to other data sources and taking care of the issues such as discovery, automation, disambiguation. Etc. Other important issues that broadcasters would face are the editorial quality of the linked data, its persistence, and usage rights.

=== Aggregation and Mashups of Infrastructure Data ===

For infrastructure management (such as storage systems, virtual machine environments, and similar IaaS and PaaS concepts), it is important to provide an environment in which information from different sources can be [[#UC6: Aggregate resources|aggregated]], [[#UC7: Filter resource description|filtered]], and visualized effectively. Specifically, the following use cases need to be taken into account:

* While some data sources are based on Linked Data, others are not, and aggregation and mashups must work across these different sources.
* Consumers of the data sources and aggregated/filtered data streams are not necessarily implementing Linked Data themselves, they may be off-the-shelf components such as dashboard frameworks for composing visualizations.
* Simple versions of this scenario are pull-based, where the data is requested from data sources. In more advanced settings, without a major change in architecture it should be possible to move to a push-based interaction model, where data sources push notifications to subscribers, and data sources provide different services that consumers can subscribe to (such as "informational messages" or "critical alerts only").

In this scenario, the important factors are to have abstractions that allow easy aggregation and filtering, are independent from the internal data model of the sources that are being combined, and can be used for pull-based interactions as well as for push-based interactions.

=== Sharing payload of RDF data among low-end devices ===

Several projects around the idea of [http://worldwidesemanticweb.wordpress.com/ downscaling the Semantic Web] need to be able to ship payloads of RDF across the nodes member of a given network. The transfers are done in a constrained context in terms of bandwidth, scope of the local semantics employed by the nodes and computing capabilities of the nodes. In a P2P style, every node has the capability to act either as a data consumer or a data provider, serving its own data or acting as a relay to pass other's data along (typically in mesh networks).

The transfer of an arbitrary payload of RDF data could be implemented through the container mechanism, adding and removing sets of RDF triples to it. Currently, one of the project "SemanticXO" uses named graphs and the graph protocol to create/delete/copy graphs across the nodes but this (almost) imposes the usage of a triple store. Unfortunately, triple store are rather demanding piece of software that are not always usable on limited hardware. Some generic ReST like interaction backed up with a lightweight column store would be better approach.

=== Sharing Binary Resources and Metadata ===

When publishing datasets about stars one may want to publish links to the pictures in which those stars appear, and this may well require publishing the pictures themselves. Vice versa: when publishing a picture of space we need to know which telescope took the picture, which part of the sky it was pointing at, what filters were used, which identified stars are visible, who can read it, who can write to it, ...

If LinkedData contains information about resources that are most naturally expressed in non-rdf formats (be they binary such as pictures or videos, or human readable documents in XML formats), those non RDF formats should be just as easy to publish to the LinkedData server as the RDF relations that link those resources up. A LinkedData server should therefore allow publishing of non linked data resources too, and make it easy to publish and edit metadata about those resources.

The resource comes in two parts - the image and information about the image (which may in the image file but better external to it as it's more general). The information about the image is vital. It's a compound item of image data and other data (being application metadata about the image does not distinguish from the platform's point-of-view.

=== Data Catalogs ===

The Asset Description Metadata Schema ([http://joinup.ec.europa.eu/asset/adms/home ADMS]) provides the data model to describe semantic assets repositories contents, but this leaves many open challenges when building a federation of these repositories to serve the need of assets reuse. These include accessing and querying individual repositories and efficiently retrieving [[#UC5: Determine if a resource has changed| updated content]] without having to retrieve the whole content. Hence, we chose to build the integration solution capitalizing on the Data Warehousing integration approach. This allows us to cope with heterogeneity of sources technologies and to benefit from the optimized performance it offers, given that individual repositories do not usually change frequently. With Data Warehousing, the federation requires to:

* understand the data, i.e. understand their semantic descriptions, and other systems.
* seamlessly exchange the semantic assets metadata from different repositories
* keep itself up-to-date.

Repositories owners can maintain de-referenceable URIs for their repository description and contained assets in a Linked Data compatible manner. ADMS provides the necessary data model to enable meaningful exchange of data. However, This leaves the challenge of efficient access to the data not fully addressed.

Related: [http://spec.datacatalogs.org/ Data Catalog Schema and Protocol]

=== Constrained Devices and Networks ===

Information coming from resource constrained devices in the Web of Things ([http://en.wikipedia.org/wiki/Web_of_Things WoT]) has been identified as a major driver in many domains, from smart cities to environmental monitoring to real-time tracking. The amount of information produced by these devices is growing exponentially and needs to be accessed and integrated in a systematic, standardized and cost efficient way. By using the same standards as on the Web, integration with applications will be simplified and higher-level interactions among resource constrained devices, abstracting away heterogeneities, will become possible. Up-coming IoT/WoT standards such as [http://datatracker.ietf.org/wg/6lowpan/ 6LowPAN] - IPv6 for resource constrained devices - and the Constrained Application Protocol ([http://tools.ietf.org/html/draft-ietf-core-coap CoAP]), which provides a downscaled version of HTTP on top of UDP for the use on constrained devices, are already at a mature stage. The next step now is to support RESTful interfaces also on resource constrained devices, adhering to the Linked Data principles. Due to the limited resources available, both on the device and in the network (such as bandwidth, energy, memory) a solution based on SPARQL Update is at the current point in time considered not to be useful and/or feasible. An approach based on the [http://tools.ietf.org/html/draft-castellani-core-http-mapping HTTP-CoAP Mapping] would enable constrained devices to directly participate in a Linked Data-based environment.

=== Services Supporting the Process of Science ===
Many fields of science now include branches with in silico data-intensive methods, e.g. bioinformatics, astronomy. To support these new methods we look to move beyond the established platforms provided by scientific workflow systems to capture, assist, and preserve the complete lifecycle from record of the experiment, through local trusted sharing, analysis, dissemination (including publishing of experimental data "beyond the PDF"), and re-use.

* [[#UC6: Aggregate resources|Aggregations]], specifically ''Research Objects (ROs)'' that are exchanged between services and clients bringing together workflows, data sets, annotations, and provenance. We use an RDF model for this. While some aggregated contents are encoded using RDF and in increasing number are linked data sources, others are not; while some are stored locally "within" the RO, others are remote (in both cases this is often due to size of the resources or access policies).
* Services that are distributed and linked. Some may be centralising for e.g. publication, others may be local, e.g. per lab. We need lightweight services that can be simply and easily integrated into and scale across the wide variety of softwares and data used in science: we have adopted a RESTful approach where possible.
** Foundation services that collect and expose ROs for storage, modification, exploration, and reuse.
** Services that provide added-value to ROs such as seamless import/export from scientific workflow systems, automated stability evaluation, or recommendation (and therefore interact with the foundation services to retrieve/store/modify/ROs).

seeAlso: [http://www.wf4ever-project.org/ Wf4Ever]

=== Project Membership Information : Information Evolution ===

Information about people and projects changes as roles change, as organisations change
and as contact details change. Finding the current state of a project is important
in enabling people to contact the right person in the right role. It can also be
useful to look back and see who was performing what role in the past.

A use of a Linked Data Platform could be to give responsibility for managing
such information with the project team itself, not requiring updates to be
requested of a centralised website administrator.

This could be achieved with:

* Resource descriptions for each person and project
* A container resource to describe roles/membership in the project.

To retain the history of the project, the old version of a resources,
including container resources, should be retained so there is a need to address both specific items
and also have a notion of "current".

Access to information has two aspects:
* Access to the "current" state, regardless of the version of the resource description
* Access to historical state, via access to a specific version of the resource description

=== Cloud Infrastructure Management===

Cloud operators offer API support to provide customers with remote access for the management of Cloud infrastructure (IaaS). Infrastructure consists of Systems, Computers, Networks, Discs, etc. The overall structure can be seen as mostly hierarchical, (Cloud contains Systems, Systems contain Machines, etc), complemented with crossing links (e.g. multiple Machines connected to a Network).

The IaaS scenario makes specific requirements on lifecycle management and discovery, handling non-instant changes, history capture and query:

* Many aspects of Cloud infrastructure have associated lifecycle, e.g. a Computer can be transitioned between Running and Shutdown. This should be manageable through the API, which should include how a client discovers dynamic lifecycle options and thus help steering through an application.
* It is often the case that attaining a new lifecycle state is not instantaneous. Clients require a universal mechanism for monitoring such changes.
* A facility to retrieve all events in the lifecycle of a resource can be useful.
* Query provides the means to interrogate the resources behind the API, as well as finding new entry points into the application.

Infrastructure management may be viewed as the manipulation of the underlying graph of resources.

== Use Cases ==
The following use-cases are each derived from one or more of the user-stories above. These use-cases are explored in detail through the development of scenarios, each motivated by some key aspect exemplified by a single user-story. The examples they contain are included purely for illustrative purposes, and should not be interpreted normatively.

===UC1: Manage containers===
A number of user-stories introduce the idea of a ''container'' as a mechanism for creating and managing resources within the context of an application. Resources grouped together within the same container would typically belong to the same application. A container is identified by a URI so is a resource in its own right.
The properties of a container may also represent the ''affordances'' of that container, enabling clients to determine what other operations they can do on that container. These operations may include descriptions of application specific services that can be invoked by exchanging RDF documents.

* Provide "access guidance for ... resources" (affordances) (from user-story, [[#Maintaining Social Contact Information|Maintaining Social Contact Information]]).

====Primary scenario: create container====
Create a new container resource within the LDP server.
In [[#Services Supporting the Process of Science|Services supporting the process of science]], [http://wf4ever.github.com/ro-primer/ Research Objects] are semantically rich aggregations of resources that bring together data, methods and people in scientific investigations. A basic workflow research object will be created to aggegate [http://ceur-ws.org/Vol-903/paper-01.pdf scientific workflows] and the artefacts that result from this workflow. The research object begins life as an empty container into which workflows, datasets, results and other data will be added throughout the lifecycle of the project.

<nowiki>
@prefix ro: http://purl.org/wf4ever/ro#
@prefix dct: http://purl.org/dc/terms/
@prefix ore: http://www.openarchives.org/ore/

<> a ro:ResearchObject, ore:Aggregation ;
dct:created "2012-12-01"^^xsd:dateTime .
</nowiki>

====Alternative scenario: create a nested container====
The motivation for nested containers comes from the [[#System and Software Development Tool Integration| System and Software Development Tool Integration]] user-story. The OSLC Change Management vocabulary allows bug reports to have attachments referenced by the membership predicate <nowiki>oslc_cm:attachment</nowiki>. The 'top-level-container' contains issues, and each issue resource has its own container of attachment resources.

<nowiki>
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix oslc_cm: <http://open-services.net/ns/cm#>.
@prefix : <http://example.org/>.

:top-level-container rdfs:member :issue1234 .

:issue1234 a oslc_cm:ChangeRequest;
dcterms:identifier "1234";
dcterms:type "a bug";
dcterms:related :issue1235 ;
oslc_cm:attachments :attachments123.

:issue1235 a oslc_cm:ChangeRequest;
dcterms:title "a related bug".

:attachments a oslc_cm:AttachmentList;
oslc_cm:attachment :attachment324, :attachment251.
</nowiki>

===UC2: Manage resources===
This use-case addresses the managed lifecycle of a resource and is concerned with resource ''ownership''. The responsibility for managing resources belongs with their container.
For example, a container may accept a request from a client to make a new resource.
This use-case focuses on creation and deletion of resources in the context of a container, and the potential for transfer of ownership by moving resources between containers.
The ownership of a resource should always be clear; no resource managed in this way should ever be owned by more than one container.

Once a new resource has been created it should be identified by a URI. Clients may defer responsibility for establishing dereferenceable URIs to the container of their data.
The container is a natural choice for the endpoint for this interface as it will already have some application-specific knowledge about the contained resources.
While the LDP has ultimate control over resource naming, some applications may require more control over naming, perhaps to provide a more human-readable URI. An LDP server could support something like the [http://tools.ietf.org/html/rfc5023 Atom Publishing Protocol] slug header to convey a user defined naming 'hint'.

* Non-duplication of resources: "Eliminate multiple copies", representing resources in a single place (from [[#Maintaining Social Contact Information]]).
* Distribution of resources: Linked aata "may be stored on separate servers" (from [[#Maintaining Social Contact Information]]).
* Consistent, global naming: Resources should be "linked to consistently, ... instead of maintaining various identifiers in different formats" (from [[#Keeping Track of Personal and Business Relationships]]).

====Primary scenario: create resource====
Resources begin life by being created within a container. From user-story, [[#Maintaining Social Contact Information|Maintaining Social Contact Information]], It should be possible to "easily create a new contact and add it to my contacts." This suggests that resource creation is closely linked to the application context. The new resource is created in a container representing "my contacts." The lifecycle of the resource is linked to the lifecycle of it's container. So, for example, if "my contacts" is deleted then a user would also reasonably expect that all contacts within it would also be deleted.

Contact details are captured as an RDF description and it's properties, including "names, email addresses, telephone numbers, instant messenger identities and so on." The description may include non-standard RDF; "data about my contacts that the original design didn’t consider."
The following RDF could be used to describe contact information using the [http://www.foaf-project.org FOAF] vocabulary. A contact is represented here by a <nowiki>foaf:PersonalProfileDocument</nowiki> defining a resource that can be created and updated as a single-unit, even though it may describe ancillary resources, such as a <nowiki>foaf:Person</nowiki>, below.

<nowiki>
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

<> a foaf:PersonalProfileDocument;
foaf:PrimaryTopic [
a foaf:Person;
foaf:name "Timothy Berners-Lee";
foaf:title "Sir";
foaf:firstName "Timothy";
foaf:surname "Berners-Lee";
foaf:nick "TimBL", "timbl";
foaf:homepage <http://www.w3.org/People/Berners-Lee/>;
foaf:weblog <http://dig.csail.mit.edu/breadcrumbs/blog/4>;
foaf:mbox <mailto:timbl@w3.org>;
foaf:workplaceHomepage <http://www.w3.org/>.
]
</nowiki>

====Alternative scenario: delete resource====
Delete a resource and all it's properties. If the resource resides within a container it will be removed from that container, however other links to the deleted resource may be left as dangling references.
In the case where the resource is a container, the server may also delete any or all contained resources.
In normal practice, a deleted resource cannot be reinstated. There are however, edge-cases where limited undelete may be desirable.
Best practice states that "[http://www.w3.org/TR/cooluris/| Cool URIs don't change]", which implies that deleted URIs shouldn't be recycled.

====Alternative scenario: moving contained resources====
Many resources may have value beyond the life of their membership in a container. This implies methods to add references to revise container membership.
Cloning container members for use in other containers results in duplication of information and maintenance problems; web practice is to encourage the creation of one resource, which may be referenced as many places as necessary. A change of ownership may - or may not - imply a change of URI, depending upon the specific LDP naming policy. While assigning a new URI to a resource is discouraged [http://www.w3.org/DesignIssues/Architecture.html#HTTP], it is possible to indicate that a resource has moved with an appropriate HTTP response.

===UC3: Retrieve resource description===
Access the current description of a resource, containing properties of that resource and links to related resources. The representation may include descriptions of related resources that cannot be accessed directly.
Depending upon the application, an LDP may enrich the retrieved RDF with additional triples. Examples include adding incoming links, sameAs closure and type closure.
The HTTP response should also include versioning information (i.e. last update or entity tag) so that subsequent updates can ensure they are being applied to the correct version.

* Use standard vocabularies as appropriate to enable a "common understanding of the resource" (from [[#Maintaining Social Contact Information|Maintaining Social Contact Information]]).
* A "scalable linking model is key" (from [[#Municipality Operational Monitoring]]).

====Primary scenario====
The user-story [[#Project Membership Information : Information Evolution| Project Membership Information]] discusses the representation of information about people and projects. It calls for "Resource descriptions for each person and project" allowing project teams to review information held about these resources. The example below illustrates the kinds of information that might be held about organizational structures based on the [http://www.epimorphics.com Epimorphics] [http://www.epimorphics.com/public/vocabulary/org.html organizational ontology].

Note that the example below defines two resources (shown as separate sections below) that will be hosted on an LDP based at <nowiki>http://example.com/</nowiki>. The representations of these resources may include descriptions of related resources, such as <nowiki>http://www.w3.org/</nowiki>, that that fall under a different authority and therefore can't be served from the LDP at this location.

<nowiki>
@prefix org: <http://www.w3.org/ns/org#> .
@prefix owltime: <http://www.w3.org/2006/time> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@base <http://example.com/> .

<member1> a org:Membership ;
org:member <http://www.w3.org/People/Berners-Lee/card#i> ;
org:organization http://www.w3.org/> ;
org:role <director> ;
org:memberDuring [a owltime:Interval; owltime:hasBeginning [
owltime:inXSDDateTime "1994-10-01T00:00:00Z"^^xsd:dateTime]] .

<http://www.w3.org/> a org:FormalOrganization ;
skos:prefLabel "The World Wide Web Consortium"@en ;
skos:altLabel "W3C" .
</nowiki>

<nowiki>
@prefix org: <http://www.w3.org/ns/org#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@base <http://example.com/> .

<director> a org:Role ;
rdfs:label "Director" .
</nowiki>

====Alternative scenario: retrieve description of a non-document resource====
In many cases, the things that are of interest are not always the things that are resolvable. The example below demonstrates how a foaf profile may be used to distinguish between the person and the profile; the former being the topic of the latter. This begs the question as to what a client should do with such non-document resources. In this case the HTTP protocol requires that the fragment part be stripped off before requesting the URI from the server. The result is a resolvable URI for the profile.

<nowiki>
@base <http://www.w3.org/People/Berners-Lee/card>
@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@prefix dc: <http://purl.org/dc/elements/1.1/>.

<> a foaf:PersonalProfileDocument ;
dc:title "Tim Berners-Lee's FOAF file" ;
foaf:homepage <http://www.w3.org/People/Berners-Lee/> ;
foaf:primaryTopic <#i> .
</nowiki>

===UC4: Update existing resource===
Change the RDF description of a LDP resource, potentially removing or overwriting existing data. This allows applications to ''enrich'' the representation of a resource by addling additional links to other resources.

* Unrestricted vocabulary: It should be possible be "able to add ... application-specific data" to resources (from [[#Maintaining Social Contact Information]]).

====Primary scenario: enrichment====
This relates to user-story [[#Metadata Enrichment in Broadcasting| Metadata Enrichment in Broadcasting]] and is based on the [http://www.bbc.co.uk/ontologies/sport/ BBC Sports Ontology]. The ''resource-centric'' view of linked-data provides a natural granularity for substituting, or overwriting a resource and its data. The simplest kind of update would simply replace what is currently known about a resource with a new representation. There are two distinct resources in the example below; a sporting event and an associated award. The granularity of the LDP would allow a user to replace the information about the award without disturbing the information about the event.

<nowiki>
@prefix sport: <http://www.bbc.co.uk/ontologies/sport/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

:mens_sprint a sport:MultiStageCompetition;
rdfs:label "Men's Sprint";
sport:award <#gold_medal> .

<#gold_medal> a sport:Award .
</nowiki>

We can enrich the description as events unfold, linking to the winner of the gold medal by substituting the above description with the following.

<nowiki>
@prefix sport: <http://www.bbc.co.uk/ontologies/sport/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

:mens_sprint a sport:MultiStageCompetition;
rdfs:label "Men's Sprint";
sport:award <#gold_medal> .
<#gold_medal> a sport:Award;
sport:awarded_to [
a foaf:Agent ;
foaf:name "Chris Hoy" .
] .
</nowiki>

====Alternative scenario: selective update of a resource====
This relates to user-story [[#Data Catalogs|Data Catalogs]], based on the [http://vocab.deri.ie/dcat Data Catalog Vocabulary].
A catalogue is described by the following RDF model.

<nowiki>
@prefix dcat: <http://www.w3.org/ns/dcat#> .
@prefix dcterms: <http://purl.org/dc/terms/> .

:catalog a dcat:Catalog ;
dcat:dataset :dataset/001;
dcterms:issued "2012-12-11"^^xsd:date.
</nowiki>

A catalog may contain multiple datasets, so when linking to new datasets it would be simpler and preferable to selectively add just the new dataset links.
A Talis ''changeset'' [http://docs.api.talis.com/getting-started/changesets][http://www.w3.org/2009/12/rdf-ws/papers/ws07] could be used to add a new <nowiki>dc:title</nowiki> to the dataset. The following update would be directed to the catalogue to add an additional dataset.

<nowiki>
@prefix : <http://example.com/>.
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix cs: <http://purl.org/vocab/changeset/schema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.

<change1>
a cs:ChangeSet ;
cs:subjectOfChange :catalog ;
cs:createdDate "2012-01-01T00:00:00Z" ;
cs:changeReason "Update catalog datasets" ;
cs:addition [
a rdf:Statement ;
rdf:subject :catalog ;
rdf:predicate dcat:dataset ;
rdf:object :dataset/002 .
] .
</nowiki>

===UC5: Determine if a resource has changed===
It should be possible to retrieve versioning information about a resource (e.g. last modified or entity tag) without having to download a representation of the resource.
This information can then be compared with previous information held about that resource to determine if it has changed.
This versioning information can also be used in subsequent ''conditional'' requests to ensure they are only applied if the version is unchanged.

====Primary scenario====
Based on the user-story, [[#Constrained Devices and Networks| Constrained Devices and Networks]], an LDP could be configured to act as a proxy for a [http://tools.ietf.org/html/draft-ietf-core-coap CoAP] based [http://en.wikipedia.org/wiki/Web_of_Things Web of Things]. As an observer of CoAP resources, the LDP registers its interest so that it will be notified whenever the sensor reading changes. Clients of the LDP can interrogate the LDP to determine if the state has changed.

In this example, the information about a sensor and corresponding sensor readings can be represented as RDF resources. The first resource below, represents a sensor described using the [http://www.w3.org/2005/Incubator/ssn/ Semantic Sensor Network] ontology.
<nowiki>
@prefix : <http://example.com/energy-management/>.

<> a :MainsFrequencySensor;
rdfs:comment "Sense grid load based on mains frequency";
ssn:hasMeasurementCapability [
a :FrequencyMeasurementCapability;
ssn:hasMeasurementProperty <#property_1> .
] .
</nowiki>

The value of the sensor changes in real-time as measurements are taken. The LDP client can interrogate the resource below to determine if it has changed, ''without'' necessarily having to download the RDF representation. As different sensor properties are represented disjointly (separate RDF representations) they may change independently.

<nowiki>
@prefix : <http://example.com/energy-management/>.

<http://example.com/energy-management#property_1> :hasMeasurementPropertyValue <> .
<> a :FrequencyValue;
:hasQuantityValue "50"^^xsd:float.
</nowiki>

===UC6: Aggregate resources===
There is a requirement to be able to manage ''collections'' of resources. The concept of a collection overlaps with, but is distinct from that of a container. These collections are (weak) aggregations, unrelated to the lifecycle management of resources, and distinct from the ownership between a resource and its container. However, the composition of a container may be reflected as a collection to support navigation of the container and its contents. There is a need to be able to create collections by adding and deleting individual membership properties. Resources may belong to multiple collections, or to none.

* Resource descriptions are a "mix of simple data and collections" (from [[#Keeping Track of Personal and Business Relationships]]).
* Relative URIs: It should be possible to "ship payloads of RDF" for a collection as a whole without breaking internal links (from [[#Constrained Devices and Networks]]).

====Primary scenario: add a resource to a collection====
This example is from [[#Library Linked Data|Library Linked Data]] and [http://www.w3.org/2005/Incubator/lld/wiki/UseCaseReport LLD-UC], specifically [http://www.w3.org/2005/Incubator/lld/wiki/Use_Case_Subject_Search Subject Search].

There is an existing collection at <nowiki><http://example.com/concept-scheme/subject-heading></nowiki> that defines a collection of subject headings. This collection is defined as a skos:ConceptScheme and
the client wishes to insert a new concept into the scheme. which will be related to the collection via a <nowiki>skos:inScheme</nowiki> link. The new subject-heading, "outer space exploration", is not necessarily owned by a container. The following RDF would be added to the (item-level) description of the collection.

<nowiki>
@prefix scheme : <http://example.com/concept-scheme/>.
@prefix concept : <http://example.com/concept/>.

scheme:subject-heading a skos:ConceptScheme.

concept:Outer+space+Exploration skos:inScheme scheme:subject-heading.
</nowiki>

====Alternative scenario: add a resource to multiple collections====
Logically, a resource should not be owned by more than one container. however, it may be a member of multiple collections which define a weaker form of ''aggregation''. As this is simply a manipulation of the RDF description of a collection, it should be possible to add the same resource to multiple collections.

As a machine-readable collection of medical terms, the [http://www.ihtsdo.org| SNOMED] ontology is of key importance in [[#Healthcare | healthcare]]. SNOMED CT allows concepts with more than one parent that don't fall into a lattice.
In the example below, the same concept may fall under two different parent concepts.
The example uses skos:narrowerTransitive to elide intervening concepts.

<nowiki>
@prefix : <http://example.com/snomed/>.

:_119376003 a skos:Concept ;
skos:prefLabel "Tissue specimen"
skos:narrowerTransitive :TissueSpecimenFromHeart.

:_127462005 a skos:Concept ;
skos:prefLabel "Specimen from heart"
skos:narrowerTransitive :TissueSpecimenFromHeart.

:_128166000 a skos:Concept;
rdfs:label "Tissue specimen from heart".
</nowiki>

===UC7: Filter resource description===
This use-case extends the normal behaviour of retrieving an RDF description of a resource, by dynamically excluding specific (membership) properties.
For containers, it is often desirable to be able to read a collection, or item-level description that excludes the container membership.

====Primary scenario: retrieve collection-level description====
This scenario, based on [[#Library Linked Data| Library Linked Data]], uses the Dublin Core Metadata Initiative [http://dublincore.org/groups/collections/collection-application-profile/| Collection-Level] description.
A collection can refer to any aggregation of physical or digital items.
This scenario covers the case whereby a client can request a collection-level description as typified by the example below, without necessarily having to download a full listing of the items within the collection.

<nowiki>
@prefix rdf: <rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">.
@prefix dc: <http://purl.org/dc/elements/1.1/>.
@prefix : <http://example.org/bookshelf/>.
@prefix dcmitype: <http://purl.org/dc/dcmitype/>.
@prefix cld: <http://purl.org/cld/terms/>.
@prefix dcterms: <http://purl.org/dc/terms/>.

<> dc:type dcmitype:Collection ;
dc:title "Directory of organizations working with Linked Data" ;
dcterms:abstract "This is a directory of organisations specializing in Linked Data."
cld:isLocatedAt <http://dir.w3.org>
cld:isAccessedVia <http://dir.w3.org/rdf/2012/directory/directory-list.xhtml?construct>
</nowiki>

====Alternative scenario: retrieve item-level description of a collection====
This use-case scenario, also based on [[#Library Linked Data| Library Linked Data]], focuses on obtaining an item-level description of the resources aggregated by a collection.
The simplest scenario is where the members of a collection are returned within a single representation, so that a client can explore the data by following these links. Different applications may use different membership predicates to capture this aggregation. The example below uses <nowiki>rdfs:member</nowiki>, but many different membership predicates are in common use, including RDF Lists.
Item-level descriptions can be captured using the Functional Requirements for Bibliographic Records ([http://www.ifla.org/publications/functional-requirements-for-bibliographic-records FRBR]) [http://vocab.org/frbr/core.html ontology].

<nowiki>
@prefix frbr: <http://purl.org/vocab/frbr/core#>.

<> rdfs:member <#ebooks97>, <#ebooks21279>.

<#work97> a frbr:LiteraryWork;
dc:title "Flatland: a romance of many dimensions" ;
frbr:creator <#Abbott_Edwin>;
frbr:manifestation <ebook97>.

<#work21279> a frbr:LiteraryWork;
dc:title "2 B R 0 2 B" ;
frbr:creator <#Vonnegut_Kurt>;
frbr:manifestation <ebook21279>.
</nowiki>

Collections are potentially very large, so some means may be required to limit the size of RDF representation returned by the LDP (e.g. pagination).

===UC8: Manage media resources===
It should be possible to easily add non-RDF media resources to containers that accept them. Media resources may be updated and removed during the lifecycle of the container.

====Primary scenario: access media resources====
From the User Story [[#Sharing Binary Resources and Metadata| Sharing Binary Resources and Metadata]] it should be possible to easily add non RDF resources to a containers that accept them. Clients submit a non-RDF representation to a container in a media type accepted by that container. The container creates a URI to represent this media resource, and creates a link from the container to the new URI.The media resource may have an explicit representation of the media type. It should be possible to find the metadata about such a resource and to access and edit it in the usual ways.

This example uses the [http://www.w3.org/TR/mediaont-10/#ont-ttl Ontology for Media Resources] to describe a media resource added to a collection.
<nowiki>
@prefix ma: <http://www.w3.org/ns/ma-ont#> .

<dataset> a ma:Collection ;
:hasMember <dataset/image1.jpg>

<dataset/image1.jpg> a ma:MediaResource ;
ma:hasFormat "image/jpeg" .
</nowiki>

====Alternative scenario: media-resource attachments====
A resource may have multiple ''renditions''; the idea that you can have a PDF and a JPEG representing the same thing. A user is trying to create a work order along with an attached image showing a faulty machine part. To the user and to the work order system, these two artifacts are managed as a set. A single request may create the work order, the attachment, and the relationship between them, atomically.
When the user retrieves the work order later, they expect a single request by default to retrieve the work order plus all attachments.
When the user updates the work order, e.g. to mark it completed, they only want to update the work order proper, not its attachments.
Users may add/remove/replace attachments to the work order during its lifetime.

== Requirements ==

===Functional Requirements===
# Create Containers, from [[#UC1: Manage containers]]
# Creation of nested containers, from [[#UC1: Manage containers]]
# Creation of resources (within a container), from [[#UC2: Manage resources]]
# Deletion of resources, from [[#UC2: Manage resources]]
# Moving contained resources, from [[#UC2: Manage resources]]
# Retrieve resource description, from [[#UC3: Retrieve resource description]]
# Retrieve description of a non-document resource, from [[#UC3: Retrieve resource description]]
# Enrichment (substituting update of existing resource), from [[#UC4: Update existing resource]]
# Selective update of a resource, from [[#UC4: Update existing resource]]
# Determine if a resource has changed, from [[#UC5: Determine if a resource has changed]]
# Add a resource to a collection, from [[#UC6: Aggregate resources]]
# Add a resource to multiple collections, from [[#UC6: Aggregate resources]]
# Retrieve collection-level description, from [[#UC7: Filter resource description]]
# Retrieve item-level description of a collection, from [[#UC7: Filter resource description]]
# Access media resources, from [[#UC8: Manage media resources]]
# Media-resource attachments, from [[#UC8: Manage media resources]]

===Non-Functional Requirements===

# Provide access guidance to resources, from [[#UC1: Manage containers]]
# Non-duplication of resources, from [[#UC2: Manage resources]]
# Distribution of resources, from [[#UC2: Manage resources]]
# Consistent, global naming, from [[#UC2: Manage resources]]
# Use standard vocabularies as appropriate, from [[#UC3: Retrieve resource description]]
# Scalable linking model, from [[#UC3: Retrieve resource description]]
# Unrestricted vocabulary, from [[#UC4: Update existing resource]]
# Resource descriptions are a "mix of simple data and collections", from [[#UC6: Aggregate resources]]
# Relative URIs enabling sharing of collections, from [[#UC6: Aggregate resources]]

== Acknowledgements ==
We would like to acknowledge the contributions of user-story authors; Christophe Guéret, Roger Menday, Eric Prud'hommeaux, Steve Speicher.

== References ==

Use Cases And Requirements

Sbattle2 — Mon, 10 Dec 2012 17:27:54 GMT

Sbattle2: /* Status of this Document */

= Linked Data Platform Use Cases And Requirements =

This is a working document used to collect use cases and requirements for consideration by the WG.
The starting point comes from [http://www.w3.org/Submission/2012/SUBM-ldbpucr-20120326/ Linked Data Basic Profile Use Cases and Requirements].

== Status of this Document ==

This document is currently under review pending release as a First Public Working Draft. While the editors have made every effort to identify a set of use-cases that are both evidenced in user-stories and in-scope of the charter, the document may yet be missing some key unidentified use-cases, or indeed, may include use-cases that ought to be removed. Furthermore, the coarse grouping of use-cases to avoid CRUDdy operations may not be to people's taste and is open to challenge.

===Timetable===
* <strike>Nov 26? WG to confirm User Story content: add, remove, refine (see process below). Note: this is ONLY User Stories (not Use Cases, Use Case Scenarios or Requirements)</strike>
** <strike>Issues before Nov 26th? will be included into FPWD</strike>
* Editors to:
** <strike>Dec 3 refine User Stories based on feedback</strike>
** <strike>Dec 5 elaborate on Use Cases in support of User Stories</strike>
* Dec 10 - WG to review prior to FPWD
** Review period ends Dec 15th
** insert open issues into draft for FPWD
* Dec 17 - Publish FPWD
** convert wiki page to ReSpec for FPWD
* Dec ?? Deadline for publications by year end 2012

===To Be Done===
* <strike>Move [[#LDP_and_Authentication.2FAuthorization| LDP and Authentication]] to [http://www.w3.org/2012/ldp/wiki/AccessControl AccessControl]</strike>
* <strike>Complete [[#Alternative_scenario:_moving_contained_resources| moving contained resources]] scenario with content from ericP on issue-30.</strike>
* <strike>Augment [[#Cloud_Infrastructure_Management| Cloud Infrastructure Management]] scenario with content from Roger Menday.</strike>
* <strike>Ensure issue-40/41 are fully covered in [[#UC8:_Managing_non-RDF_Resources| UC8: Managing non-RDF Resources]]. 2 scenarios (single v multiple attachments) ?</strike>
* <strike>Contact owner of [[#Data_Sharing| Data Sharing]] user-story to determine if we keep or not.</strike>
* <strike>Review [[#Requirements| Requirements]] section for functional/non-functional requirements arising in UCs.</strike>
* <strike>Propose resolutions to open issues against UC&R where possible.</strike>
* <strike>Identify and acknowledge user-story contributors.</strike>
* <strike>Check hyperlinks</strike>
* Convert to ReSpec
* Annotate document with open issues against UC&R
** <strike>[http://www.w3.org/2012/ldp/track/issues/30 ISSUE-30] (OPEN)</strike>
** [http://www.w3.org/2012/ldp/track/issues/40 ISSUE-40] (PENDING REVIEW)
** [http://www.w3.org/2012/ldp/track/issues/41 ISSUE-41] (PENDING REVIEW)

=== Process to introduce new User Stories & Use Cases ===

Open an Issue in the tracker against the UC&R product. The WG will review these and decide whether they are valid.

== Scope and Motivation ==

Linked Data was defined by Tim Berners-Lee with the following guidelines [http://www.w3.org/DesignIssues/LinkedData.html]:

# Use URIs as names for things
# Use HTTP URIs so that people can look up those names
# When someone looks up a URI, provide useful information, using the standards (RDF*, SPARQL)
# Include links to other URIs. so that they can discover more things

These four rules have proven very effective in guiding and inspiring people to publish Linked Data on the web. The amount of data, especially public data, available on the web has grown rapidly, and an impressive number of extremely creative and useful “mashups” have been created using this data as result.

There has been much less focus on the potential of Linked Data as a model for managing data on the web - the majority of the Application Programming Interfaces (APIs) available on the Internet for creating and updating data follow a Remote Procedure Call (RPC) model rather than a Linked Data model.

If Linked Data were just another model for doing something that RPC models can already do, it would be of only marginal interest. Interest in Linked Data arises from the fact that applications with an interface defined using Linked Data can be much more easily and seamlessly integrated with each other than applications that offer an RPC interface. In many problem domains, the most important problems and the greatest value are found not in the implementation of new applications, but in the successful integration of multiple applications into larger systems.

Some of the features that make Linked Data exceptionally well suited for integration include:

* A single interface – defined by a common set of HTTP methods – that is universally understood and is constant across all applications. This is in contrast with the RPC architecture where each application has a unique interface that has to be learned and coded to.
* A universal addressing scheme – provided by HTTP URLs – for both identifying and accessing all “entities”. This is in contrast with the RPC architecture where there is no uniform way to either identify or access data.
* A simple yet extensible data model – provided by RDF – for describing data about a resource in a way which doesn’t require prior knowledge of vocabulary being used.

Experience implementing applications and integrating them using Linked Data has shown very promising results, but has also demonstrated that the original four rules defined by Tim Berners-Lee for Linked Data are not sufficient to guide and constrain a writable Linked Data API. As was the case with the original four rules, the need generally is not for the invention of fundamental new technologies, but rather for a series of additional rules and patterns that guide and constrain the use of existing technologies in the construction of a Basic Profile for Linked Data to achieve interoperability.

The following list illustrates a few of the issues that require additional rules and patterns:
* What URLs do I post to in order to create new resources?
* How do I get lists of existing resources, and how do I get basic information about them without having to access each one?
* How should I detect and deal with race conditions on write?
* What media-types/representations should I use?
* What standard vocabularies should I use?
* What primitive data types should I use?

A good goal for the Basic Profile for Linked Data would be to define a specification required to allow the definition of a writable Linked Data API equivalent to the simple application APIs that are often written on the web today using the Atom Publishing Protocol (APP). APP shares some characteristics with Linked Data, such as the use of HTTP and URLs. One difference is that Linked Data relies on a flexible data model with RDF, which allows for multiple representations.

== Organization of this Document ==

This document is organized as follows:

* '''[[#User Stories| User Stories]]''' capture statements about system requirements written from a user or application perspective. They are typically lightweight and informal and can run from one line to a paragraph or two (sometimes described as an 'epic') [http://www.agilemodeling.com/artifacts/userStory.htm]. Analysis of each user story will reveal a number of (functional) use-cases and other non-functional requirements. See [http://www.w3.org/TR/dap-policy-reqs/| Device API Access Control Use Cases and Requirements] for a good example of user stories and their analysis.

* '''[[#Use Cases| Use Cases]]''' are used to capture and model functional requirements. Use cases describe the system’s behavior under various conditions [http://alistair.cockburn.us/get/2465], cataloguing who does what with the system, for what purpose, but without concern for system design or implementation [http://www.bredemeyer.com/pdf_files/functreq.pdf]. Each use case is identified by a reference number to aid cross-reference from other documentation; use-case indexing in this document is based on [http://www.w3.org/TR/rdb2rdf-ucr/ rdb2rdf use-cases]. A variety of styles may be used to capture use-cases, from a simple narrative to a structured description with actors, pre/post conditions, and step-by-step behaviours as in [http://www.w3.org/TR/powder-use-cases/ POWDER: Use Cases and Requirements], and non-functional requirements raised by the use-case. Use cases act like the hub of a wheel, with spokes supporting requirements analysis, scenario-based evaluation, testing, and integration with non-functional, or quality requirements.

* '''Scenarios''' are more focused still, representing a single instance of a use case in action. Scenarios may range from lightweight narratives as seen in [http://www.w3.org/TR/media-frags-reqs/ Use cases and requirements for Media Fragments], to being formally modeled as interaction diagrams. Each use-case should include at least a primary scenario, and possibly other alternative scenarios.

* '''[[#Requirements| Requirements]]''' list non-functional or quality requirements, and the use cases they may be derived from. This approach is exemplified in the [http://dvcs.w3.org/hg/gld/raw-file/default/dcat-ucr/index.html Use Cases and Requirements for the Data Catalog Vocabulary].

== User Stories ==

=== Maintaining Social Contact Information ===

Many of us have multiple email accounts that include information about the people and organizations we interact with – names, email addresses, telephone numbers, instant messenger identities and so on. When someone’s email address or telephone number changes (or they acquire a new one), our lives would be much simpler if we could update that information in one spot and all copies of it would automatically be updated. In other words, those copies would all be linked to some definition of “the contact.” There might also be good reasons (like off-line email addressing) to maintain a local copy of the contact, but ideally any copies would still be linked to some central “master.”

Agreeing on a format for “the contact” is not enough, however. Even if all our email providers agreed on the format of a contact, we would still need to use each provider’s custom interface to update or replace the provider’s copy, or we would have to agree on a way for each email provider to link to the “master”. If we look outside our own personal interests, it would be even more useful if the person or organization exposed their own contact information so we could link to it.

What would work in either case is a common understanding of the resource, a few formats needed, and access guidance for these resources. This would support how to acquire a link to a contact, and how to use those links to interact with a contact (including [[#UC3: Retrieve resource description|reading]], [[#UC4: Update existing resource|updating]], and [[#Alternative scenario: delete resource|deleting]] it), as well as how to easily [[#Primary scenario: create resource|create a new contact]] and add it to my contacts and when deleting a contact, how it would be removed from my list of contacts. It would also be good to be able to add some application-specific data about my contacts that the original design didn’t consider. Ideally we’d like to eliminate multiple copies of contacts, there would be additional valuable information about my contacts that may be stored on separate servers and need a simple way to link this information back to the contacts. Regardless of whether a contact collection is my own, shared by an organization, or all contacts known to an email provider (or to a single email account at an email provider), it would be nice if they all worked pretty much the same way.

=== Keeping Track of Personal and Business Relationships ===

In our daily lives, we deal with many different organizations in many different relationships, and they each have data about us. However, it is unlikely that any one organization has all the information about us. Each of them typically gives us access to the information (at least some of it), many through websites where we are uniquely identified by some string – an account number, user ID, and so on. We have to use their applications to interact with the data about us, however, and we have to use their identifier(s) for us. If we want to build any semblance of a holistic picture of ourselves (more accurately, collect all the data about us that they externalize), we as humans must use their custom applications to find the data, copy it, and organize it to suit our needs.

Would it not be simpler if at least the Web-addressable portion of that data could be linked to consistently, so that instead of maintaining various identifiers in different formats and instead of having to manually supply those identifiers to each one’s corresponding custom application, we could essentially build a set of bookmarks to it all? When we want to [[#UC3: Retrieve resource description|examine]] or [[#UC4: Update existing resource|change]] their contents, would it not be simpler if there were a single consistent application interface that they all supported? Of course it would.

Our set of links would probably be a [[#UC6: Aggregate resources|simple collection]]. The information held by any single organization might be a mix of simple data and [[#UC6: Aggregate resources|collections of other data]], for example, a bank account balance and a collection of historical transactions. Our bank might easily have [[#Alternative scenario: create a nested container|a collection of accounts for each of its collection of customers]].

=== System and Software Development Tool Integration ===

System and software development tools typically come from a diverse set of vendors and are built on various architectures and technologies. These tools are purpose built to meet the needs for a specific domain scenario (modeling, design, requirements and so on.) Often tool vendors view integrations with other tools as a necessary evil rather than providing additional value to their end-users. Even more of an afterthought is how these tools’ data -- such as people, projects, customer-reported problems and needs -- integrate and relate to corporate and external applications that manage data such as customers, business priorities and market trends. The problem can be isolated by standardizing on a small set of tools or a set of tools from a single vendor, but this rarely occurs and if does it usually does so only within small organizations. As these organizations grow both in size and complexity, they have needs to work with outsourced development and diverse internal other organizations with their own set of tools and processes. There is a need for better support of more complete business processes (system and software development processes) that span the roles, tasks, and data addressed by multiple tools. This demand has existed for many years, and the tools vendor industry has tried several different architectural approaches to address the problem. Here are a few:

* Implement an API for each application, and then, in each application, implement “glue code” that exploits the APIs of other applications to link them together.
* Design a single database to store the data of multiple applications, and implement each of the applications against this database. In the software development tools business, these databases are often called “repositories.”
* Implement a central “hub” or “bus” that orchestrates the broader business process by exploiting the APIs described previously.

It is fair to say that although each of those approaches has its adherents and can point to some successes, none of them is wholly satisfactory. The use of Linked Data as an application integration technology has a strong appeal. [http://open-services.net/ OSLC]

=== Library Linked Data ===

The W3C Library Linked Data working group has a number of use cases cited in their Use Case Report. [http://www.w3.org/2005/Incubator/lld/wiki/UseCaseReport LLD-UC] These referenced use cases focus on the need to extract and correlate library data from disparate sources. Variants of these use cases that can provide consistent formats, as well as ways to improve or update the data, would enable simplified methods for both efficiently sharing this data as well as producing incremental updates without the need for repeated full extractions and import of data.

The 'Digital Objects Cluster' contains a number of relevant use-cases:

* Grouping: This should "Allow the end-users to define [[#UC6: Aggregate resources|groups of resources]] on the web that for some reason belong together. The relationship that exists between the resources is often left unspecified. Some of the resources in a group may not be under control of the institution that defines the groups."

* Enrichment: "Enable end-users to [[#UC4: Update existing resource|link resources together]]."

* Browsing: "[[#UC7: Filter resource description|Support end-user browsing through groups]] and resources that belong to the groups."

* Re-use: "Users should have the capability to re-use all or parts of a collection, with all or part of its metadata, elsewhere on the linked Web."

The 'Collections' cluster also contains a number of relevant use-cases:

* Collection-level description: "Provide [[#UC7: Filter resource description|metadata pertaining to a collection as a whole]], in contrast to item-level description."

* Collections discovery: "Enable innovative collection discovery such as identification of nearest location of a physical collection where a specific information resource is found or mobile device applications ... based on collection-level descriptions."

* Community information services: Identify and classify collections of special interest to the community.

=== Municipality Operational Monitoring ===

Across various cities, towns, counties, and various municipalities there is a growing number of services managed and run by municipalities that produce and consume a vast amount of information. This information is used to help monitor services, predict problems, and handle logistics. In order to effectively and efficiently collect, produce, and analyze all this data, a fundamental set of loosely coupled standard data sources are needed. A simple, low-cost way to [[#UC3: Retrieve resource description|expose data]] from the diverse set of monitored services is needed, one that can easily integrate into the municipalities of other systems that inspect and analyze the data. All these services have links and dependencies on other data and services, so having a simple and scalable linking model is key.

=== Healthcare ===

For physicians to analyze, diagnose, and propose treatment for patients requires a vast amount of complex, changing and growing knowledge. This knowledge needs to come from a number of sources, including physicians’ own subject knowledge, consultation with their network of other healthcare professionals, public health sources, food and drug regulators, and other repositories of medical research and recommendations.

To diagnose a patient’s condition requires current data on the patient’s medications and medical history. In addition, recent pharmaceutical advisories about these medications are linked into the patient’s data. If the patient experiences adverse affects from medications, these physicians need to publish information about this to an appropriate regulatory source. Other medical professionals require access to both validated and emerging effects of the medication. Similarly, if there are geographical patterns around outbreaks that allow both the awareness of new symptoms and treatments, this information needs to quickly reach a very distributed and diverse set of medical information systems. Also, reporting back to these regulatory agencies regarding new occurrences of an outbreak, including additional details of symptoms and causes, is critical in producing the most effective treatment for future incidents.

=== Metadata Enrichment in Broadcasting ===

There are many different use cases when broadcasters show interest in metadata [[#UC4: Update existing resource| enrichment]]:

* enrich archive or news metadata by linking facts, events, locations and personalities
* enrich metadata generated by automatic extraction tools such as person identification, etc.
* enrich definitions of terms in classification schemes or enumeration lists

This comes in support of more effective information management and data/content mining (if you can't find your content, it' like if you don't have and must either recreate or acquire it again, which is not financially effective).

However, there is a need for solutions facilitating linkage to other data sources and taking care of the issues such as discovery, automation, disambiguation. Etc. Other important issues that broadcasters would face are the editorial quality of the linked data, its persistence, and usage rights.

=== Aggregation and Mashups of Infrastructure Data ===

For infrastructure management (such as storage systems, virtual machine environments, and similar IaaS and PaaS concepts), it is important to provide an environment in which information from different sources can be [[#UC6: Aggregate resources|aggregated]], [[#UC7: Filter resource description|filtered]], and visualized effectively. Specifically, the following use cases need to be taken into account:

* While some data sources are based on Linked Data, others are not, and aggregation and mashups must work across these different sources.
* Consumers of the data sources and aggregated/filtered data streams are not necessarily implementing Linked Data themselves, they may be off-the-shelf components such as dashboard frameworks for composing visualizations.
* Simple versions of this scenario are pull-based, where the data is requested from data sources. In more advanced settings, without a major change in architecture it should be possible to move to a push-based interaction model, where data sources push notifications to subscribers, and data sources provide different services that consumers can subscribe to (such as "informational messages" or "critical alerts only").

In this scenario, the important factors are to have abstractions that allow easy aggregation and filtering, are independent from the internal data model of the sources that are being combined, and can be used for pull-based interactions as well as for push-based interactions.

=== Sharing payload of RDF data among low-end devices ===

Several projects around the idea of [http://worldwidesemanticweb.wordpress.com/ downscaling the Semantic Web] need to be able to ship payloads of RDF across the nodes member of a given network. The transfers are done in a constrained context in terms of bandwidth, scope of the local semantics employed by the nodes and computing capabilities of the nodes. In a P2P style, every node has the capability to act either as a data consumer or a data provider, serving its own data or acting as a relay to pass other's data along (typically in mesh networks).

The transfer of an arbitrary payload of RDF data could be implemented through the container mechanism, adding and removing sets of RDF triples to it. Currently, one of the project "SemanticXO" uses named graphs and the graph protocol to create/delete/copy graphs across the nodes but this (almost) imposes the usage of a triple store. Unfortunately, triple store are rather demanding piece of software that are not always usable on limited hardware. Some generic ReST like interaction backed up with a lightweight column store would be better approach.

=== Sharing Binary Resources and Metadata ===

When publishing datasets about stars one may want to publish links to the pictures in which those stars appear, and this may well require publishing the pictures themselves. Vice versa: when publishing a picture of space we need to know which telescope took the picture, which part of the sky it was pointing at, what filters were used, which identified stars are visible, who can read it, who can write to it, ...

If LinkedData contains information about resources that are most naturally expressed in non-rdf formats (be they binary such as pictures or videos, or human readable documents in XML formats), those non RDF formats should be just as easy to publish to the LinkedData server as the RDF relations that link those resources up. A LinkedData server should therefore allow publishing of non linked data resources too, and make it easy to publish and edit metadata about those resources.

The resource comes in two parts - the image and information about the image (which may in the image file but better external to it as it's more general). The information about the image is vital. It's a compound item of image data and other data (being application metadata about the image does not distinguish from the platform's point-of-view.

=== Data Catalogs ===

The Asset Description Metadata Schema ([http://joinup.ec.europa.eu/asset/adms/home ADMS]) provides the data model to describe semantic assets repositories contents, but this leaves many open challenges when building a federation of these repositories to serve the need of assets reuse. These include accessing and querying individual repositories and efficiently retrieving [[#UC5: Determine if a resource has changed| updated content]] without having to retrieve the whole content. Hence, we chose to build the integration solution capitalizing on the Data Warehousing integration approach. This allows us to cope with heterogeneity of sources technologies and to benefit from the optimized performance it offers, given that individual repositories do not usually change frequently. With Data Warehousing, the federation requires to:

* understand the data, i.e. understand their semantic descriptions, and other systems.
* seamlessly exchange the semantic assets metadata from different repositories
* keep itself up-to-date.

Repositories owners can maintain de-referenceable URIs for their repository description and contained assets in a Linked Data compatible manner. ADMS provides the necessary data model to enable meaningful exchange of data. However, This leaves the challenge of efficient access to the data not fully addressed.

Related: [http://spec.datacatalogs.org/ Data Catalog Schema and Protocol]

=== Constrained Devices and Networks ===

Information coming from resource constrained devices in the Web of Things ([http://en.wikipedia.org/wiki/Web_of_Things WoT]) has been identified as a major driver in many domains, from smart cities to environmental monitoring to real-time tracking. The amount of information produced by these devices is growing exponentially and needs to be accessed and integrated in a systematic, standardized and cost efficient way. By using the same standards as on the Web, integration with applications will be simplified and higher-level interactions among resource constrained devices, abstracting away heterogeneities, will become possible. Up-coming IoT/WoT standards such as [http://datatracker.ietf.org/wg/6lowpan/ 6LowPAN] - IPv6 for resource constrained devices - and the Constrained Application Protocol ([http://tools.ietf.org/html/draft-ietf-core-coap CoAP]), which provides a downscaled version of HTTP on top of UDP for the use on constrained devices, are already at a mature stage. The next step now is to support RESTful interfaces also on resource constrained devices, adhering to the Linked Data principles. Due to the limited resources available, both on the device and in the network (such as bandwidth, energy, memory) a solution based on SPARQL Update is at the current point in time considered not to be useful and/or feasible. An approach based on the [http://tools.ietf.org/html/draft-castellani-core-http-mapping HTTP-CoAP Mapping] would enable constrained devices to directly participate in a Linked Data-based environment.

=== Services Supporting the Process of Science ===
Many fields of science now include branches with in silico data-intensive methods, e.g. bioinformatics, astronomy. To support these new methods we look to move beyond the established platforms provided by scientific workflow systems to capture, assist, and preserve the complete lifecycle from record of the experiment, through local trusted sharing, analysis, dissemination (including publishing of experimental data "beyond the PDF"), and re-use.

* [[#UC6: Aggregate resources|Aggregations]], specifically ''Research Objects (ROs)'' that are exchanged between services and clients bringing together workflows, data sets, annotations, and provenance. We use an RDF model for this. While some aggregated contents are encoded using RDF and in increasing number are linked data sources, others are not; while some are stored locally "within" the RO, others are remote (in both cases this is often due to size of the resources or access policies).
* Services that are distributed and linked. Some may be centralising for e.g. publication, others may be local, e.g. per lab. We need lightweight services that can be simply and easily integrated into and scale across the wide variety of softwares and data used in science: we have adopted a RESTful approach where possible.
** Foundation services that collect and expose ROs for storage, modification, exploration, and reuse.
** Services that provide added-value to ROs such as seamless import/export from scientific workflow systems, automated stability evaluation, or recommendation (and therefore interact with the foundation services to retrieve/store/modify/ROs).

seeAlso: [http://www.wf4ever-project.org/ Wf4Ever]

=== Project Membership Information : Information Evolution ===

Information about people and projects changes as roles change, as organisations change
and as contact details change. Finding the current state of a project is important
in enabling people to contact the right person in the right role. It can also be
useful to look back and see who was performing what role in the past.

A use of a Linked Data Platform could be to give responsibility for managing
such information with the project team itself, not requiring updates to be
requested of a centralised website administrator.

This could be achieved with:

* Resource descriptions for each person and project
* A container resource to describe roles/membership in the project.

To retain the history of the project, the old version of a resources,
including container resources, should be retained so there is a need to address both specific items
and also have a notion of "current".

Access to information has two aspects:
* Access to the "current" state, regardless of the version of the resource description
* Access to historical state, via access to a specific version of the resource description

=== Cloud Infrastructure Management===

Cloud operators offer API support to provide customers with remote access for the management of Cloud infrastructure (IaaS). Infrastructure consists of Systems, Computers, Networks, Discs, etc. The overall structure can be seen as mostly hierarchical, (Cloud contains Systems, Systems contain Machines, etc), complemented with crossing links (e.g. multiple Machines connected to a Network).

The IaaS scenario makes specific requirements on lifecycle management and discovery, handling non-instant changes, history capture and query:

* Many aspects of Cloud infrastructure have associated lifecycle, e.g. a Computer can be transitioned between Running and Shutdown. This should be manageable through the API, which should include how a client discovers dynamic lifecycle options and thus help steering through an application.
* It is often the case that attaining a new lifecycle state is not instantaneous. Clients require a universal mechanism for monitoring such changes.
* A facility to retrieve all events in the lifecycle of a resource can be useful.
* Query provides the means to interrogate the resources behind the API, as well as finding new entry points into the application.

Infrastructure management may be viewed as the manipulation of the underlying graph of resources.

== Use Cases ==
The following use-cases are each derived from one or more of the user-stories above. These use-cases are explored in detail through the development of scenarios, each motivated by some key aspect exemplified by a single user-story. The examples they contain are included purely for illustrative purposes, and should not be interpreted normatively.

===UC1: Manage containers===
A number of user-stories introduce the idea of a ''container'' as a mechanism for creating and managing resources within the context of an application. Resources grouped together within the same container would typically belong to the same application. A container is identified by a URI so is a resource in its own right.
The properties of a container may also represent the ''affordances'' of that container, enabling clients to determine what other operations they can do on that container. These operations may include descriptions of application specific services that can be invoked by exchanging RDF documents.

* Provide "access guidance for ... resources" (affordances) (from user-story, [[#Maintaining Social Contact Information|Maintaining Social Contact Information]]).

====Primary scenario: create container====
Create a new container resource within the LDP server.
In [[#Services Supporting the Process of Science|Services supporting the process of science]], [http://wf4ever.github.com/ro-primer/ Research Objects] are semantically rich aggregations of resources that bring together data, methods and people in scientific investigations. A basic workflow research object will be created to aggegate [http://ceur-ws.org/Vol-903/paper-01.pdf scientific workflows] and the artefacts that result from this workflow. The research object begins life as an empty container into which workflows, datasets, results and other data will be added throughout the lifecycle of the project.

<nowiki>
@prefix ro: http://purl.org/wf4ever/ro#
@prefix dct: http://purl.org/dc/terms/
@prefix ore: http://www.openarchives.org/ore/

<> a ro:ResearchObject, ore:Aggregation ;
dct:created "2012-12-01"^^xsd:dateTime .
</nowiki>

====Alternative scenario: create a nested container====
The motivation for nested containers comes from the [[#System and Software Development Tool Integration| System and Software Development Tool Integration]] user-story. The OSLC Change Management vocabulary allows bug reports to have attachments referenced by the membership predicate <nowiki>oslc_cm:attachment</nowiki>. The 'top-level-container' contains issues, and each issue resource has its own container of attachment resources.

<nowiki>
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix oslc_cm: <http://open-services.net/ns/cm#>.
@prefix : <http://example.org/>.

:top-level-container rdfs:member :issue1234 .

:issue1234 a oslc_cm:ChangeRequest;
dcterms:identifier "1234";
dcterms:type "a bug";
dcterms:related :issue1235 ;
oslc_cm:attachments :attachments123.

:issue1235 a oslc_cm:ChangeRequest;
dcterms:title "a related bug".

:attachments a oslc_cm:AttachmentList;
oslc_cm:attachment :attachment324, :attachment251.
</nowiki>

===UC2: Manage resources===
This use-case addresses the managed lifecycle of a resource and is concerned with resource ''ownership''. The responsibility for managing resources belongs with their container.
For example, a container may accept a request from a client to make a new resource.
This use-case focuses on creation and deletion of resources in the context of a container, and the potential for transfer of ownership by moving resources between containers.
The ownership of a resource should always be clear; no resource managed in this way should ever be owned by more than one container.

Once a new resource has been created it should be identified by a URI. Clients may defer responsibility for establishing dereferenceable URIs to the container of their data.
The container is a natural choice for the endpoint for this interface as it will already have some application-specific knowledge about the contained resources.
While the LDP has ultimate control over resource naming, some applications may require more control over naming, perhaps to provide a more human-readable URI. An LDP server could support something like the [http://tools.ietf.org/html/rfc5023 Atom Publishing Protocol] slug header to convey a user defined naming 'hint'.

* Non-duplication of resources: "Eliminate multiple copies", representing resources in a single place (from [[#Maintaining Social Contact Information]]).
* Distribution of resources: Linked aata "may be stored on separate servers" (from [[#Maintaining Social Contact Information]]).
* Consistent, global naming: Resources should be "linked to consistently, ... instead of maintaining various identifiers in different formats" (from [[#Keeping Track of Personal and Business Relationships]]).

====Primary scenario: create resource====
Resources begin life by being created within a container. From user-story, [[#Maintaining Social Contact Information|Maintaining Social Contact Information]], It should be possible to "easily create a new contact and add it to my contacts." This suggests that resource creation is closely linked to the application context. The new resource is created in a container representing "my contacts." The lifecycle of the resource is linked to the lifecycle of it's container. So, for example, if "my contacts" is deleted then a user would also reasonably expect that all contacts within it would also be deleted.

Contact details are captured as an RDF description and it's properties, including "names, email addresses, telephone numbers, instant messenger identities and so on." The description may include non-standard RDF; "data about my contacts that the original design didn’t consider."
The following RDF could be used to describe contact information using the [http://www.foaf-project.org FOAF] vocabulary. A contact is represented here by a <nowiki>foaf:PersonalProfileDocument</nowiki> defining a resource that can be created and updated as a single-unit, even though it may describe ancillary resources, such as a <nowiki>foaf:Person</nowiki>, below.

<nowiki>
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

<> a foaf:PersonalProfileDocument;
foaf:PrimaryTopic [
a foaf:Person;
foaf:name "Timothy Berners-Lee";
foaf:title "Sir";
foaf:firstName "Timothy";
foaf:surname "Berners-Lee";
foaf:nick "TimBL", "timbl";
foaf:homepage <http://www.w3.org/People/Berners-Lee/>;
foaf:weblog <http://dig.csail.mit.edu/breadcrumbs/blog/4>;
foaf:mbox <mailto:timbl@w3.org>;
foaf:workplaceHomepage <http://www.w3.org/>.
]
</nowiki>

====Alternative scenario: delete resource====
Delete a resource and all it's properties. If the resource resides within a container it will be removed from that container, however other links to the deleted resource may be left as dangling references.
In the case where the resource is a container, the server may also delete any or all contained resources.
In normal practice, a deleted resource cannot be reinstated. There are however, edge-cases where limited undelete may be desirable.
Best practice states that "[http://www.w3.org/TR/cooluris/| Cool URIs don't change]", which implies that deleted URIs shouldn't be recycled.

====Alternative scenario: moving contained resources====
Many resources may have value beyond the life of their membership in a container. This implies methods to add references to revise container membership.
Cloning container members for use in other containers results in duplication of information and maintenance problems; web practice is to encourage the creation of one resource, which may be referenced as many places as necessary. A change of ownership may - or may not - imply a change of URI, depending upon the specific LDP naming policy. While assigning a new URI to a resource is discouraged [http://www.w3.org/DesignIssues/Architecture.html#HTTP], it is possible to indicate that a resource has moved with an appropriate HTTP response.

===UC3: Retrieve resource description===
Access the current description of a resource, containing properties of that resource and links to related resources. The representation may include descriptions of related resources that cannot be accessed directly.
Depending upon the application, an LDP may enrich the retrieved RDF with additional triples. Examples include adding incoming links, sameAs closure and type closure.
The HTTP response should also include versioning information (i.e. last update or entity tag) so that subsequent updates can ensure they are being applied to the correct version.

* Use standard vocabularies as appropriate to enable a "common understanding of the resource" (from [[#Maintaining Social Contact Information|Maintaining Social Contact Information]]).
* A "scalable linking model is key" (from [[#Municipality Operational Monitoring]]).

====Primary scenario====
The user-story [[#Project Membership Information : Information Evolution| Project Membership Information]] discusses the representation of information about people and projects. It calls for "Resource descriptions for each person and project" allowing project teams to review information held about these resources. The example below illustrates the kinds of information that might be held about organizational structures based on the [http://www.epimorphics.com Epimorphics] [http://www.epimorphics.com/public/vocabulary/org.html organizational ontology].

Note that the example below defines two resources (shown as separate sections below) that will be hosted on an LDP based at <nowiki>http://example.com/</nowiki>. The representations of these resources may include descriptions of related resources, such as <nowiki>http://www.w3.org/</nowiki>, that that fall under a different authority and therefore can't be served from the LDP at this location.

<nowiki>
@prefix org: <http://www.w3.org/ns/org#> .
@prefix owltime: <http://www.w3.org/2006/time> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@base <http://example.com/> .

<member1> a org:Membership ;
org:member <http://www.w3.org/People/Berners-Lee/card#i> ;
org:organization http://www.w3.org/> ;
org:role <director> ;
org:memberDuring [a owltime:Interval; owltime:hasBeginning [
owltime:inXSDDateTime "1994-10-01T00:00:00Z"^^xsd:dateTime]] .

<http://www.w3.org/> a org:FormalOrganization ;
skos:prefLabel "The World Wide Web Consortium"@en ;
skos:altLabel "W3C" .
</nowiki>

<nowiki>
@prefix org: <http://www.w3.org/ns/org#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@base <http://example.com/> .

<director> a org:Role ;
rdfs:label "Director" .
</nowiki>

====Alternative scenario: retrieve description of a non-document resource====
In many cases, the things that are of interest are not always the things that are resolvable. The example below demonstrates how a foaf profile may be used to distinguish between the person and the profile; the former being the topic of the latter. This begs the question as to what a client should do with such non-document resources. In this case the HTTP protocol requires that the fragment part be stripped off before requesting the URI from the server. The result is a resolvable URI for the profile.

<nowiki>
@base <http://www.w3.org/People/Berners-Lee/card>
@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@prefix dc: <http://purl.org/dc/elements/1.1/>.

<> a foaf:PersonalProfileDocument ;
dc:title "Tim Berners-Lee's FOAF file" ;
foaf:homepage <http://www.w3.org/People/Berners-Lee/> ;
foaf:primaryTopic <#i> .
</nowiki>

===UC4: Update existing resource===
Change the RDF description of a LDP resource, potentially removing or overwriting existing data. This allows applications to ''enrich'' the representation of a resource by addling additional links to other resources.

* Unrestricted vocabulary: It should be possible be "able to add ... application-specific data" to resources (from [[#Maintaining Social Contact Information]]).

====Primary scenario: enrichment====
This relates to user-story [[#Metadata Enrichment in Broadcasting| Metadata Enrichment in Broadcasting]] and is based on the [http://www.bbc.co.uk/ontologies/sport/ BBC Sports Ontology]. The ''resource-centric'' view of linked-data provides a natural granularity for substituting, or overwriting a resource and its data. The simplest kind of update would simply replace what is currently known about a resource with a new representation. There are two distinct resources in the example below; a sporting event and an associated award. The granularity of the LDP would allow a user to replace the information about the award without disturbing the information about the event.

<nowiki>
@prefix sport: <http://www.bbc.co.uk/ontologies/sport/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

:mens_sprint a sport:MultiStageCompetition;
rdfs:label "Men's Sprint";
sport:award <#gold_medal> .

<#gold_medal> a sport:Award .
</nowiki>

We can enrich the description as events unfold, linking to the winner of the gold medal by substituting the above description with the following.

<nowiki>
@prefix sport: <http://www.bbc.co.uk/ontologies/sport/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

:mens_sprint a sport:MultiStageCompetition;
rdfs:label "Men's Sprint";
sport:award <#gold_medal> .
<#gold_medal> a sport:Award;
sport:awarded_to [
a foaf:Agent ;
foaf:name "Chris Hoy" .
] .
</nowiki>

====Alternative scenario: selective update of a resource====
This relates to user-story [[#Data Catalogs|Data Catalogs]], based on the [http://vocab.deri.ie/dcat Data Catalog Vocabulary].
A catalogue is described by the following RDF model.

<nowiki>
@prefix dcat: <http://www.w3.org/ns/dcat#> .
@prefix dcterms: <http://purl.org/dc/terms/> .

:catalog a dcat:Catalog ;
dcat:dataset :dataset/001;
dcterms:issued "2012-12-11"^^xsd:date.
</nowiki>

A catalog may contain multiple datasets, so when linking to new datasets it would be simpler and preferable to selectively add just the new dataset links.
A Talis ''changeset'' [http://docs.api.talis.com/getting-started/changesets][http://www.w3.org/2009/12/rdf-ws/papers/ws07] could be used to add a new <nowiki>dc:title</nowiki> to the dataset. The following update would be directed to the catalogue to add an additional dataset.

<nowiki>
@prefix : <http://example.com/>.
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix cs: <http://purl.org/vocab/changeset/schema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.

<change1>
a cs:ChangeSet ;
cs:subjectOfChange :catalog ;
cs:createdDate "2012-01-01T00:00:00Z" ;
cs:changeReason "Update catalog datasets" ;
cs:addition [
a rdf:Statement ;
rdf:subject :catalog ;
rdf:predicate dcat:dataset ;
rdf:object :dataset/002 .
] .
</nowiki>

===UC5: Determine if a resource has changed===
It should be possible to retrieve versioning information about a resource (e.g. last modified or entity tag) without having to download a representation of the resource.
This information can then be compared with previous information held about that resource to determine if it has changed.
This versioning information can also be used in subsequent ''conditional'' requests to ensure they are only applied if the version is unchanged.

====Primary scenario====
Based on the user-story, [[#Constrained Devices and Networks| Constrained Devices and Networks]], an LDP could be configured to act as a proxy for a [http://tools.ietf.org/html/draft-ietf-core-coap CoAP] based [http://en.wikipedia.org/wiki/Web_of_Things Web of Things]. As an observer of CoAP resources, the LDP registers its interest so that it will be notified whenever the sensor reading changes. Clients of the LDP can interrogate the LDP to determine if the state has changed.

In this example, the information about a sensor and corresponding sensor readings can be represented as RDF resources. The first resource below, represents a sensor described using the [http://www.w3.org/2005/Incubator/ssn/ Semantic Sensor Network] ontology.
<nowiki>
@prefix : <http://example.com/energy-management/>.

<> a :MainsFrequencySensor;
rdfs:comment "Sense grid load based on mains frequency";
ssn:hasMeasurementCapability [
a :FrequencyMeasurementCapability;
ssn:hasMeasurementProperty <#property_1> .
] .
</nowiki>

The value of the sensor changes in real-time as measurements are taken. The LDP client can interrogate the resource below to determine if it has changed, ''without'' necessarily having to download the RDF representation. As different sensor properties are represented disjointly (separate RDF representations) they may change independently.

<nowiki>
@prefix : <http://example.com/energy-management/>.

<http://example.com/energy-management#property_1> :hasMeasurementPropertyValue <> .
<> a :FrequencyValue;
:hasQuantityValue "50"^^xsd:float.
</nowiki>

===UC6: Aggregate resources===
There is a requirement to be able to manage ''collections'' of resources. The concept of a collection overlaps with, but is distinct from that of a container. These collections are (weak) aggregations, unrelated to the lifecycle management of resources, and distinct from the ownership between a resource and its container. However, the composition of a container may be reflected as a collection to support navigation of the container and its contents. There is a need to be able to create collections by adding and deleting individual membership properties. Resources may belong to multiple collections, or to none.

* Resource descriptions are a "mix of simple data and collections" (from [[#Keeping Track of Personal and Business Relationships]]).
* Relative URIs: It should be possible to "ship payloads of RDF" for a collection as a whole without breaking internal links (from [[#Constrained Devices and Networks]]).

====Primary scenario: add a resource to a collection====
This example is from [[#Library Linked Data|Library Linked Data]] and [http://www.w3.org/2005/Incubator/lld/wiki/UseCaseReport LLD-UC], specifically [http://www.w3.org/2005/Incubator/lld/wiki/Use_Case_Subject_Search Subject Search].

There is an existing collection at <nowiki><http://example.com/concept-scheme/subject-heading></nowiki> that defines a collection of subject headings. This collection is defined as a skos:ConceptScheme and
the client wishes to insert a new concept into the scheme. which will be related to the collection via a <nowiki>skos:inScheme</nowiki> link. The new subject-heading, "outer space exploration", is not necessarily owned by a container. The following RDF would be added to the (item-level) description of the collection.

<nowiki>
@prefix scheme : <http://example.com/concept-scheme/>.
@prefix concept : <http://example.com/concept/>.

scheme:subject-heading a skos:ConceptScheme.

concept:Outer+space+Exploration skos:inScheme scheme:subject-heading.
</nowiki>

====Alternative scenario: add a resource to multiple collections====
Logically, a resource should not be owned by more than one container. however, it may be a member of multiple collections which define a weaker form of ''aggregation''. As this is simply a manipulation of the RDF description of a collection, it should be possible to add the same resource to multiple collections.

As a machine-readable collection of medical terms, the [http://www.ihtsdo.org| SNOMED] ontology is of key importance in [[#Healthcare | healthcare]]. SNOMED CT allows concepts with more than one parent that don't fall into a lattice.
In the example below, the same concept may fall under two different parent concepts.
The example uses skos:narrowerTransitive to elide intervening concepts.

<nowiki>
@prefix : <http://example.com/snomed/>.

:_119376003 a skos:Concept ;
skos:prefLabel "Tissue specimen"
skos:narrowerTransitive :TissueSpecimenFromHeart.

:_127462005 a skos:Concept ;
skos:prefLabel "Specimen from heart"
skos:narrowerTransitive :TissueSpecimenFromHeart.

:_128166000 a skos:Concept;
rdfs:label "Tissue specimen from heart".
</nowiki>

===UC7: Filter resource description===
This use-case extends the normal behaviour of retrieving an RDF description of a resource, by dynamically excluding specific (membership) properties.
For containers, it is often desirable to be able to read a collection, or item-level description that excludes the container membership.

====Primary scenario: retrieve collection-level description====
This scenario, based on [[#Library Linked Data| Library Linked Data]], uses the Dublin Core Metadata Initiative [http://dublincore.org/groups/collections/collection-application-profile/| Collection-Level] description.
A collection can refer to any aggregation of physical or digital items.
This scenario covers the case whereby a client can request a collection-level description as typified by the example below, without necessarily having to download a full listing of the items within the collection.

<nowiki>
@prefix rdf: <rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">.
@prefix dc: <http://purl.org/dc/elements/1.1/>.
@prefix : <http://example.org/bookshelf/>.
@prefix dcmitype: <http://purl.org/dc/dcmitype/>.
@prefix cld: <http://purl.org/cld/terms/>.
@prefix dcterms: <http://purl.org/dc/terms/>.

<> dc:type dcmitype:Collection ;
dc:title "Directory of organizations working with Linked Data" ;
dcterms:abstract "This is a directory of organisations specializing in Linked Data."
cld:isLocatedAt <http://dir.w3.org>
cld:isAccessedVia <http://dir.w3.org/rdf/2012/directory/directory-list.xhtml?construct>
</nowiki>

====Alternative scenario: retrieve item-level description of a collection====
This use-case scenario, also based on [[#Library Linked Data| Library Linked Data]], focuses on obtaining an item-level description of the resources aggregated by a collection.
The simplest scenario is where the members of a collection are returned within a single representation, so that a client can explore the data by following these links. Different applications may use different membership predicates to capture this aggregation. The example below uses <nowiki>rdfs:member</nowiki>, but many different membership predicates are in common use, including RDF Lists.
Item-level descriptions can be captured using the Functional Requirements for Bibliographic Records ([http://www.ifla.org/publications/functional-requirements-for-bibliographic-records FRBR]) [http://vocab.org/frbr/core.html ontology].

<nowiki>
@prefix frbr: <http://purl.org/vocab/frbr/core#>.

<> rdfs:member <#ebooks97>, <#ebooks21279>.

<#work97> a frbr:LiteraryWork;
dc:title "Flatland: a romance of many dimensions" ;
frbr:creator <#Abbott_Edwin>;
frbr:manifestation <ebook97>.

<#work21279> a frbr:LiteraryWork;
dc:title "2 B R 0 2 B" ;
frbr:creator <#Vonnegut_Kurt>;
frbr:manifestation <ebook21279>.
</nowiki>

Collections are potentially very large, so some means may be required to limit the size of RDF representation returned by the LDP (e.g. pagination).

===UC8: Manage media resources===
It should be possible to easily add non-RDF media resources to containers that accept them. Media resources may be updated and removed during the lifecycle of the container.

====Primary scenario: access media resources====
From the User Story [[#Sharing Binary Resources and Metadata| Sharing Binary Resources and Metadata]] it should be possible to easily add non RDF resources to a containers that accept them. Clients submit a non-RDF representation to a container in a media type accepted by that container. The container creates a URI to represent this media resource, and creates a link from the container to the new URI.The media resource may have an explicit representation of the media type. It should be possible to find the metadata about such a resource and to access and edit it in the usual ways.

This example uses the [http://www.w3.org/TR/mediaont-10/#ont-ttl Ontology for Media Resources] to describe a media resource added to a collection.
<nowiki>
@prefix ma: <http://www.w3.org/ns/ma-ont#> .

<dataset> a ma:Collection ;
:hasMember <dataset/image1.jpg>

<dataset/image1.jpg> a ma:MediaResource ;
ma:hasFormat "image/jpeg" .
</nowiki>

====Alternative scenario: media-resource attachments====
A resource may have multiple ''renditions''; the idea that you can have a PDF and a JPEG representing the same thing. A user is trying to create a work order along with an attached image showing a faulty machine part. To the user and to the work order system, these two artifacts are managed as a set. A single request may create the work order, the attachment, and the relationship between them, atomically.
When the user retrieves the work order later, they expect a single request by default to retrieve the work order plus all attachments.
When the user updates the work order, e.g. to mark it completed, they only want to update the work order proper, not its attachments.
Users may add/remove/replace attachments to the work order during its lifetime.

== Requirements ==

===Functional Requirements===
# Create Containers, from [[#UC1: Manage containers]]
# Creation of nested containers, from [[#UC1: Manage containers]]
# Creation of resources (within a container), from [[#UC2: Manage resources]]
# Deletion of resources, from [[#UC2: Manage resources]]
# Moving contained resources, from [[#UC2: Manage resources]]
# Retrieve resource description, from [[#UC3: Retrieve resource description]]
# Retrieve description of a non-document resource, from [[#UC3: Retrieve resource description]]
# Enrichment (substituting update of existing resource), from [[#UC4: Update existing resource]]
# Selective update of a resource, from [[#UC4: Update existing resource]]
# Determine if a resource has changed, from [[#UC5: Determine if a resource has changed]]
# Add a resource to a collection, from [[#UC6: Aggregate resources]]
# Add a resource to multiple collections, from [[#UC6: Aggregate resources]]
# Retrieve collection-level description, from [[#UC7: Filter resource description]]
# Retrieve item-level description of a collection, from [[#UC7: Filter resource description]]
# Access media resources, from [[#UC8: Manage media resources]]
# Media-resource attachments, from [[#UC8: Manage media resources]]

===Non-Functional Requirements===

# Provide access guidance to resources, from [[#UC1: Manage containers]]
# Non-duplication of resources, from [[#UC2: Manage resources]]
# Distribution of resources, from [[#UC2: Manage resources]]
# Consistent, global naming, from [[#UC2: Manage resources]]
# Use standard vocabularies as appropriate, from [[#UC3: Retrieve resource description]]
# Scalable linking model, from [[#UC3: Retrieve resource description]]
# Unrestricted vocabulary, from [[#UC4: Update existing resource]]
# Resource descriptions are a "mix of simple data and collections", from [[#UC6: Aggregate resources]]
# Relative URIs enabling sharing of collections, from [[#UC6: Aggregate resources]]

== Acknowledgements ==
We would like to acknowledge the contributions of user-story authors; Christophe Guéret, Roger Menday, Eric Prud'hommeaux, Steve Speicher.

== References ==

Use Cases And Requirements

Sbattle2 — Mon, 10 Dec 2012 17:27:26 GMT

Sbattle2: /* Timetable */

= Linked Data Platform Use Cases And Requirements =

This is a working document used to collect use cases and requirements for consideration by the WG.
The starting point comes from [http://www.w3.org/Submission/2012/SUBM-ldbpucr-20120326/ Linked Data Basic Profile Use Cases and Requirements].

== Status of this Document ==

This document is currently under review pending release as a First Public Working Draft. While the editors have made their best effort to identify a set of use-cases that are both evidenced in user-stories and in-scope of the charter, the document may yet be missing some key unidentified use-cases, or indeed, may include use-cases that ought to be removed. Furthermore, the coarse grouping of use-cases to avoid CRUDdy operations may not be to people's taste and is open to challenge.

===Timetable===
* <strike>Nov 26? WG to confirm User Story content: add, remove, refine (see process below). Note: this is ONLY User Stories (not Use Cases, Use Case Scenarios or Requirements)</strike>
** <strike>Issues before Nov 26th? will be included into FPWD</strike>
* Editors to:
** <strike>Dec 3 refine User Stories based on feedback</strike>
** <strike>Dec 5 elaborate on Use Cases in support of User Stories</strike>
* Dec 10 - WG to review prior to FPWD
** Review period ends Dec 15th
** insert open issues into draft for FPWD
* Dec 17 - Publish FPWD
** convert wiki page to ReSpec for FPWD
* Dec ?? Deadline for publications by year end 2012

===To Be Done===
* <strike>Move [[#LDP_and_Authentication.2FAuthorization| LDP and Authentication]] to [http://www.w3.org/2012/ldp/wiki/AccessControl AccessControl]</strike>
* <strike>Complete [[#Alternative_scenario:_moving_contained_resources| moving contained resources]] scenario with content from ericP on issue-30.</strike>
* <strike>Augment [[#Cloud_Infrastructure_Management| Cloud Infrastructure Management]] scenario with content from Roger Menday.</strike>
* <strike>Ensure issue-40/41 are fully covered in [[#UC8:_Managing_non-RDF_Resources| UC8: Managing non-RDF Resources]]. 2 scenarios (single v multiple attachments) ?</strike>
* <strike>Contact owner of [[#Data_Sharing| Data Sharing]] user-story to determine if we keep or not.</strike>
* <strike>Review [[#Requirements| Requirements]] section for functional/non-functional requirements arising in UCs.</strike>
* <strike>Propose resolutions to open issues against UC&R where possible.</strike>
* <strike>Identify and acknowledge user-story contributors.</strike>
* <strike>Check hyperlinks</strike>
* Convert to ReSpec
* Annotate document with open issues against UC&R
** <strike>[http://www.w3.org/2012/ldp/track/issues/30 ISSUE-30] (OPEN)</strike>
** [http://www.w3.org/2012/ldp/track/issues/40 ISSUE-40] (PENDING REVIEW)
** [http://www.w3.org/2012/ldp/track/issues/41 ISSUE-41] (PENDING REVIEW)

=== Process to introduce new User Stories & Use Cases ===

Open an Issue in the tracker against the UC&R product. The WG will review these and decide whether they are valid.

== Scope and Motivation ==

Linked Data was defined by Tim Berners-Lee with the following guidelines [http://www.w3.org/DesignIssues/LinkedData.html]:

# Use URIs as names for things
# Use HTTP URIs so that people can look up those names
# When someone looks up a URI, provide useful information, using the standards (RDF*, SPARQL)
# Include links to other URIs. so that they can discover more things

These four rules have proven very effective in guiding and inspiring people to publish Linked Data on the web. The amount of data, especially public data, available on the web has grown rapidly, and an impressive number of extremely creative and useful “mashups” have been created using this data as result.

There has been much less focus on the potential of Linked Data as a model for managing data on the web - the majority of the Application Programming Interfaces (APIs) available on the Internet for creating and updating data follow a Remote Procedure Call (RPC) model rather than a Linked Data model.

If Linked Data were just another model for doing something that RPC models can already do, it would be of only marginal interest. Interest in Linked Data arises from the fact that applications with an interface defined using Linked Data can be much more easily and seamlessly integrated with each other than applications that offer an RPC interface. In many problem domains, the most important problems and the greatest value are found not in the implementation of new applications, but in the successful integration of multiple applications into larger systems.

Some of the features that make Linked Data exceptionally well suited for integration include:

* A single interface – defined by a common set of HTTP methods – that is universally understood and is constant across all applications. This is in contrast with the RPC architecture where each application has a unique interface that has to be learned and coded to.
* A universal addressing scheme – provided by HTTP URLs – for both identifying and accessing all “entities”. This is in contrast with the RPC architecture where there is no uniform way to either identify or access data.
* A simple yet extensible data model – provided by RDF – for describing data about a resource in a way which doesn’t require prior knowledge of vocabulary being used.

Experience implementing applications and integrating them using Linked Data has shown very promising results, but has also demonstrated that the original four rules defined by Tim Berners-Lee for Linked Data are not sufficient to guide and constrain a writable Linked Data API. As was the case with the original four rules, the need generally is not for the invention of fundamental new technologies, but rather for a series of additional rules and patterns that guide and constrain the use of existing technologies in the construction of a Basic Profile for Linked Data to achieve interoperability.

The following list illustrates a few of the issues that require additional rules and patterns:
* What URLs do I post to in order to create new resources?
* How do I get lists of existing resources, and how do I get basic information about them without having to access each one?
* How should I detect and deal with race conditions on write?
* What media-types/representations should I use?
* What standard vocabularies should I use?
* What primitive data types should I use?

A good goal for the Basic Profile for Linked Data would be to define a specification required to allow the definition of a writable Linked Data API equivalent to the simple application APIs that are often written on the web today using the Atom Publishing Protocol (APP). APP shares some characteristics with Linked Data, such as the use of HTTP and URLs. One difference is that Linked Data relies on a flexible data model with RDF, which allows for multiple representations.

== Organization of this Document ==

This document is organized as follows:

* '''[[#User Stories| User Stories]]''' capture statements about system requirements written from a user or application perspective. They are typically lightweight and informal and can run from one line to a paragraph or two (sometimes described as an 'epic') [http://www.agilemodeling.com/artifacts/userStory.htm]. Analysis of each user story will reveal a number of (functional) use-cases and other non-functional requirements. See [http://www.w3.org/TR/dap-policy-reqs/| Device API Access Control Use Cases and Requirements] for a good example of user stories and their analysis.

* '''[[#Use Cases| Use Cases]]''' are used to capture and model functional requirements. Use cases describe the system’s behavior under various conditions [http://alistair.cockburn.us/get/2465], cataloguing who does what with the system, for what purpose, but without concern for system design or implementation [http://www.bredemeyer.com/pdf_files/functreq.pdf]. Each use case is identified by a reference number to aid cross-reference from other documentation; use-case indexing in this document is based on [http://www.w3.org/TR/rdb2rdf-ucr/ rdb2rdf use-cases]. A variety of styles may be used to capture use-cases, from a simple narrative to a structured description with actors, pre/post conditions, and step-by-step behaviours as in [http://www.w3.org/TR/powder-use-cases/ POWDER: Use Cases and Requirements], and non-functional requirements raised by the use-case. Use cases act like the hub of a wheel, with spokes supporting requirements analysis, scenario-based evaluation, testing, and integration with non-functional, or quality requirements.

* '''Scenarios''' are more focused still, representing a single instance of a use case in action. Scenarios may range from lightweight narratives as seen in [http://www.w3.org/TR/media-frags-reqs/ Use cases and requirements for Media Fragments], to being formally modeled as interaction diagrams. Each use-case should include at least a primary scenario, and possibly other alternative scenarios.

* '''[[#Requirements| Requirements]]''' list non-functional or quality requirements, and the use cases they may be derived from. This approach is exemplified in the [http://dvcs.w3.org/hg/gld/raw-file/default/dcat-ucr/index.html Use Cases and Requirements for the Data Catalog Vocabulary].

== User Stories ==

=== Maintaining Social Contact Information ===

Many of us have multiple email accounts that include information about the people and organizations we interact with – names, email addresses, telephone numbers, instant messenger identities and so on. When someone’s email address or telephone number changes (or they acquire a new one), our lives would be much simpler if we could update that information in one spot and all copies of it would automatically be updated. In other words, those copies would all be linked to some definition of “the contact.” There might also be good reasons (like off-line email addressing) to maintain a local copy of the contact, but ideally any copies would still be linked to some central “master.”

Agreeing on a format for “the contact” is not enough, however. Even if all our email providers agreed on the format of a contact, we would still need to use each provider’s custom interface to update or replace the provider’s copy, or we would have to agree on a way for each email provider to link to the “master”. If we look outside our own personal interests, it would be even more useful if the person or organization exposed their own contact information so we could link to it.

What would work in either case is a common understanding of the resource, a few formats needed, and access guidance for these resources. This would support how to acquire a link to a contact, and how to use those links to interact with a contact (including [[#UC3: Retrieve resource description|reading]], [[#UC4: Update existing resource|updating]], and [[#Alternative scenario: delete resource|deleting]] it), as well as how to easily [[#Primary scenario: create resource|create a new contact]] and add it to my contacts and when deleting a contact, how it would be removed from my list of contacts. It would also be good to be able to add some application-specific data about my contacts that the original design didn’t consider. Ideally we’d like to eliminate multiple copies of contacts, there would be additional valuable information about my contacts that may be stored on separate servers and need a simple way to link this information back to the contacts. Regardless of whether a contact collection is my own, shared by an organization, or all contacts known to an email provider (or to a single email account at an email provider), it would be nice if they all worked pretty much the same way.

=== Keeping Track of Personal and Business Relationships ===

In our daily lives, we deal with many different organizations in many different relationships, and they each have data about us. However, it is unlikely that any one organization has all the information about us. Each of them typically gives us access to the information (at least some of it), many through websites where we are uniquely identified by some string – an account number, user ID, and so on. We have to use their applications to interact with the data about us, however, and we have to use their identifier(s) for us. If we want to build any semblance of a holistic picture of ourselves (more accurately, collect all the data about us that they externalize), we as humans must use their custom applications to find the data, copy it, and organize it to suit our needs.

Would it not be simpler if at least the Web-addressable portion of that data could be linked to consistently, so that instead of maintaining various identifiers in different formats and instead of having to manually supply those identifiers to each one’s corresponding custom application, we could essentially build a set of bookmarks to it all? When we want to [[#UC3: Retrieve resource description|examine]] or [[#UC4: Update existing resource|change]] their contents, would it not be simpler if there were a single consistent application interface that they all supported? Of course it would.

Our set of links would probably be a [[#UC6: Aggregate resources|simple collection]]. The information held by any single organization might be a mix of simple data and [[#UC6: Aggregate resources|collections of other data]], for example, a bank account balance and a collection of historical transactions. Our bank might easily have [[#Alternative scenario: create a nested container|a collection of accounts for each of its collection of customers]].

=== System and Software Development Tool Integration ===

System and software development tools typically come from a diverse set of vendors and are built on various architectures and technologies. These tools are purpose built to meet the needs for a specific domain scenario (modeling, design, requirements and so on.) Often tool vendors view integrations with other tools as a necessary evil rather than providing additional value to their end-users. Even more of an afterthought is how these tools’ data -- such as people, projects, customer-reported problems and needs -- integrate and relate to corporate and external applications that manage data such as customers, business priorities and market trends. The problem can be isolated by standardizing on a small set of tools or a set of tools from a single vendor, but this rarely occurs and if does it usually does so only within small organizations. As these organizations grow both in size and complexity, they have needs to work with outsourced development and diverse internal other organizations with their own set of tools and processes. There is a need for better support of more complete business processes (system and software development processes) that span the roles, tasks, and data addressed by multiple tools. This demand has existed for many years, and the tools vendor industry has tried several different architectural approaches to address the problem. Here are a few:

* Implement an API for each application, and then, in each application, implement “glue code” that exploits the APIs of other applications to link them together.
* Design a single database to store the data of multiple applications, and implement each of the applications against this database. In the software development tools business, these databases are often called “repositories.”
* Implement a central “hub” or “bus” that orchestrates the broader business process by exploiting the APIs described previously.

It is fair to say that although each of those approaches has its adherents and can point to some successes, none of them is wholly satisfactory. The use of Linked Data as an application integration technology has a strong appeal. [http://open-services.net/ OSLC]

=== Library Linked Data ===

The W3C Library Linked Data working group has a number of use cases cited in their Use Case Report. [http://www.w3.org/2005/Incubator/lld/wiki/UseCaseReport LLD-UC] These referenced use cases focus on the need to extract and correlate library data from disparate sources. Variants of these use cases that can provide consistent formats, as well as ways to improve or update the data, would enable simplified methods for both efficiently sharing this data as well as producing incremental updates without the need for repeated full extractions and import of data.

The 'Digital Objects Cluster' contains a number of relevant use-cases:

* Grouping: This should "Allow the end-users to define [[#UC6: Aggregate resources|groups of resources]] on the web that for some reason belong together. The relationship that exists between the resources is often left unspecified. Some of the resources in a group may not be under control of the institution that defines the groups."

* Enrichment: "Enable end-users to [[#UC4: Update existing resource|link resources together]]."

* Browsing: "[[#UC7: Filter resource description|Support end-user browsing through groups]] and resources that belong to the groups."

* Re-use: "Users should have the capability to re-use all or parts of a collection, with all or part of its metadata, elsewhere on the linked Web."

The 'Collections' cluster also contains a number of relevant use-cases:

* Collection-level description: "Provide [[#UC7: Filter resource description|metadata pertaining to a collection as a whole]], in contrast to item-level description."

* Collections discovery: "Enable innovative collection discovery such as identification of nearest location of a physical collection where a specific information resource is found or mobile device applications ... based on collection-level descriptions."

* Community information services: Identify and classify collections of special interest to the community.

=== Municipality Operational Monitoring ===

Across various cities, towns, counties, and various municipalities there is a growing number of services managed and run by municipalities that produce and consume a vast amount of information. This information is used to help monitor services, predict problems, and handle logistics. In order to effectively and efficiently collect, produce, and analyze all this data, a fundamental set of loosely coupled standard data sources are needed. A simple, low-cost way to [[#UC3: Retrieve resource description|expose data]] from the diverse set of monitored services is needed, one that can easily integrate into the municipalities of other systems that inspect and analyze the data. All these services have links and dependencies on other data and services, so having a simple and scalable linking model is key.

=== Healthcare ===

For physicians to analyze, diagnose, and propose treatment for patients requires a vast amount of complex, changing and growing knowledge. This knowledge needs to come from a number of sources, including physicians’ own subject knowledge, consultation with their network of other healthcare professionals, public health sources, food and drug regulators, and other repositories of medical research and recommendations.

To diagnose a patient’s condition requires current data on the patient’s medications and medical history. In addition, recent pharmaceutical advisories about these medications are linked into the patient’s data. If the patient experiences adverse affects from medications, these physicians need to publish information about this to an appropriate regulatory source. Other medical professionals require access to both validated and emerging effects of the medication. Similarly, if there are geographical patterns around outbreaks that allow both the awareness of new symptoms and treatments, this information needs to quickly reach a very distributed and diverse set of medical information systems. Also, reporting back to these regulatory agencies regarding new occurrences of an outbreak, including additional details of symptoms and causes, is critical in producing the most effective treatment for future incidents.

=== Metadata Enrichment in Broadcasting ===

There are many different use cases when broadcasters show interest in metadata [[#UC4: Update existing resource| enrichment]]:

* enrich archive or news metadata by linking facts, events, locations and personalities
* enrich metadata generated by automatic extraction tools such as person identification, etc.
* enrich definitions of terms in classification schemes or enumeration lists

This comes in support of more effective information management and data/content mining (if you can't find your content, it' like if you don't have and must either recreate or acquire it again, which is not financially effective).

However, there is a need for solutions facilitating linkage to other data sources and taking care of the issues such as discovery, automation, disambiguation. Etc. Other important issues that broadcasters would face are the editorial quality of the linked data, its persistence, and usage rights.

=== Aggregation and Mashups of Infrastructure Data ===

For infrastructure management (such as storage systems, virtual machine environments, and similar IaaS and PaaS concepts), it is important to provide an environment in which information from different sources can be [[#UC6: Aggregate resources|aggregated]], [[#UC7: Filter resource description|filtered]], and visualized effectively. Specifically, the following use cases need to be taken into account:

* While some data sources are based on Linked Data, others are not, and aggregation and mashups must work across these different sources.
* Consumers of the data sources and aggregated/filtered data streams are not necessarily implementing Linked Data themselves, they may be off-the-shelf components such as dashboard frameworks for composing visualizations.
* Simple versions of this scenario are pull-based, where the data is requested from data sources. In more advanced settings, without a major change in architecture it should be possible to move to a push-based interaction model, where data sources push notifications to subscribers, and data sources provide different services that consumers can subscribe to (such as "informational messages" or "critical alerts only").

In this scenario, the important factors are to have abstractions that allow easy aggregation and filtering, are independent from the internal data model of the sources that are being combined, and can be used for pull-based interactions as well as for push-based interactions.

=== Sharing payload of RDF data among low-end devices ===

Several projects around the idea of [http://worldwidesemanticweb.wordpress.com/ downscaling the Semantic Web] need to be able to ship payloads of RDF across the nodes member of a given network. The transfers are done in a constrained context in terms of bandwidth, scope of the local semantics employed by the nodes and computing capabilities of the nodes. In a P2P style, every node has the capability to act either as a data consumer or a data provider, serving its own data or acting as a relay to pass other's data along (typically in mesh networks).

The transfer of an arbitrary payload of RDF data could be implemented through the container mechanism, adding and removing sets of RDF triples to it. Currently, one of the project "SemanticXO" uses named graphs and the graph protocol to create/delete/copy graphs across the nodes but this (almost) imposes the usage of a triple store. Unfortunately, triple store are rather demanding piece of software that are not always usable on limited hardware. Some generic ReST like interaction backed up with a lightweight column store would be better approach.

=== Sharing Binary Resources and Metadata ===

When publishing datasets about stars one may want to publish links to the pictures in which those stars appear, and this may well require publishing the pictures themselves. Vice versa: when publishing a picture of space we need to know which telescope took the picture, which part of the sky it was pointing at, what filters were used, which identified stars are visible, who can read it, who can write to it, ...

If LinkedData contains information about resources that are most naturally expressed in non-rdf formats (be they binary such as pictures or videos, or human readable documents in XML formats), those non RDF formats should be just as easy to publish to the LinkedData server as the RDF relations that link those resources up. A LinkedData server should therefore allow publishing of non linked data resources too, and make it easy to publish and edit metadata about those resources.

The resource comes in two parts - the image and information about the image (which may in the image file but better external to it as it's more general). The information about the image is vital. It's a compound item of image data and other data (being application metadata about the image does not distinguish from the platform's point-of-view.

=== Data Catalogs ===

The Asset Description Metadata Schema ([http://joinup.ec.europa.eu/asset/adms/home ADMS]) provides the data model to describe semantic assets repositories contents, but this leaves many open challenges when building a federation of these repositories to serve the need of assets reuse. These include accessing and querying individual repositories and efficiently retrieving [[#UC5: Determine if a resource has changed| updated content]] without having to retrieve the whole content. Hence, we chose to build the integration solution capitalizing on the Data Warehousing integration approach. This allows us to cope with heterogeneity of sources technologies and to benefit from the optimized performance it offers, given that individual repositories do not usually change frequently. With Data Warehousing, the federation requires to:

* understand the data, i.e. understand their semantic descriptions, and other systems.
* seamlessly exchange the semantic assets metadata from different repositories
* keep itself up-to-date.

Repositories owners can maintain de-referenceable URIs for their repository description and contained assets in a Linked Data compatible manner. ADMS provides the necessary data model to enable meaningful exchange of data. However, This leaves the challenge of efficient access to the data not fully addressed.

Related: [http://spec.datacatalogs.org/ Data Catalog Schema and Protocol]

=== Constrained Devices and Networks ===

Information coming from resource constrained devices in the Web of Things ([http://en.wikipedia.org/wiki/Web_of_Things WoT]) has been identified as a major driver in many domains, from smart cities to environmental monitoring to real-time tracking. The amount of information produced by these devices is growing exponentially and needs to be accessed and integrated in a systematic, standardized and cost efficient way. By using the same standards as on the Web, integration with applications will be simplified and higher-level interactions among resource constrained devices, abstracting away heterogeneities, will become possible. Up-coming IoT/WoT standards such as [http://datatracker.ietf.org/wg/6lowpan/ 6LowPAN] - IPv6 for resource constrained devices - and the Constrained Application Protocol ([http://tools.ietf.org/html/draft-ietf-core-coap CoAP]), which provides a downscaled version of HTTP on top of UDP for the use on constrained devices, are already at a mature stage. The next step now is to support RESTful interfaces also on resource constrained devices, adhering to the Linked Data principles. Due to the limited resources available, both on the device and in the network (such as bandwidth, energy, memory) a solution based on SPARQL Update is at the current point in time considered not to be useful and/or feasible. An approach based on the [http://tools.ietf.org/html/draft-castellani-core-http-mapping HTTP-CoAP Mapping] would enable constrained devices to directly participate in a Linked Data-based environment.

=== Services Supporting the Process of Science ===
Many fields of science now include branches with in silico data-intensive methods, e.g. bioinformatics, astronomy. To support these new methods we look to move beyond the established platforms provided by scientific workflow systems to capture, assist, and preserve the complete lifecycle from record of the experiment, through local trusted sharing, analysis, dissemination (including publishing of experimental data "beyond the PDF"), and re-use.

* [[#UC6: Aggregate resources|Aggregations]], specifically ''Research Objects (ROs)'' that are exchanged between services and clients bringing together workflows, data sets, annotations, and provenance. We use an RDF model for this. While some aggregated contents are encoded using RDF and in increasing number are linked data sources, others are not; while some are stored locally "within" the RO, others are remote (in both cases this is often due to size of the resources or access policies).
* Services that are distributed and linked. Some may be centralising for e.g. publication, others may be local, e.g. per lab. We need lightweight services that can be simply and easily integrated into and scale across the wide variety of softwares and data used in science: we have adopted a RESTful approach where possible.
** Foundation services that collect and expose ROs for storage, modification, exploration, and reuse.
** Services that provide added-value to ROs such as seamless import/export from scientific workflow systems, automated stability evaluation, or recommendation (and therefore interact with the foundation services to retrieve/store/modify/ROs).

seeAlso: [http://www.wf4ever-project.org/ Wf4Ever]

=== Project Membership Information : Information Evolution ===

Information about people and projects changes as roles change, as organisations change
and as contact details change. Finding the current state of a project is important
in enabling people to contact the right person in the right role. It can also be
useful to look back and see who was performing what role in the past.

A use of a Linked Data Platform could be to give responsibility for managing
such information with the project team itself, not requiring updates to be
requested of a centralised website administrator.

This could be achieved with:

* Resource descriptions for each person and project
* A container resource to describe roles/membership in the project.

To retain the history of the project, the old version of a resources,
including container resources, should be retained so there is a need to address both specific items
and also have a notion of "current".

Access to information has two aspects:
* Access to the "current" state, regardless of the version of the resource description
* Access to historical state, via access to a specific version of the resource description

=== Cloud Infrastructure Management===

Cloud operators offer API support to provide customers with remote access for the management of Cloud infrastructure (IaaS). Infrastructure consists of Systems, Computers, Networks, Discs, etc. The overall structure can be seen as mostly hierarchical, (Cloud contains Systems, Systems contain Machines, etc), complemented with crossing links (e.g. multiple Machines connected to a Network).

The IaaS scenario makes specific requirements on lifecycle management and discovery, handling non-instant changes, history capture and query:

* Many aspects of Cloud infrastructure have associated lifecycle, e.g. a Computer can be transitioned between Running and Shutdown. This should be manageable through the API, which should include how a client discovers dynamic lifecycle options and thus help steering through an application.
* It is often the case that attaining a new lifecycle state is not instantaneous. Clients require a universal mechanism for monitoring such changes.
* A facility to retrieve all events in the lifecycle of a resource can be useful.
* Query provides the means to interrogate the resources behind the API, as well as finding new entry points into the application.

Infrastructure management may be viewed as the manipulation of the underlying graph of resources.

== Use Cases ==
The following use-cases are each derived from one or more of the user-stories above. These use-cases are explored in detail through the development of scenarios, each motivated by some key aspect exemplified by a single user-story. The examples they contain are included purely for illustrative purposes, and should not be interpreted normatively.

===UC1: Manage containers===
A number of user-stories introduce the idea of a ''container'' as a mechanism for creating and managing resources within the context of an application. Resources grouped together within the same container would typically belong to the same application. A container is identified by a URI so is a resource in its own right.
The properties of a container may also represent the ''affordances'' of that container, enabling clients to determine what other operations they can do on that container. These operations may include descriptions of application specific services that can be invoked by exchanging RDF documents.

* Provide "access guidance for ... resources" (affordances) (from user-story, [[#Maintaining Social Contact Information|Maintaining Social Contact Information]]).

====Primary scenario: create container====
Create a new container resource within the LDP server.
In [[#Services Supporting the Process of Science|Services supporting the process of science]], [http://wf4ever.github.com/ro-primer/ Research Objects] are semantically rich aggregations of resources that bring together data, methods and people in scientific investigations. A basic workflow research object will be created to aggegate [http://ceur-ws.org/Vol-903/paper-01.pdf scientific workflows] and the artefacts that result from this workflow. The research object begins life as an empty container into which workflows, datasets, results and other data will be added throughout the lifecycle of the project.

<nowiki>
@prefix ro: http://purl.org/wf4ever/ro#
@prefix dct: http://purl.org/dc/terms/
@prefix ore: http://www.openarchives.org/ore/

<> a ro:ResearchObject, ore:Aggregation ;
dct:created "2012-12-01"^^xsd:dateTime .
</nowiki>

====Alternative scenario: create a nested container====
The motivation for nested containers comes from the [[#System and Software Development Tool Integration| System and Software Development Tool Integration]] user-story. The OSLC Change Management vocabulary allows bug reports to have attachments referenced by the membership predicate <nowiki>oslc_cm:attachment</nowiki>. The 'top-level-container' contains issues, and each issue resource has its own container of attachment resources.

<nowiki>
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix oslc_cm: <http://open-services.net/ns/cm#>.
@prefix : <http://example.org/>.

:top-level-container rdfs:member :issue1234 .

:issue1234 a oslc_cm:ChangeRequest;
dcterms:identifier "1234";
dcterms:type "a bug";
dcterms:related :issue1235 ;
oslc_cm:attachments :attachments123.

:issue1235 a oslc_cm:ChangeRequest;
dcterms:title "a related bug".

:attachments a oslc_cm:AttachmentList;
oslc_cm:attachment :attachment324, :attachment251.
</nowiki>

===UC2: Manage resources===
This use-case addresses the managed lifecycle of a resource and is concerned with resource ''ownership''. The responsibility for managing resources belongs with their container.
For example, a container may accept a request from a client to make a new resource.
This use-case focuses on creation and deletion of resources in the context of a container, and the potential for transfer of ownership by moving resources between containers.
The ownership of a resource should always be clear; no resource managed in this way should ever be owned by more than one container.

Once a new resource has been created it should be identified by a URI. Clients may defer responsibility for establishing dereferenceable URIs to the container of their data.
The container is a natural choice for the endpoint for this interface as it will already have some application-specific knowledge about the contained resources.
While the LDP has ultimate control over resource naming, some applications may require more control over naming, perhaps to provide a more human-readable URI. An LDP server could support something like the [http://tools.ietf.org/html/rfc5023 Atom Publishing Protocol] slug header to convey a user defined naming 'hint'.

* Non-duplication of resources: "Eliminate multiple copies", representing resources in a single place (from [[#Maintaining Social Contact Information]]).
* Distribution of resources: Linked aata "may be stored on separate servers" (from [[#Maintaining Social Contact Information]]).
* Consistent, global naming: Resources should be "linked to consistently, ... instead of maintaining various identifiers in different formats" (from [[#Keeping Track of Personal and Business Relationships]]).

====Primary scenario: create resource====
Resources begin life by being created within a container. From user-story, [[#Maintaining Social Contact Information|Maintaining Social Contact Information]], It should be possible to "easily create a new contact and add it to my contacts." This suggests that resource creation is closely linked to the application context. The new resource is created in a container representing "my contacts." The lifecycle of the resource is linked to the lifecycle of it's container. So, for example, if "my contacts" is deleted then a user would also reasonably expect that all contacts within it would also be deleted.

Contact details are captured as an RDF description and it's properties, including "names, email addresses, telephone numbers, instant messenger identities and so on." The description may include non-standard RDF; "data about my contacts that the original design didn’t consider."
The following RDF could be used to describe contact information using the [http://www.foaf-project.org FOAF] vocabulary. A contact is represented here by a <nowiki>foaf:PersonalProfileDocument</nowiki> defining a resource that can be created and updated as a single-unit, even though it may describe ancillary resources, such as a <nowiki>foaf:Person</nowiki>, below.

<nowiki>
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

<> a foaf:PersonalProfileDocument;
foaf:PrimaryTopic [
a foaf:Person;
foaf:name "Timothy Berners-Lee";
foaf:title "Sir";
foaf:firstName "Timothy";
foaf:surname "Berners-Lee";
foaf:nick "TimBL", "timbl";
foaf:homepage <http://www.w3.org/People/Berners-Lee/>;
foaf:weblog <http://dig.csail.mit.edu/breadcrumbs/blog/4>;
foaf:mbox <mailto:timbl@w3.org>;
foaf:workplaceHomepage <http://www.w3.org/>.
]
</nowiki>

====Alternative scenario: delete resource====
Delete a resource and all it's properties. If the resource resides within a container it will be removed from that container, however other links to the deleted resource may be left as dangling references.
In the case where the resource is a container, the server may also delete any or all contained resources.
In normal practice, a deleted resource cannot be reinstated. There are however, edge-cases where limited undelete may be desirable.
Best practice states that "[http://www.w3.org/TR/cooluris/| Cool URIs don't change]", which implies that deleted URIs shouldn't be recycled.

====Alternative scenario: moving contained resources====
Many resources may have value beyond the life of their membership in a container. This implies methods to add references to revise container membership.
Cloning container members for use in other containers results in duplication of information and maintenance problems; web practice is to encourage the creation of one resource, which may be referenced as many places as necessary. A change of ownership may - or may not - imply a change of URI, depending upon the specific LDP naming policy. While assigning a new URI to a resource is discouraged [http://www.w3.org/DesignIssues/Architecture.html#HTTP], it is possible to indicate that a resource has moved with an appropriate HTTP response.

===UC3: Retrieve resource description===
Access the current description of a resource, containing properties of that resource and links to related resources. The representation may include descriptions of related resources that cannot be accessed directly.
Depending upon the application, an LDP may enrich the retrieved RDF with additional triples. Examples include adding incoming links, sameAs closure and type closure.
The HTTP response should also include versioning information (i.e. last update or entity tag) so that subsequent updates can ensure they are being applied to the correct version.

* Use standard vocabularies as appropriate to enable a "common understanding of the resource" (from [[#Maintaining Social Contact Information|Maintaining Social Contact Information]]).
* A "scalable linking model is key" (from [[#Municipality Operational Monitoring]]).

====Primary scenario====
The user-story [[#Project Membership Information : Information Evolution| Project Membership Information]] discusses the representation of information about people and projects. It calls for "Resource descriptions for each person and project" allowing project teams to review information held about these resources. The example below illustrates the kinds of information that might be held about organizational structures based on the [http://www.epimorphics.com Epimorphics] [http://www.epimorphics.com/public/vocabulary/org.html organizational ontology].

Note that the example below defines two resources (shown as separate sections below) that will be hosted on an LDP based at <nowiki>http://example.com/</nowiki>. The representations of these resources may include descriptions of related resources, such as <nowiki>http://www.w3.org/</nowiki>, that that fall under a different authority and therefore can't be served from the LDP at this location.

<nowiki>
@prefix org: <http://www.w3.org/ns/org#> .
@prefix owltime: <http://www.w3.org/2006/time> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@base <http://example.com/> .

<member1> a org:Membership ;
org:member <http://www.w3.org/People/Berners-Lee/card#i> ;
org:organization http://www.w3.org/> ;
org:role <director> ;
org:memberDuring [a owltime:Interval; owltime:hasBeginning [
owltime:inXSDDateTime "1994-10-01T00:00:00Z"^^xsd:dateTime]] .

<http://www.w3.org/> a org:FormalOrganization ;
skos:prefLabel "The World Wide Web Consortium"@en ;
skos:altLabel "W3C" .
</nowiki>

<nowiki>
@prefix org: <http://www.w3.org/ns/org#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@base <http://example.com/> .

<director> a org:Role ;
rdfs:label "Director" .
</nowiki>

====Alternative scenario: retrieve description of a non-document resource====
In many cases, the things that are of interest are not always the things that are resolvable. The example below demonstrates how a foaf profile may be used to distinguish between the person and the profile; the former being the topic of the latter. This begs the question as to what a client should do with such non-document resources. In this case the HTTP protocol requires that the fragment part be stripped off before requesting the URI from the server. The result is a resolvable URI for the profile.

<nowiki>
@base <http://www.w3.org/People/Berners-Lee/card>
@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@prefix dc: <http://purl.org/dc/elements/1.1/>.

<> a foaf:PersonalProfileDocument ;
dc:title "Tim Berners-Lee's FOAF file" ;
foaf:homepage <http://www.w3.org/People/Berners-Lee/> ;
foaf:primaryTopic <#i> .
</nowiki>

===UC4: Update existing resource===
Change the RDF description of a LDP resource, potentially removing or overwriting existing data. This allows applications to ''enrich'' the representation of a resource by addling additional links to other resources.

* Unrestricted vocabulary: It should be possible be "able to add ... application-specific data" to resources (from [[#Maintaining Social Contact Information]]).

====Primary scenario: enrichment====
This relates to user-story [[#Metadata Enrichment in Broadcasting| Metadata Enrichment in Broadcasting]] and is based on the [http://www.bbc.co.uk/ontologies/sport/ BBC Sports Ontology]. The ''resource-centric'' view of linked-data provides a natural granularity for substituting, or overwriting a resource and its data. The simplest kind of update would simply replace what is currently known about a resource with a new representation. There are two distinct resources in the example below; a sporting event and an associated award. The granularity of the LDP would allow a user to replace the information about the award without disturbing the information about the event.

<nowiki>
@prefix sport: <http://www.bbc.co.uk/ontologies/sport/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

:mens_sprint a sport:MultiStageCompetition;
rdfs:label "Men's Sprint";
sport:award <#gold_medal> .

<#gold_medal> a sport:Award .
</nowiki>

We can enrich the description as events unfold, linking to the winner of the gold medal by substituting the above description with the following.

<nowiki>
@prefix sport: <http://www.bbc.co.uk/ontologies/sport/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

:mens_sprint a sport:MultiStageCompetition;
rdfs:label "Men's Sprint";
sport:award <#gold_medal> .
<#gold_medal> a sport:Award;
sport:awarded_to [
a foaf:Agent ;
foaf:name "Chris Hoy" .
] .
</nowiki>

====Alternative scenario: selective update of a resource====
This relates to user-story [[#Data Catalogs|Data Catalogs]], based on the [http://vocab.deri.ie/dcat Data Catalog Vocabulary].
A catalogue is described by the following RDF model.

<nowiki>
@prefix dcat: <http://www.w3.org/ns/dcat#> .
@prefix dcterms: <http://purl.org/dc/terms/> .

:catalog a dcat:Catalog ;
dcat:dataset :dataset/001;
dcterms:issued "2012-12-11"^^xsd:date.
</nowiki>

A catalog may contain multiple datasets, so when linking to new datasets it would be simpler and preferable to selectively add just the new dataset links.
A Talis ''changeset'' [http://docs.api.talis.com/getting-started/changesets][http://www.w3.org/2009/12/rdf-ws/papers/ws07] could be used to add a new <nowiki>dc:title</nowiki> to the dataset. The following update would be directed to the catalogue to add an additional dataset.

<nowiki>
@prefix : <http://example.com/>.
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix cs: <http://purl.org/vocab/changeset/schema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.

<change1>
a cs:ChangeSet ;
cs:subjectOfChange :catalog ;
cs:createdDate "2012-01-01T00:00:00Z" ;
cs:changeReason "Update catalog datasets" ;
cs:addition [
a rdf:Statement ;
rdf:subject :catalog ;
rdf:predicate dcat:dataset ;
rdf:object :dataset/002 .
] .
</nowiki>

===UC5: Determine if a resource has changed===
It should be possible to retrieve versioning information about a resource (e.g. last modified or entity tag) without having to download a representation of the resource.
This information can then be compared with previous information held about that resource to determine if it has changed.
This versioning information can also be used in subsequent ''conditional'' requests to ensure they are only applied if the version is unchanged.

====Primary scenario====
Based on the user-story, [[#Constrained Devices and Networks| Constrained Devices and Networks]], an LDP could be configured to act as a proxy for a [http://tools.ietf.org/html/draft-ietf-core-coap CoAP] based [http://en.wikipedia.org/wiki/Web_of_Things Web of Things]. As an observer of CoAP resources, the LDP registers its interest so that it will be notified whenever the sensor reading changes. Clients of the LDP can interrogate the LDP to determine if the state has changed.

In this example, the information about a sensor and corresponding sensor readings can be represented as RDF resources. The first resource below, represents a sensor described using the [http://www.w3.org/2005/Incubator/ssn/ Semantic Sensor Network] ontology.
<nowiki>
@prefix : <http://example.com/energy-management/>.

<> a :MainsFrequencySensor;
rdfs:comment "Sense grid load based on mains frequency";
ssn:hasMeasurementCapability [
a :FrequencyMeasurementCapability;
ssn:hasMeasurementProperty <#property_1> .
] .
</nowiki>

The value of the sensor changes in real-time as measurements are taken. The LDP client can interrogate the resource below to determine if it has changed, ''without'' necessarily having to download the RDF representation. As different sensor properties are represented disjointly (separate RDF representations) they may change independently.

<nowiki>
@prefix : <http://example.com/energy-management/>.

<http://example.com/energy-management#property_1> :hasMeasurementPropertyValue <> .
<> a :FrequencyValue;
:hasQuantityValue "50"^^xsd:float.
</nowiki>

===UC6: Aggregate resources===
There is a requirement to be able to manage ''collections'' of resources. The concept of a collection overlaps with, but is distinct from that of a container. These collections are (weak) aggregations, unrelated to the lifecycle management of resources, and distinct from the ownership between a resource and its container. However, the composition of a container may be reflected as a collection to support navigation of the container and its contents. There is a need to be able to create collections by adding and deleting individual membership properties. Resources may belong to multiple collections, or to none.

* Resource descriptions are a "mix of simple data and collections" (from [[#Keeping Track of Personal and Business Relationships]]).
* Relative URIs: It should be possible to "ship payloads of RDF" for a collection as a whole without breaking internal links (from [[#Constrained Devices and Networks]]).

====Primary scenario: add a resource to a collection====
This example is from [[#Library Linked Data|Library Linked Data]] and [http://www.w3.org/2005/Incubator/lld/wiki/UseCaseReport LLD-UC], specifically [http://www.w3.org/2005/Incubator/lld/wiki/Use_Case_Subject_Search Subject Search].

There is an existing collection at <nowiki><http://example.com/concept-scheme/subject-heading></nowiki> that defines a collection of subject headings. This collection is defined as a skos:ConceptScheme and
the client wishes to insert a new concept into the scheme. which will be related to the collection via a <nowiki>skos:inScheme</nowiki> link. The new subject-heading, "outer space exploration", is not necessarily owned by a container. The following RDF would be added to the (item-level) description of the collection.

<nowiki>
@prefix scheme : <http://example.com/concept-scheme/>.
@prefix concept : <http://example.com/concept/>.

scheme:subject-heading a skos:ConceptScheme.

concept:Outer+space+Exploration skos:inScheme scheme:subject-heading.
</nowiki>

====Alternative scenario: add a resource to multiple collections====
Logically, a resource should not be owned by more than one container. however, it may be a member of multiple collections which define a weaker form of ''aggregation''. As this is simply a manipulation of the RDF description of a collection, it should be possible to add the same resource to multiple collections.

As a machine-readable collection of medical terms, the [http://www.ihtsdo.org| SNOMED] ontology is of key importance in [[#Healthcare | healthcare]]. SNOMED CT allows concepts with more than one parent that don't fall into a lattice.
In the example below, the same concept may fall under two different parent concepts.
The example uses skos:narrowerTransitive to elide intervening concepts.

<nowiki>
@prefix : <http://example.com/snomed/>.

:_119376003 a skos:Concept ;
skos:prefLabel "Tissue specimen"
skos:narrowerTransitive :TissueSpecimenFromHeart.

:_127462005 a skos:Concept ;
skos:prefLabel "Specimen from heart"
skos:narrowerTransitive :TissueSpecimenFromHeart.

:_128166000 a skos:Concept;
rdfs:label "Tissue specimen from heart".
</nowiki>

===UC7: Filter resource description===
This use-case extends the normal behaviour of retrieving an RDF description of a resource, by dynamically excluding specific (membership) properties.
For containers, it is often desirable to be able to read a collection, or item-level description that excludes the container membership.

====Primary scenario: retrieve collection-level description====
This scenario, based on [[#Library Linked Data| Library Linked Data]], uses the Dublin Core Metadata Initiative [http://dublincore.org/groups/collections/collection-application-profile/| Collection-Level] description.
A collection can refer to any aggregation of physical or digital items.
This scenario covers the case whereby a client can request a collection-level description as typified by the example below, without necessarily having to download a full listing of the items within the collection.

<nowiki>
@prefix rdf: <rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">.
@prefix dc: <http://purl.org/dc/elements/1.1/>.
@prefix : <http://example.org/bookshelf/>.
@prefix dcmitype: <http://purl.org/dc/dcmitype/>.
@prefix cld: <http://purl.org/cld/terms/>.
@prefix dcterms: <http://purl.org/dc/terms/>.

<> dc:type dcmitype:Collection ;
dc:title "Directory of organizations working with Linked Data" ;
dcterms:abstract "This is a directory of organisations specializing in Linked Data."
cld:isLocatedAt <http://dir.w3.org>
cld:isAccessedVia <http://dir.w3.org/rdf/2012/directory/directory-list.xhtml?construct>
</nowiki>

====Alternative scenario: retrieve item-level description of a collection====
This use-case scenario, also based on [[#Library Linked Data| Library Linked Data]], focuses on obtaining an item-level description of the resources aggregated by a collection.
The simplest scenario is where the members of a collection are returned within a single representation, so that a client can explore the data by following these links. Different applications may use different membership predicates to capture this aggregation. The example below uses <nowiki>rdfs:member</nowiki>, but many different membership predicates are in common use, including RDF Lists.
Item-level descriptions can be captured using the Functional Requirements for Bibliographic Records ([http://www.ifla.org/publications/functional-requirements-for-bibliographic-records FRBR]) [http://vocab.org/frbr/core.html ontology].

<nowiki>
@prefix frbr: <http://purl.org/vocab/frbr/core#>.

<> rdfs:member <#ebooks97>, <#ebooks21279>.

<#work97> a frbr:LiteraryWork;
dc:title "Flatland: a romance of many dimensions" ;
frbr:creator <#Abbott_Edwin>;
frbr:manifestation <ebook97>.

<#work21279> a frbr:LiteraryWork;
dc:title "2 B R 0 2 B" ;
frbr:creator <#Vonnegut_Kurt>;
frbr:manifestation <ebook21279>.
</nowiki>

Collections are potentially very large, so some means may be required to limit the size of RDF representation returned by the LDP (e.g. pagination).

===UC8: Manage media resources===
It should be possible to easily add non-RDF media resources to containers that accept them. Media resources may be updated and removed during the lifecycle of the container.

====Primary scenario: access media resources====
From the User Story [[#Sharing Binary Resources and Metadata| Sharing Binary Resources and Metadata]] it should be possible to easily add non RDF resources to a containers that accept them. Clients submit a non-RDF representation to a container in a media type accepted by that container. The container creates a URI to represent this media resource, and creates a link from the container to the new URI.The media resource may have an explicit representation of the media type. It should be possible to find the metadata about such a resource and to access and edit it in the usual ways.

This example uses the [http://www.w3.org/TR/mediaont-10/#ont-ttl Ontology for Media Resources] to describe a media resource added to a collection.
<nowiki>
@prefix ma: <http://www.w3.org/ns/ma-ont#> .

<dataset> a ma:Collection ;
:hasMember <dataset/image1.jpg>

<dataset/image1.jpg> a ma:MediaResource ;
ma:hasFormat "image/jpeg" .
</nowiki>

====Alternative scenario: media-resource attachments====
A resource may have multiple ''renditions''; the idea that you can have a PDF and a JPEG representing the same thing. A user is trying to create a work order along with an attached image showing a faulty machine part. To the user and to the work order system, these two artifacts are managed as a set. A single request may create the work order, the attachment, and the relationship between them, atomically.
When the user retrieves the work order later, they expect a single request by default to retrieve the work order plus all attachments.
When the user updates the work order, e.g. to mark it completed, they only want to update the work order proper, not its attachments.
Users may add/remove/replace attachments to the work order during its lifetime.

== Requirements ==

===Functional Requirements===
# Create Containers, from [[#UC1: Manage containers]]
# Creation of nested containers, from [[#UC1: Manage containers]]
# Creation of resources (within a container), from [[#UC2: Manage resources]]
# Deletion of resources, from [[#UC2: Manage resources]]
# Moving contained resources, from [[#UC2: Manage resources]]
# Retrieve resource description, from [[#UC3: Retrieve resource description]]
# Retrieve description of a non-document resource, from [[#UC3: Retrieve resource description]]
# Enrichment (substituting update of existing resource), from [[#UC4: Update existing resource]]
# Selective update of a resource, from [[#UC4: Update existing resource]]
# Determine if a resource has changed, from [[#UC5: Determine if a resource has changed]]
# Add a resource to a collection, from [[#UC6: Aggregate resources]]
# Add a resource to multiple collections, from [[#UC6: Aggregate resources]]
# Retrieve collection-level description, from [[#UC7: Filter resource description]]
# Retrieve item-level description of a collection, from [[#UC7: Filter resource description]]
# Access media resources, from [[#UC8: Manage media resources]]
# Media-resource attachments, from [[#UC8: Manage media resources]]

===Non-Functional Requirements===

# Provide access guidance to resources, from [[#UC1: Manage containers]]
# Non-duplication of resources, from [[#UC2: Manage resources]]
# Distribution of resources, from [[#UC2: Manage resources]]
# Consistent, global naming, from [[#UC2: Manage resources]]
# Use standard vocabularies as appropriate, from [[#UC3: Retrieve resource description]]
# Scalable linking model, from [[#UC3: Retrieve resource description]]
# Unrestricted vocabulary, from [[#UC4: Update existing resource]]
# Resource descriptions are a "mix of simple data and collections", from [[#UC6: Aggregate resources]]
# Relative URIs enabling sharing of collections, from [[#UC6: Aggregate resources]]

== Acknowledgements ==
We would like to acknowledge the contributions of user-story authors; Christophe Guéret, Roger Menday, Eric Prud'hommeaux, Steve Speicher.

== References ==

Use Cases And Requirements

Sbattle2 — Mon, 10 Dec 2012 17:25:39 GMT

Sbattle2: /* Steps to Complete */

= Linked Data Platform Use Cases And Requirements =

This is a working document used to collect use cases and requirements for consideration by the WG.
The starting point comes from [http://www.w3.org/Submission/2012/SUBM-ldbpucr-20120326/ Linked Data Basic Profile Use Cases and Requirements].

== Status of this Document ==

This document is currently under review pending release as a First Public Working Draft. While the editors have made their best effort to identify a set of use-cases that are both evidenced in user-stories and in-scope of the charter, the document may yet be missing some key unidentified use-cases, or indeed, may include use-cases that ought to be removed. Furthermore, the coarse grouping of use-cases to avoid CRUDdy operations may not be to people's taste and is open to challenge.

===Timetable===
* <strike>Nov 26? WG to confirm User Story content: add, remove, refine (see process below). Note: this is ONLY User Stories (not Use Cases, Use Case Scenarios or Requirements)</strike>
** Issues before Nov 26th? will be included into FPWD
* Editors to:
** <strike>Dec 3 refine User Stories based on feedback</strike>
** <strike>Dec 5 elaborate on Use Cases in support of User Stories</strike>
* Dec 10 - WG to review prior to FPWD
** Review period ends Dec 15th
** insert open issues into draft for FPWD
* Dec 17 - Publish FPWD
** convert wiki page to ReSpec for FPWD
* Dec ?? Deadline for publications by year end 2012

===To Be Done===
* <strike>Move [[#LDP_and_Authentication.2FAuthorization| LDP and Authentication]] to [http://www.w3.org/2012/ldp/wiki/AccessControl AccessControl]</strike>
* <strike>Complete [[#Alternative_scenario:_moving_contained_resources| moving contained resources]] scenario with content from ericP on issue-30.</strike>
* <strike>Augment [[#Cloud_Infrastructure_Management| Cloud Infrastructure Management]] scenario with content from Roger Menday.</strike>
* <strike>Ensure issue-40/41 are fully covered in [[#UC8:_Managing_non-RDF_Resources| UC8: Managing non-RDF Resources]]. 2 scenarios (single v multiple attachments) ?</strike>
* <strike>Contact owner of [[#Data_Sharing| Data Sharing]] user-story to determine if we keep or not.</strike>
* <strike>Review [[#Requirements| Requirements]] section for functional/non-functional requirements arising in UCs.</strike>
* <strike>Propose resolutions to open issues against UC&R where possible.</strike>
* <strike>Identify and acknowledge user-story contributors.</strike>
* <strike>Check hyperlinks</strike>
* Convert to ReSpec
* Annotate document with open issues against UC&R
** <strike>[http://www.w3.org/2012/ldp/track/issues/30 ISSUE-30] (OPEN)</strike>
** [http://www.w3.org/2012/ldp/track/issues/40 ISSUE-40] (PENDING REVIEW)
** [http://www.w3.org/2012/ldp/track/issues/41 ISSUE-41] (PENDING REVIEW)

=== Process to introduce new User Stories & Use Cases ===

Open an Issue in the tracker against the UC&R product. The WG will review these and decide whether they are valid.

== Scope and Motivation ==

Linked Data was defined by Tim Berners-Lee with the following guidelines [http://www.w3.org/DesignIssues/LinkedData.html]:

# Use URIs as names for things
# Use HTTP URIs so that people can look up those names
# When someone looks up a URI, provide useful information, using the standards (RDF*, SPARQL)
# Include links to other URIs. so that they can discover more things

These four rules have proven very effective in guiding and inspiring people to publish Linked Data on the web. The amount of data, especially public data, available on the web has grown rapidly, and an impressive number of extremely creative and useful “mashups” have been created using this data as result.

There has been much less focus on the potential of Linked Data as a model for managing data on the web - the majority of the Application Programming Interfaces (APIs) available on the Internet for creating and updating data follow a Remote Procedure Call (RPC) model rather than a Linked Data model.

If Linked Data were just another model for doing something that RPC models can already do, it would be of only marginal interest. Interest in Linked Data arises from the fact that applications with an interface defined using Linked Data can be much more easily and seamlessly integrated with each other than applications that offer an RPC interface. In many problem domains, the most important problems and the greatest value are found not in the implementation of new applications, but in the successful integration of multiple applications into larger systems.

Some of the features that make Linked Data exceptionally well suited for integration include:

* A single interface – defined by a common set of HTTP methods – that is universally understood and is constant across all applications. This is in contrast with the RPC architecture where each application has a unique interface that has to be learned and coded to.
* A universal addressing scheme – provided by HTTP URLs – for both identifying and accessing all “entities”. This is in contrast with the RPC architecture where there is no uniform way to either identify or access data.
* A simple yet extensible data model – provided by RDF – for describing data about a resource in a way which doesn’t require prior knowledge of vocabulary being used.

Experience implementing applications and integrating them using Linked Data has shown very promising results, but has also demonstrated that the original four rules defined by Tim Berners-Lee for Linked Data are not sufficient to guide and constrain a writable Linked Data API. As was the case with the original four rules, the need generally is not for the invention of fundamental new technologies, but rather for a series of additional rules and patterns that guide and constrain the use of existing technologies in the construction of a Basic Profile for Linked Data to achieve interoperability.

The following list illustrates a few of the issues that require additional rules and patterns:
* What URLs do I post to in order to create new resources?
* How do I get lists of existing resources, and how do I get basic information about them without having to access each one?
* How should I detect and deal with race conditions on write?
* What media-types/representations should I use?
* What standard vocabularies should I use?
* What primitive data types should I use?

A good goal for the Basic Profile for Linked Data would be to define a specification required to allow the definition of a writable Linked Data API equivalent to the simple application APIs that are often written on the web today using the Atom Publishing Protocol (APP). APP shares some characteristics with Linked Data, such as the use of HTTP and URLs. One difference is that Linked Data relies on a flexible data model with RDF, which allows for multiple representations.

== Organization of this Document ==

This document is organized as follows:

* '''[[#User Stories| User Stories]]''' capture statements about system requirements written from a user or application perspective. They are typically lightweight and informal and can run from one line to a paragraph or two (sometimes described as an 'epic') [http://www.agilemodeling.com/artifacts/userStory.htm]. Analysis of each user story will reveal a number of (functional) use-cases and other non-functional requirements. See [http://www.w3.org/TR/dap-policy-reqs/| Device API Access Control Use Cases and Requirements] for a good example of user stories and their analysis.

* '''[[#Use Cases| Use Cases]]''' are used to capture and model functional requirements. Use cases describe the system’s behavior under various conditions [http://alistair.cockburn.us/get/2465], cataloguing who does what with the system, for what purpose, but without concern for system design or implementation [http://www.bredemeyer.com/pdf_files/functreq.pdf]. Each use case is identified by a reference number to aid cross-reference from other documentation; use-case indexing in this document is based on [http://www.w3.org/TR/rdb2rdf-ucr/ rdb2rdf use-cases]. A variety of styles may be used to capture use-cases, from a simple narrative to a structured description with actors, pre/post conditions, and step-by-step behaviours as in [http://www.w3.org/TR/powder-use-cases/ POWDER: Use Cases and Requirements], and non-functional requirements raised by the use-case. Use cases act like the hub of a wheel, with spokes supporting requirements analysis, scenario-based evaluation, testing, and integration with non-functional, or quality requirements.

* '''Scenarios''' are more focused still, representing a single instance of a use case in action. Scenarios may range from lightweight narratives as seen in [http://www.w3.org/TR/media-frags-reqs/ Use cases and requirements for Media Fragments], to being formally modeled as interaction diagrams. Each use-case should include at least a primary scenario, and possibly other alternative scenarios.

* '''[[#Requirements| Requirements]]''' list non-functional or quality requirements, and the use cases they may be derived from. This approach is exemplified in the [http://dvcs.w3.org/hg/gld/raw-file/default/dcat-ucr/index.html Use Cases and Requirements for the Data Catalog Vocabulary].

== User Stories ==

=== Maintaining Social Contact Information ===

Many of us have multiple email accounts that include information about the people and organizations we interact with – names, email addresses, telephone numbers, instant messenger identities and so on. When someone’s email address or telephone number changes (or they acquire a new one), our lives would be much simpler if we could update that information in one spot and all copies of it would automatically be updated. In other words, those copies would all be linked to some definition of “the contact.” There might also be good reasons (like off-line email addressing) to maintain a local copy of the contact, but ideally any copies would still be linked to some central “master.”

Agreeing on a format for “the contact” is not enough, however. Even if all our email providers agreed on the format of a contact, we would still need to use each provider’s custom interface to update or replace the provider’s copy, or we would have to agree on a way for each email provider to link to the “master”. If we look outside our own personal interests, it would be even more useful if the person or organization exposed their own contact information so we could link to it.

What would work in either case is a common understanding of the resource, a few formats needed, and access guidance for these resources. This would support how to acquire a link to a contact, and how to use those links to interact with a contact (including [[#UC3: Retrieve resource description|reading]], [[#UC4: Update existing resource|updating]], and [[#Alternative scenario: delete resource|deleting]] it), as well as how to easily [[#Primary scenario: create resource|create a new contact]] and add it to my contacts and when deleting a contact, how it would be removed from my list of contacts. It would also be good to be able to add some application-specific data about my contacts that the original design didn’t consider. Ideally we’d like to eliminate multiple copies of contacts, there would be additional valuable information about my contacts that may be stored on separate servers and need a simple way to link this information back to the contacts. Regardless of whether a contact collection is my own, shared by an organization, or all contacts known to an email provider (or to a single email account at an email provider), it would be nice if they all worked pretty much the same way.

=== Keeping Track of Personal and Business Relationships ===

In our daily lives, we deal with many different organizations in many different relationships, and they each have data about us. However, it is unlikely that any one organization has all the information about us. Each of them typically gives us access to the information (at least some of it), many through websites where we are uniquely identified by some string – an account number, user ID, and so on. We have to use their applications to interact with the data about us, however, and we have to use their identifier(s) for us. If we want to build any semblance of a holistic picture of ourselves (more accurately, collect all the data about us that they externalize), we as humans must use their custom applications to find the data, copy it, and organize it to suit our needs.

Would it not be simpler if at least the Web-addressable portion of that data could be linked to consistently, so that instead of maintaining various identifiers in different formats and instead of having to manually supply those identifiers to each one’s corresponding custom application, we could essentially build a set of bookmarks to it all? When we want to [[#UC3: Retrieve resource description|examine]] or [[#UC4: Update existing resource|change]] their contents, would it not be simpler if there were a single consistent application interface that they all supported? Of course it would.

Our set of links would probably be a [[#UC6: Aggregate resources|simple collection]]. The information held by any single organization might be a mix of simple data and [[#UC6: Aggregate resources|collections of other data]], for example, a bank account balance and a collection of historical transactions. Our bank might easily have [[#Alternative scenario: create a nested container|a collection of accounts for each of its collection of customers]].

=== System and Software Development Tool Integration ===

System and software development tools typically come from a diverse set of vendors and are built on various architectures and technologies. These tools are purpose built to meet the needs for a specific domain scenario (modeling, design, requirements and so on.) Often tool vendors view integrations with other tools as a necessary evil rather than providing additional value to their end-users. Even more of an afterthought is how these tools’ data -- such as people, projects, customer-reported problems and needs -- integrate and relate to corporate and external applications that manage data such as customers, business priorities and market trends. The problem can be isolated by standardizing on a small set of tools or a set of tools from a single vendor, but this rarely occurs and if does it usually does so only within small organizations. As these organizations grow both in size and complexity, they have needs to work with outsourced development and diverse internal other organizations with their own set of tools and processes. There is a need for better support of more complete business processes (system and software development processes) that span the roles, tasks, and data addressed by multiple tools. This demand has existed for many years, and the tools vendor industry has tried several different architectural approaches to address the problem. Here are a few:

* Implement an API for each application, and then, in each application, implement “glue code” that exploits the APIs of other applications to link them together.
* Design a single database to store the data of multiple applications, and implement each of the applications against this database. In the software development tools business, these databases are often called “repositories.”
* Implement a central “hub” or “bus” that orchestrates the broader business process by exploiting the APIs described previously.

It is fair to say that although each of those approaches has its adherents and can point to some successes, none of them is wholly satisfactory. The use of Linked Data as an application integration technology has a strong appeal. [http://open-services.net/ OSLC]

=== Library Linked Data ===

The W3C Library Linked Data working group has a number of use cases cited in their Use Case Report. [http://www.w3.org/2005/Incubator/lld/wiki/UseCaseReport LLD-UC] These referenced use cases focus on the need to extract and correlate library data from disparate sources. Variants of these use cases that can provide consistent formats, as well as ways to improve or update the data, would enable simplified methods for both efficiently sharing this data as well as producing incremental updates without the need for repeated full extractions and import of data.

The 'Digital Objects Cluster' contains a number of relevant use-cases:

* Grouping: This should "Allow the end-users to define [[#UC6: Aggregate resources|groups of resources]] on the web that for some reason belong together. The relationship that exists between the resources is often left unspecified. Some of the resources in a group may not be under control of the institution that defines the groups."

* Enrichment: "Enable end-users to [[#UC4: Update existing resource|link resources together]]."

* Browsing: "[[#UC7: Filter resource description|Support end-user browsing through groups]] and resources that belong to the groups."

* Re-use: "Users should have the capability to re-use all or parts of a collection, with all or part of its metadata, elsewhere on the linked Web."

The 'Collections' cluster also contains a number of relevant use-cases:

* Collection-level description: "Provide [[#UC7: Filter resource description|metadata pertaining to a collection as a whole]], in contrast to item-level description."

* Collections discovery: "Enable innovative collection discovery such as identification of nearest location of a physical collection where a specific information resource is found or mobile device applications ... based on collection-level descriptions."

* Community information services: Identify and classify collections of special interest to the community.

=== Municipality Operational Monitoring ===

Across various cities, towns, counties, and various municipalities there is a growing number of services managed and run by municipalities that produce and consume a vast amount of information. This information is used to help monitor services, predict problems, and handle logistics. In order to effectively and efficiently collect, produce, and analyze all this data, a fundamental set of loosely coupled standard data sources are needed. A simple, low-cost way to [[#UC3: Retrieve resource description|expose data]] from the diverse set of monitored services is needed, one that can easily integrate into the municipalities of other systems that inspect and analyze the data. All these services have links and dependencies on other data and services, so having a simple and scalable linking model is key.

=== Healthcare ===

For physicians to analyze, diagnose, and propose treatment for patients requires a vast amount of complex, changing and growing knowledge. This knowledge needs to come from a number of sources, including physicians’ own subject knowledge, consultation with their network of other healthcare professionals, public health sources, food and drug regulators, and other repositories of medical research and recommendations.

To diagnose a patient’s condition requires current data on the patient’s medications and medical history. In addition, recent pharmaceutical advisories about these medications are linked into the patient’s data. If the patient experiences adverse affects from medications, these physicians need to publish information about this to an appropriate regulatory source. Other medical professionals require access to both validated and emerging effects of the medication. Similarly, if there are geographical patterns around outbreaks that allow both the awareness of new symptoms and treatments, this information needs to quickly reach a very distributed and diverse set of medical information systems. Also, reporting back to these regulatory agencies regarding new occurrences of an outbreak, including additional details of symptoms and causes, is critical in producing the most effective treatment for future incidents.

=== Metadata Enrichment in Broadcasting ===

There are many different use cases when broadcasters show interest in metadata [[#UC4: Update existing resource| enrichment]]:

* enrich archive or news metadata by linking facts, events, locations and personalities
* enrich metadata generated by automatic extraction tools such as person identification, etc.
* enrich definitions of terms in classification schemes or enumeration lists

This comes in support of more effective information management and data/content mining (if you can't find your content, it' like if you don't have and must either recreate or acquire it again, which is not financially effective).

However, there is a need for solutions facilitating linkage to other data sources and taking care of the issues such as discovery, automation, disambiguation. Etc. Other important issues that broadcasters would face are the editorial quality of the linked data, its persistence, and usage rights.

=== Aggregation and Mashups of Infrastructure Data ===

For infrastructure management (such as storage systems, virtual machine environments, and similar IaaS and PaaS concepts), it is important to provide an environment in which information from different sources can be [[#UC6: Aggregate resources|aggregated]], [[#UC7: Filter resource description|filtered]], and visualized effectively. Specifically, the following use cases need to be taken into account:

* While some data sources are based on Linked Data, others are not, and aggregation and mashups must work across these different sources.
* Consumers of the data sources and aggregated/filtered data streams are not necessarily implementing Linked Data themselves, they may be off-the-shelf components such as dashboard frameworks for composing visualizations.
* Simple versions of this scenario are pull-based, where the data is requested from data sources. In more advanced settings, without a major change in architecture it should be possible to move to a push-based interaction model, where data sources push notifications to subscribers, and data sources provide different services that consumers can subscribe to (such as "informational messages" or "critical alerts only").

In this scenario, the important factors are to have abstractions that allow easy aggregation and filtering, are independent from the internal data model of the sources that are being combined, and can be used for pull-based interactions as well as for push-based interactions.

=== Sharing payload of RDF data among low-end devices ===

Several projects around the idea of [http://worldwidesemanticweb.wordpress.com/ downscaling the Semantic Web] need to be able to ship payloads of RDF across the nodes member of a given network. The transfers are done in a constrained context in terms of bandwidth, scope of the local semantics employed by the nodes and computing capabilities of the nodes. In a P2P style, every node has the capability to act either as a data consumer or a data provider, serving its own data or acting as a relay to pass other's data along (typically in mesh networks).

The transfer of an arbitrary payload of RDF data could be implemented through the container mechanism, adding and removing sets of RDF triples to it. Currently, one of the project "SemanticXO" uses named graphs and the graph protocol to create/delete/copy graphs across the nodes but this (almost) imposes the usage of a triple store. Unfortunately, triple store are rather demanding piece of software that are not always usable on limited hardware. Some generic ReST like interaction backed up with a lightweight column store would be better approach.

=== Sharing Binary Resources and Metadata ===

When publishing datasets about stars one may want to publish links to the pictures in which those stars appear, and this may well require publishing the pictures themselves. Vice versa: when publishing a picture of space we need to know which telescope took the picture, which part of the sky it was pointing at, what filters were used, which identified stars are visible, who can read it, who can write to it, ...

If LinkedData contains information about resources that are most naturally expressed in non-rdf formats (be they binary such as pictures or videos, or human readable documents in XML formats), those non RDF formats should be just as easy to publish to the LinkedData server as the RDF relations that link those resources up. A LinkedData server should therefore allow publishing of non linked data resources too, and make it easy to publish and edit metadata about those resources.

The resource comes in two parts - the image and information about the image (which may in the image file but better external to it as it's more general). The information about the image is vital. It's a compound item of image data and other data (being application metadata about the image does not distinguish from the platform's point-of-view.

=== Data Catalogs ===

The Asset Description Metadata Schema ([http://joinup.ec.europa.eu/asset/adms/home ADMS]) provides the data model to describe semantic assets repositories contents, but this leaves many open challenges when building a federation of these repositories to serve the need of assets reuse. These include accessing and querying individual repositories and efficiently retrieving [[#UC5: Determine if a resource has changed| updated content]] without having to retrieve the whole content. Hence, we chose to build the integration solution capitalizing on the Data Warehousing integration approach. This allows us to cope with heterogeneity of sources technologies and to benefit from the optimized performance it offers, given that individual repositories do not usually change frequently. With Data Warehousing, the federation requires to:

* understand the data, i.e. understand their semantic descriptions, and other systems.
* seamlessly exchange the semantic assets metadata from different repositories
* keep itself up-to-date.

Repositories owners can maintain de-referenceable URIs for their repository description and contained assets in a Linked Data compatible manner. ADMS provides the necessary data model to enable meaningful exchange of data. However, This leaves the challenge of efficient access to the data not fully addressed.

Related: [http://spec.datacatalogs.org/ Data Catalog Schema and Protocol]

=== Constrained Devices and Networks ===

Information coming from resource constrained devices in the Web of Things ([http://en.wikipedia.org/wiki/Web_of_Things WoT]) has been identified as a major driver in many domains, from smart cities to environmental monitoring to real-time tracking. The amount of information produced by these devices is growing exponentially and needs to be accessed and integrated in a systematic, standardized and cost efficient way. By using the same standards as on the Web, integration with applications will be simplified and higher-level interactions among resource constrained devices, abstracting away heterogeneities, will become possible. Up-coming IoT/WoT standards such as [http://datatracker.ietf.org/wg/6lowpan/ 6LowPAN] - IPv6 for resource constrained devices - and the Constrained Application Protocol ([http://tools.ietf.org/html/draft-ietf-core-coap CoAP]), which provides a downscaled version of HTTP on top of UDP for the use on constrained devices, are already at a mature stage. The next step now is to support RESTful interfaces also on resource constrained devices, adhering to the Linked Data principles. Due to the limited resources available, both on the device and in the network (such as bandwidth, energy, memory) a solution based on SPARQL Update is at the current point in time considered not to be useful and/or feasible. An approach based on the [http://tools.ietf.org/html/draft-castellani-core-http-mapping HTTP-CoAP Mapping] would enable constrained devices to directly participate in a Linked Data-based environment.

=== Services Supporting the Process of Science ===
Many fields of science now include branches with in silico data-intensive methods, e.g. bioinformatics, astronomy. To support these new methods we look to move beyond the established platforms provided by scientific workflow systems to capture, assist, and preserve the complete lifecycle from record of the experiment, through local trusted sharing, analysis, dissemination (including publishing of experimental data "beyond the PDF"), and re-use.

* [[#UC6: Aggregate resources|Aggregations]], specifically ''Research Objects (ROs)'' that are exchanged between services and clients bringing together workflows, data sets, annotations, and provenance. We use an RDF model for this. While some aggregated contents are encoded using RDF and in increasing number are linked data sources, others are not; while some are stored locally "within" the RO, others are remote (in both cases this is often due to size of the resources or access policies).
* Services that are distributed and linked. Some may be centralising for e.g. publication, others may be local, e.g. per lab. We need lightweight services that can be simply and easily integrated into and scale across the wide variety of softwares and data used in science: we have adopted a RESTful approach where possible.
** Foundation services that collect and expose ROs for storage, modification, exploration, and reuse.
** Services that provide added-value to ROs such as seamless import/export from scientific workflow systems, automated stability evaluation, or recommendation (and therefore interact with the foundation services to retrieve/store/modify/ROs).

seeAlso: [http://www.wf4ever-project.org/ Wf4Ever]

=== Project Membership Information : Information Evolution ===

Information about people and projects changes as roles change, as organisations change
and as contact details change. Finding the current state of a project is important
in enabling people to contact the right person in the right role. It can also be
useful to look back and see who was performing what role in the past.

A use of a Linked Data Platform could be to give responsibility for managing
such information with the project team itself, not requiring updates to be
requested of a centralised website administrator.

This could be achieved with:

* Resource descriptions for each person and project
* A container resource to describe roles/membership in the project.

To retain the history of the project, the old version of a resources,
including container resources, should be retained so there is a need to address both specific items
and also have a notion of "current".

Access to information has two aspects:
* Access to the "current" state, regardless of the version of the resource description
* Access to historical state, via access to a specific version of the resource description

=== Cloud Infrastructure Management===

Cloud operators offer API support to provide customers with remote access for the management of Cloud infrastructure (IaaS). Infrastructure consists of Systems, Computers, Networks, Discs, etc. The overall structure can be seen as mostly hierarchical, (Cloud contains Systems, Systems contain Machines, etc), complemented with crossing links (e.g. multiple Machines connected to a Network).

The IaaS scenario makes specific requirements on lifecycle management and discovery, handling non-instant changes, history capture and query:

* Many aspects of Cloud infrastructure have associated lifecycle, e.g. a Computer can be transitioned between Running and Shutdown. This should be manageable through the API, which should include how a client discovers dynamic lifecycle options and thus help steering through an application.
* It is often the case that attaining a new lifecycle state is not instantaneous. Clients require a universal mechanism for monitoring such changes.
* A facility to retrieve all events in the lifecycle of a resource can be useful.
* Query provides the means to interrogate the resources behind the API, as well as finding new entry points into the application.

Infrastructure management may be viewed as the manipulation of the underlying graph of resources.

== Use Cases ==
The following use-cases are each derived from one or more of the user-stories above. These use-cases are explored in detail through the development of scenarios, each motivated by some key aspect exemplified by a single user-story. The examples they contain are included purely for illustrative purposes, and should not be interpreted normatively.

===UC1: Manage containers===
A number of user-stories introduce the idea of a ''container'' as a mechanism for creating and managing resources within the context of an application. Resources grouped together within the same container would typically belong to the same application. A container is identified by a URI so is a resource in its own right.
The properties of a container may also represent the ''affordances'' of that container, enabling clients to determine what other operations they can do on that container. These operations may include descriptions of application specific services that can be invoked by exchanging RDF documents.

* Provide "access guidance for ... resources" (affordances) (from user-story, [[#Maintaining Social Contact Information|Maintaining Social Contact Information]]).

====Primary scenario: create container====
Create a new container resource within the LDP server.
In [[#Services Supporting the Process of Science|Services supporting the process of science]], [http://wf4ever.github.com/ro-primer/ Research Objects] are semantically rich aggregations of resources that bring together data, methods and people in scientific investigations. A basic workflow research object will be created to aggegate [http://ceur-ws.org/Vol-903/paper-01.pdf scientific workflows] and the artefacts that result from this workflow. The research object begins life as an empty container into which workflows, datasets, results and other data will be added throughout the lifecycle of the project.

<nowiki>
@prefix ro: http://purl.org/wf4ever/ro#
@prefix dct: http://purl.org/dc/terms/
@prefix ore: http://www.openarchives.org/ore/

<> a ro:ResearchObject, ore:Aggregation ;
dct:created "2012-12-01"^^xsd:dateTime .
</nowiki>

====Alternative scenario: create a nested container====
The motivation for nested containers comes from the [[#System and Software Development Tool Integration| System and Software Development Tool Integration]] user-story. The OSLC Change Management vocabulary allows bug reports to have attachments referenced by the membership predicate <nowiki>oslc_cm:attachment</nowiki>. The 'top-level-container' contains issues, and each issue resource has its own container of attachment resources.

<nowiki>
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix oslc_cm: <http://open-services.net/ns/cm#>.
@prefix : <http://example.org/>.

:top-level-container rdfs:member :issue1234 .

:issue1234 a oslc_cm:ChangeRequest;
dcterms:identifier "1234";
dcterms:type "a bug";
dcterms:related :issue1235 ;
oslc_cm:attachments :attachments123.

:issue1235 a oslc_cm:ChangeRequest;
dcterms:title "a related bug".

:attachments a oslc_cm:AttachmentList;
oslc_cm:attachment :attachment324, :attachment251.
</nowiki>

===UC2: Manage resources===
This use-case addresses the managed lifecycle of a resource and is concerned with resource ''ownership''. The responsibility for managing resources belongs with their container.
For example, a container may accept a request from a client to make a new resource.
This use-case focuses on creation and deletion of resources in the context of a container, and the potential for transfer of ownership by moving resources between containers.
The ownership of a resource should always be clear; no resource managed in this way should ever be owned by more than one container.

Once a new resource has been created it should be identified by a URI. Clients may defer responsibility for establishing dereferenceable URIs to the container of their data.
The container is a natural choice for the endpoint for this interface as it will already have some application-specific knowledge about the contained resources.
While the LDP has ultimate control over resource naming, some applications may require more control over naming, perhaps to provide a more human-readable URI. An LDP server could support something like the [http://tools.ietf.org/html/rfc5023 Atom Publishing Protocol] slug header to convey a user defined naming 'hint'.

* Non-duplication of resources: "Eliminate multiple copies", representing resources in a single place (from [[#Maintaining Social Contact Information]]).
* Distribution of resources: Linked aata "may be stored on separate servers" (from [[#Maintaining Social Contact Information]]).
* Consistent, global naming: Resources should be "linked to consistently, ... instead of maintaining various identifiers in different formats" (from [[#Keeping Track of Personal and Business Relationships]]).

====Primary scenario: create resource====
Resources begin life by being created within a container. From user-story, [[#Maintaining Social Contact Information|Maintaining Social Contact Information]], It should be possible to "easily create a new contact and add it to my contacts." This suggests that resource creation is closely linked to the application context. The new resource is created in a container representing "my contacts." The lifecycle of the resource is linked to the lifecycle of it's container. So, for example, if "my contacts" is deleted then a user would also reasonably expect that all contacts within it would also be deleted.

Contact details are captured as an RDF description and it's properties, including "names, email addresses, telephone numbers, instant messenger identities and so on." The description may include non-standard RDF; "data about my contacts that the original design didn’t consider."
The following RDF could be used to describe contact information using the [http://www.foaf-project.org FOAF] vocabulary. A contact is represented here by a <nowiki>foaf:PersonalProfileDocument</nowiki> defining a resource that can be created and updated as a single-unit, even though it may describe ancillary resources, such as a <nowiki>foaf:Person</nowiki>, below.

<nowiki>
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

<> a foaf:PersonalProfileDocument;
foaf:PrimaryTopic [
a foaf:Person;
foaf:name "Timothy Berners-Lee";
foaf:title "Sir";
foaf:firstName "Timothy";
foaf:surname "Berners-Lee";
foaf:nick "TimBL", "timbl";
foaf:homepage <http://www.w3.org/People/Berners-Lee/>;
foaf:weblog <http://dig.csail.mit.edu/breadcrumbs/blog/4>;
foaf:mbox <mailto:timbl@w3.org>;
foaf:workplaceHomepage <http://www.w3.org/>.
]
</nowiki>

====Alternative scenario: delete resource====
Delete a resource and all it's properties. If the resource resides within a container it will be removed from that container, however other links to the deleted resource may be left as dangling references.
In the case where the resource is a container, the server may also delete any or all contained resources.
In normal practice, a deleted resource cannot be reinstated. There are however, edge-cases where limited undelete may be desirable.
Best practice states that "[http://www.w3.org/TR/cooluris/| Cool URIs don't change]", which implies that deleted URIs shouldn't be recycled.

====Alternative scenario: moving contained resources====
Many resources may have value beyond the life of their membership in a container. This implies methods to add references to revise container membership.
Cloning container members for use in other containers results in duplication of information and maintenance problems; web practice is to encourage the creation of one resource, which may be referenced as many places as necessary. A change of ownership may - or may not - imply a change of URI, depending upon the specific LDP naming policy. While assigning a new URI to a resource is discouraged [http://www.w3.org/DesignIssues/Architecture.html#HTTP], it is possible to indicate that a resource has moved with an appropriate HTTP response.

===UC3: Retrieve resource description===
Access the current description of a resource, containing properties of that resource and links to related resources. The representation may include descriptions of related resources that cannot be accessed directly.
Depending upon the application, an LDP may enrich the retrieved RDF with additional triples. Examples include adding incoming links, sameAs closure and type closure.
The HTTP response should also include versioning information (i.e. last update or entity tag) so that subsequent updates can ensure they are being applied to the correct version.

* Use standard vocabularies as appropriate to enable a "common understanding of the resource" (from [[#Maintaining Social Contact Information|Maintaining Social Contact Information]]).
* A "scalable linking model is key" (from [[#Municipality Operational Monitoring]]).

====Primary scenario====
The user-story [[#Project Membership Information : Information Evolution| Project Membership Information]] discusses the representation of information about people and projects. It calls for "Resource descriptions for each person and project" allowing project teams to review information held about these resources. The example below illustrates the kinds of information that might be held about organizational structures based on the [http://www.epimorphics.com Epimorphics] [http://www.epimorphics.com/public/vocabulary/org.html organizational ontology].

Note that the example below defines two resources (shown as separate sections below) that will be hosted on an LDP based at <nowiki>http://example.com/</nowiki>. The representations of these resources may include descriptions of related resources, such as <nowiki>http://www.w3.org/</nowiki>, that that fall under a different authority and therefore can't be served from the LDP at this location.

<nowiki>
@prefix org: <http://www.w3.org/ns/org#> .
@prefix owltime: <http://www.w3.org/2006/time> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@base <http://example.com/> .

<member1> a org:Membership ;
org:member <http://www.w3.org/People/Berners-Lee/card#i> ;
org:organization http://www.w3.org/> ;
org:role <director> ;
org:memberDuring [a owltime:Interval; owltime:hasBeginning [
owltime:inXSDDateTime "1994-10-01T00:00:00Z"^^xsd:dateTime]] .

<http://www.w3.org/> a org:FormalOrganization ;
skos:prefLabel "The World Wide Web Consortium"@en ;
skos:altLabel "W3C" .
</nowiki>

<nowiki>
@prefix org: <http://www.w3.org/ns/org#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@base <http://example.com/> .

<director> a org:Role ;
rdfs:label "Director" .
</nowiki>

====Alternative scenario: retrieve description of a non-document resource====
In many cases, the things that are of interest are not always the things that are resolvable. The example below demonstrates how a foaf profile may be used to distinguish between the person and the profile; the former being the topic of the latter. This begs the question as to what a client should do with such non-document resources. In this case the HTTP protocol requires that the fragment part be stripped off before requesting the URI from the server. The result is a resolvable URI for the profile.

<nowiki>
@base <http://www.w3.org/People/Berners-Lee/card>
@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@prefix dc: <http://purl.org/dc/elements/1.1/>.

<> a foaf:PersonalProfileDocument ;
dc:title "Tim Berners-Lee's FOAF file" ;
foaf:homepage <http://www.w3.org/People/Berners-Lee/> ;
foaf:primaryTopic <#i> .
</nowiki>

===UC4: Update existing resource===
Change the RDF description of a LDP resource, potentially removing or overwriting existing data. This allows applications to ''enrich'' the representation of a resource by addling additional links to other resources.

* Unrestricted vocabulary: It should be possible be "able to add ... application-specific data" to resources (from [[#Maintaining Social Contact Information]]).

====Primary scenario: enrichment====
This relates to user-story [[#Metadata Enrichment in Broadcasting| Metadata Enrichment in Broadcasting]] and is based on the [http://www.bbc.co.uk/ontologies/sport/ BBC Sports Ontology]. The ''resource-centric'' view of linked-data provides a natural granularity for substituting, or overwriting a resource and its data. The simplest kind of update would simply replace what is currently known about a resource with a new representation. There are two distinct resources in the example below; a sporting event and an associated award. The granularity of the LDP would allow a user to replace the information about the award without disturbing the information about the event.

<nowiki>
@prefix sport: <http://www.bbc.co.uk/ontologies/sport/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

:mens_sprint a sport:MultiStageCompetition;
rdfs:label "Men's Sprint";
sport:award <#gold_medal> .

<#gold_medal> a sport:Award .
</nowiki>

We can enrich the description as events unfold, linking to the winner of the gold medal by substituting the above description with the following.

<nowiki>
@prefix sport: <http://www.bbc.co.uk/ontologies/sport/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

:mens_sprint a sport:MultiStageCompetition;
rdfs:label "Men's Sprint";
sport:award <#gold_medal> .
<#gold_medal> a sport:Award;
sport:awarded_to [
a foaf:Agent ;
foaf:name "Chris Hoy" .
] .
</nowiki>

====Alternative scenario: selective update of a resource====
This relates to user-story [[#Data Catalogs|Data Catalogs]], based on the [http://vocab.deri.ie/dcat Data Catalog Vocabulary].
A catalogue is described by the following RDF model.

<nowiki>
@prefix dcat: <http://www.w3.org/ns/dcat#> .
@prefix dcterms: <http://purl.org/dc/terms/> .

:catalog a dcat:Catalog ;
dcat:dataset :dataset/001;
dcterms:issued "2012-12-11"^^xsd:date.
</nowiki>

A catalog may contain multiple datasets, so when linking to new datasets it would be simpler and preferable to selectively add just the new dataset links.
A Talis ''changeset'' [http://docs.api.talis.com/getting-started/changesets][http://www.w3.org/2009/12/rdf-ws/papers/ws07] could be used to add a new <nowiki>dc:title</nowiki> to the dataset. The following update would be directed to the catalogue to add an additional dataset.

<nowiki>
@prefix : <http://example.com/>.
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix cs: <http://purl.org/vocab/changeset/schema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.

<change1>
a cs:ChangeSet ;
cs:subjectOfChange :catalog ;
cs:createdDate "2012-01-01T00:00:00Z" ;
cs:changeReason "Update catalog datasets" ;
cs:addition [
a rdf:Statement ;
rdf:subject :catalog ;
rdf:predicate dcat:dataset ;
rdf:object :dataset/002 .
] .
</nowiki>

===UC5: Determine if a resource has changed===
It should be possible to retrieve versioning information about a resource (e.g. last modified or entity tag) without having to download a representation of the resource.
This information can then be compared with previous information held about that resource to determine if it has changed.
This versioning information can also be used in subsequent ''conditional'' requests to ensure they are only applied if the version is unchanged.

====Primary scenario====
Based on the user-story, [[#Constrained Devices and Networks| Constrained Devices and Networks]], an LDP could be configured to act as a proxy for a [http://tools.ietf.org/html/draft-ietf-core-coap CoAP] based [http://en.wikipedia.org/wiki/Web_of_Things Web of Things]. As an observer of CoAP resources, the LDP registers its interest so that it will be notified whenever the sensor reading changes. Clients of the LDP can interrogate the LDP to determine if the state has changed.

In this example, the information about a sensor and corresponding sensor readings can be represented as RDF resources. The first resource below, represents a sensor described using the [http://www.w3.org/2005/Incubator/ssn/ Semantic Sensor Network] ontology.
<nowiki>
@prefix : <http://example.com/energy-management/>.

<> a :MainsFrequencySensor;
rdfs:comment "Sense grid load based on mains frequency";
ssn:hasMeasurementCapability [
a :FrequencyMeasurementCapability;
ssn:hasMeasurementProperty <#property_1> .
] .
</nowiki>

The value of the sensor changes in real-time as measurements are taken. The LDP client can interrogate the resource below to determine if it has changed, ''without'' necessarily having to download the RDF representation. As different sensor properties are represented disjointly (separate RDF representations) they may change independently.

<nowiki>
@prefix : <http://example.com/energy-management/>.

<http://example.com/energy-management#property_1> :hasMeasurementPropertyValue <> .
<> a :FrequencyValue;
:hasQuantityValue "50"^^xsd:float.
</nowiki>

===UC6: Aggregate resources===
There is a requirement to be able to manage ''collections'' of resources. The concept of a collection overlaps with, but is distinct from that of a container. These collections are (weak) aggregations, unrelated to the lifecycle management of resources, and distinct from the ownership between a resource and its container. However, the composition of a container may be reflected as a collection to support navigation of the container and its contents. There is a need to be able to create collections by adding and deleting individual membership properties. Resources may belong to multiple collections, or to none.

* Resource descriptions are a "mix of simple data and collections" (from [[#Keeping Track of Personal and Business Relationships]]).
* Relative URIs: It should be possible to "ship payloads of RDF" for a collection as a whole without breaking internal links (from [[#Constrained Devices and Networks]]).

====Primary scenario: add a resource to a collection====
This example is from [[#Library Linked Data|Library Linked Data]] and [http://www.w3.org/2005/Incubator/lld/wiki/UseCaseReport LLD-UC], specifically [http://www.w3.org/2005/Incubator/lld/wiki/Use_Case_Subject_Search Subject Search].

There is an existing collection at <nowiki><http://example.com/concept-scheme/subject-heading></nowiki> that defines a collection of subject headings. This collection is defined as a skos:ConceptScheme and
the client wishes to insert a new concept into the scheme. which will be related to the collection via a <nowiki>skos:inScheme</nowiki> link. The new subject-heading, "outer space exploration", is not necessarily owned by a container. The following RDF would be added to the (item-level) description of the collection.

<nowiki>
@prefix scheme : <http://example.com/concept-scheme/>.
@prefix concept : <http://example.com/concept/>.

scheme:subject-heading a skos:ConceptScheme.

concept:Outer+space+Exploration skos:inScheme scheme:subject-heading.
</nowiki>

====Alternative scenario: add a resource to multiple collections====
Logically, a resource should not be owned by more than one container. however, it may be a member of multiple collections which define a weaker form of ''aggregation''. As this is simply a manipulation of the RDF description of a collection, it should be possible to add the same resource to multiple collections.

As a machine-readable collection of medical terms, the [http://www.ihtsdo.org| SNOMED] ontology is of key importance in [[#Healthcare | healthcare]]. SNOMED CT allows concepts with more than one parent that don't fall into a lattice.
In the example below, the same concept may fall under two different parent concepts.
The example uses skos:narrowerTransitive to elide intervening concepts.

<nowiki>
@prefix : <http://example.com/snomed/>.

:_119376003 a skos:Concept ;
skos:prefLabel "Tissue specimen"
skos:narrowerTransitive :TissueSpecimenFromHeart.

:_127462005 a skos:Concept ;
skos:prefLabel "Specimen from heart"
skos:narrowerTransitive :TissueSpecimenFromHeart.

:_128166000 a skos:Concept;
rdfs:label "Tissue specimen from heart".
</nowiki>

===UC7: Filter resource description===
This use-case extends the normal behaviour of retrieving an RDF description of a resource, by dynamically excluding specific (membership) properties.
For containers, it is often desirable to be able to read a collection, or item-level description that excludes the container membership.

====Primary scenario: retrieve collection-level description====
This scenario, based on [[#Library Linked Data| Library Linked Data]], uses the Dublin Core Metadata Initiative [http://dublincore.org/groups/collections/collection-application-profile/| Collection-Level] description.
A collection can refer to any aggregation of physical or digital items.
This scenario covers the case whereby a client can request a collection-level description as typified by the example below, without necessarily having to download a full listing of the items within the collection.

<nowiki>
@prefix rdf: <rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">.
@prefix dc: <http://purl.org/dc/elements/1.1/>.
@prefix : <http://example.org/bookshelf/>.
@prefix dcmitype: <http://purl.org/dc/dcmitype/>.
@prefix cld: <http://purl.org/cld/terms/>.
@prefix dcterms: <http://purl.org/dc/terms/>.

<> dc:type dcmitype:Collection ;
dc:title "Directory of organizations working with Linked Data" ;
dcterms:abstract "This is a directory of organisations specializing in Linked Data."
cld:isLocatedAt <http://dir.w3.org>
cld:isAccessedVia <http://dir.w3.org/rdf/2012/directory/directory-list.xhtml?construct>
</nowiki>

====Alternative scenario: retrieve item-level description of a collection====
This use-case scenario, also based on [[#Library Linked Data| Library Linked Data]], focuses on obtaining an item-level description of the resources aggregated by a collection.
The simplest scenario is where the members of a collection are returned within a single representation, so that a client can explore the data by following these links. Different applications may use different membership predicates to capture this aggregation. The example below uses <nowiki>rdfs:member</nowiki>, but many different membership predicates are in common use, including RDF Lists.
Item-level descriptions can be captured using the Functional Requirements for Bibliographic Records ([http://www.ifla.org/publications/functional-requirements-for-bibliographic-records FRBR]) [http://vocab.org/frbr/core.html ontology].

<nowiki>
@prefix frbr: <http://purl.org/vocab/frbr/core#>.

<> rdfs:member <#ebooks97>, <#ebooks21279>.

<#work97> a frbr:LiteraryWork;
dc:title "Flatland: a romance of many dimensions" ;
frbr:creator <#Abbott_Edwin>;
frbr:manifestation <ebook97>.

<#work21279> a frbr:LiteraryWork;
dc:title "2 B R 0 2 B" ;
frbr:creator <#Vonnegut_Kurt>;
frbr:manifestation <ebook21279>.
</nowiki>

Collections are potentially very large, so some means may be required to limit the size of RDF representation returned by the LDP (e.g. pagination).

===UC8: Manage media resources===
It should be possible to easily add non-RDF media resources to containers that accept them. Media resources may be updated and removed during the lifecycle of the container.

====Primary scenario: access media resources====
From the User Story [[#Sharing Binary Resources and Metadata| Sharing Binary Resources and Metadata]] it should be possible to easily add non RDF resources to a containers that accept them. Clients submit a non-RDF representation to a container in a media type accepted by that container. The container creates a URI to represent this media resource, and creates a link from the container to the new URI.The media resource may have an explicit representation of the media type. It should be possible to find the metadata about such a resource and to access and edit it in the usual ways.

This example uses the [http://www.w3.org/TR/mediaont-10/#ont-ttl Ontology for Media Resources] to describe a media resource added to a collection.
<nowiki>
@prefix ma: <http://www.w3.org/ns/ma-ont#> .

<dataset> a ma:Collection ;
:hasMember <dataset/image1.jpg>

<dataset/image1.jpg> a ma:MediaResource ;
ma:hasFormat "image/jpeg" .
</nowiki>

====Alternative scenario: media-resource attachments====
A resource may have multiple ''renditions''; the idea that you can have a PDF and a JPEG representing the same thing. A user is trying to create a work order along with an attached image showing a faulty machine part. To the user and to the work order system, these two artifacts are managed as a set. A single request may create the work order, the attachment, and the relationship between them, atomically.
When the user retrieves the work order later, they expect a single request by default to retrieve the work order plus all attachments.
When the user updates the work order, e.g. to mark it completed, they only want to update the work order proper, not its attachments.
Users may add/remove/replace attachments to the work order during its lifetime.

== Requirements ==

===Functional Requirements===
# Create Containers, from [[#UC1: Manage containers]]
# Creation of nested containers, from [[#UC1: Manage containers]]
# Creation of resources (within a container), from [[#UC2: Manage resources]]
# Deletion of resources, from [[#UC2: Manage resources]]
# Moving contained resources, from [[#UC2: Manage resources]]
# Retrieve resource description, from [[#UC3: Retrieve resource description]]
# Retrieve description of a non-document resource, from [[#UC3: Retrieve resource description]]
# Enrichment (substituting update of existing resource), from [[#UC4: Update existing resource]]
# Selective update of a resource, from [[#UC4: Update existing resource]]
# Determine if a resource has changed, from [[#UC5: Determine if a resource has changed]]
# Add a resource to a collection, from [[#UC6: Aggregate resources]]
# Add a resource to multiple collections, from [[#UC6: Aggregate resources]]
# Retrieve collection-level description, from [[#UC7: Filter resource description]]
# Retrieve item-level description of a collection, from [[#UC7: Filter resource description]]
# Access media resources, from [[#UC8: Manage media resources]]
# Media-resource attachments, from [[#UC8: Manage media resources]]

===Non-Functional Requirements===

# Provide access guidance to resources, from [[#UC1: Manage containers]]
# Non-duplication of resources, from [[#UC2: Manage resources]]
# Distribution of resources, from [[#UC2: Manage resources]]
# Consistent, global naming, from [[#UC2: Manage resources]]
# Use standard vocabularies as appropriate, from [[#UC3: Retrieve resource description]]
# Scalable linking model, from [[#UC3: Retrieve resource description]]
# Unrestricted vocabulary, from [[#UC4: Update existing resource]]
# Resource descriptions are a "mix of simple data and collections", from [[#UC6: Aggregate resources]]
# Relative URIs enabling sharing of collections, from [[#UC6: Aggregate resources]]

== Acknowledgements ==
We would like to acknowledge the contributions of user-story authors; Christophe Guéret, Roger Menday, Eric Prud'hommeaux, Steve Speicher.

== References ==

Use Cases And Requirements

Sbattle2 — Mon, 10 Dec 2012 17:10:54 GMT

Sbattle2: /* To Be Done */

= Linked Data Platform Use Cases And Requirements =

This is a working document used to collect use cases and requirements for consideration by the WG.
The starting point comes from [http://www.w3.org/Submission/2012/SUBM-ldbpucr-20120326/ Linked Data Basic Profile Use Cases and Requirements].

== Steps to Complete ==

* <strike>Nov 26? WG to confirm User Story content: add, remove, refine (see process below). Note: this is ONLY User Stories (not Use Cases, Use Case Scenarios or Requirements)</strike>
** Issues before Nov 26th? will be included into FPWD
* Editors to:
** <strike>Dec 3 refine User Stories based on feedback</strike>
** <strike>Dec 5 elaborate on Use Cases in support of User Stories</strike>
* Dec 10 - WG to review prior to FPWD
** Review period ends Dec 15th
** insert open issues into draft for FPWD
* Dec 17 - Publish FPWD
** convert wiki page to ReSpec for FPWD
* Dec ?? Deadline for publications by year end 2012

===To Be Done===
* <strike>Move [[#LDP_and_Authentication.2FAuthorization| LDP and Authentication]] to [http://www.w3.org/2012/ldp/wiki/AccessControl AccessControl]</strike>
* <strike>Complete [[#Alternative_scenario:_moving_contained_resources| moving contained resources]] scenario with content from ericP on issue-30.</strike>
* <strike>Augment [[#Cloud_Infrastructure_Management| Cloud Infrastructure Management]] scenario with content from Roger Menday.</strike>
* <strike>Ensure issue-40/41 are fully covered in [[#UC8:_Managing_non-RDF_Resources| UC8: Managing non-RDF Resources]]. 2 scenarios (single v multiple attachments) ?</strike>
* <strike>Contact owner of [[#Data_Sharing| Data Sharing]] user-story to determine if we keep or not.</strike>
* <strike>Review [[#Requirements| Requirements]] section for functional/non-functional requirements arising in UCs.</strike>
* <strike>Propose resolutions to open issues against UC&R where possible.</strike>
* <strike>Identify and acknowledge user-story contributors.</strike>
* <strike>Check hyperlinks</strike>
* Convert to ReSpec
* Annotate document with open issues against UC&R
** <strike>[http://www.w3.org/2012/ldp/track/issues/30 ISSUE-30] (OPEN)</strike>
** [http://www.w3.org/2012/ldp/track/issues/40 ISSUE-40] (PENDING REVIEW)
** [http://www.w3.org/2012/ldp/track/issues/41 ISSUE-41] (PENDING REVIEW)

=== Process to introduce new User Stories & Use Cases ===

Open an Issue in the tracker against the UC&R product. The WG will review these and decide whether they are valid.

== Scope and Motivation ==

Linked Data was defined by Tim Berners-Lee with the following guidelines [http://www.w3.org/DesignIssues/LinkedData.html]:

# Use URIs as names for things
# Use HTTP URIs so that people can look up those names
# When someone looks up a URI, provide useful information, using the standards (RDF*, SPARQL)
# Include links to other URIs. so that they can discover more things

These four rules have proven very effective in guiding and inspiring people to publish Linked Data on the web. The amount of data, especially public data, available on the web has grown rapidly, and an impressive number of extremely creative and useful “mashups” have been created using this data as result.

There has been much less focus on the potential of Linked Data as a model for managing data on the web - the majority of the Application Programming Interfaces (APIs) available on the Internet for creating and updating data follow a Remote Procedure Call (RPC) model rather than a Linked Data model.

If Linked Data were just another model for doing something that RPC models can already do, it would be of only marginal interest. Interest in Linked Data arises from the fact that applications with an interface defined using Linked Data can be much more easily and seamlessly integrated with each other than applications that offer an RPC interface. In many problem domains, the most important problems and the greatest value are found not in the implementation of new applications, but in the successful integration of multiple applications into larger systems.

Some of the features that make Linked Data exceptionally well suited for integration include:

* A single interface – defined by a common set of HTTP methods – that is universally understood and is constant across all applications. This is in contrast with the RPC architecture where each application has a unique interface that has to be learned and coded to.
* A universal addressing scheme – provided by HTTP URLs – for both identifying and accessing all “entities”. This is in contrast with the RPC architecture where there is no uniform way to either identify or access data.
* A simple yet extensible data model – provided by RDF – for describing data about a resource in a way which doesn’t require prior knowledge of vocabulary being used.

Experience implementing applications and integrating them using Linked Data has shown very promising results, but has also demonstrated that the original four rules defined by Tim Berners-Lee for Linked Data are not sufficient to guide and constrain a writable Linked Data API. As was the case with the original four rules, the need generally is not for the invention of fundamental new technologies, but rather for a series of additional rules and patterns that guide and constrain the use of existing technologies in the construction of a Basic Profile for Linked Data to achieve interoperability.

The following list illustrates a few of the issues that require additional rules and patterns:
* What URLs do I post to in order to create new resources?
* How do I get lists of existing resources, and how do I get basic information about them without having to access each one?
* How should I detect and deal with race conditions on write?
* What media-types/representations should I use?
* What standard vocabularies should I use?
* What primitive data types should I use?

A good goal for the Basic Profile for Linked Data would be to define a specification required to allow the definition of a writable Linked Data API equivalent to the simple application APIs that are often written on the web today using the Atom Publishing Protocol (APP). APP shares some characteristics with Linked Data, such as the use of HTTP and URLs. One difference is that Linked Data relies on a flexible data model with RDF, which allows for multiple representations.

== Organization of this Document ==

This document is organized as follows:

* '''[[#User Stories| User Stories]]''' capture statements about system requirements written from a user or application perspective. They are typically lightweight and informal and can run from one line to a paragraph or two (sometimes described as an 'epic') [http://www.agilemodeling.com/artifacts/userStory.htm]. Analysis of each user story will reveal a number of (functional) use-cases and other non-functional requirements. See [http://www.w3.org/TR/dap-policy-reqs/| Device API Access Control Use Cases and Requirements] for a good example of user stories and their analysis.

* '''[[#Use Cases| Use Cases]]''' are used to capture and model functional requirements. Use cases describe the system’s behavior under various conditions [http://alistair.cockburn.us/get/2465], cataloguing who does what with the system, for what purpose, but without concern for system design or implementation [http://www.bredemeyer.com/pdf_files/functreq.pdf]. Each use case is identified by a reference number to aid cross-reference from other documentation; use-case indexing in this document is based on [http://www.w3.org/TR/rdb2rdf-ucr/ rdb2rdf use-cases]. A variety of styles may be used to capture use-cases, from a simple narrative to a structured description with actors, pre/post conditions, and step-by-step behaviours as in [http://www.w3.org/TR/powder-use-cases/ POWDER: Use Cases and Requirements], and non-functional requirements raised by the use-case. Use cases act like the hub of a wheel, with spokes supporting requirements analysis, scenario-based evaluation, testing, and integration with non-functional, or quality requirements.

* '''Scenarios''' are more focused still, representing a single instance of a use case in action. Scenarios may range from lightweight narratives as seen in [http://www.w3.org/TR/media-frags-reqs/ Use cases and requirements for Media Fragments], to being formally modeled as interaction diagrams. Each use-case should include at least a primary scenario, and possibly other alternative scenarios.

* '''[[#Requirements| Requirements]]''' list non-functional or quality requirements, and the use cases they may be derived from. This approach is exemplified in the [http://dvcs.w3.org/hg/gld/raw-file/default/dcat-ucr/index.html Use Cases and Requirements for the Data Catalog Vocabulary].

== User Stories ==

=== Maintaining Social Contact Information ===

Many of us have multiple email accounts that include information about the people and organizations we interact with – names, email addresses, telephone numbers, instant messenger identities and so on. When someone’s email address or telephone number changes (or they acquire a new one), our lives would be much simpler if we could update that information in one spot and all copies of it would automatically be updated. In other words, those copies would all be linked to some definition of “the contact.” There might also be good reasons (like off-line email addressing) to maintain a local copy of the contact, but ideally any copies would still be linked to some central “master.”

Agreeing on a format for “the contact” is not enough, however. Even if all our email providers agreed on the format of a contact, we would still need to use each provider’s custom interface to update or replace the provider’s copy, or we would have to agree on a way for each email provider to link to the “master”. If we look outside our own personal interests, it would be even more useful if the person or organization exposed their own contact information so we could link to it.

What would work in either case is a common understanding of the resource, a few formats needed, and access guidance for these resources. This would support how to acquire a link to a contact, and how to use those links to interact with a contact (including [[#UC3: Retrieve resource description|reading]], [[#UC4: Update existing resource|updating]], and [[#Alternative scenario: delete resource|deleting]] it), as well as how to easily [[#Primary scenario: create resource|create a new contact]] and add it to my contacts and when deleting a contact, how it would be removed from my list of contacts. It would also be good to be able to add some application-specific data about my contacts that the original design didn’t consider. Ideally we’d like to eliminate multiple copies of contacts, there would be additional valuable information about my contacts that may be stored on separate servers and need a simple way to link this information back to the contacts. Regardless of whether a contact collection is my own, shared by an organization, or all contacts known to an email provider (or to a single email account at an email provider), it would be nice if they all worked pretty much the same way.

=== Keeping Track of Personal and Business Relationships ===

In our daily lives, we deal with many different organizations in many different relationships, and they each have data about us. However, it is unlikely that any one organization has all the information about us. Each of them typically gives us access to the information (at least some of it), many through websites where we are uniquely identified by some string – an account number, user ID, and so on. We have to use their applications to interact with the data about us, however, and we have to use their identifier(s) for us. If we want to build any semblance of a holistic picture of ourselves (more accurately, collect all the data about us that they externalize), we as humans must use their custom applications to find the data, copy it, and organize it to suit our needs.

Would it not be simpler if at least the Web-addressable portion of that data could be linked to consistently, so that instead of maintaining various identifiers in different formats and instead of having to manually supply those identifiers to each one’s corresponding custom application, we could essentially build a set of bookmarks to it all? When we want to [[#UC3: Retrieve resource description|examine]] or [[#UC4: Update existing resource|change]] their contents, would it not be simpler if there were a single consistent application interface that they all supported? Of course it would.

Our set of links would probably be a [[#UC6: Aggregate resources|simple collection]]. The information held by any single organization might be a mix of simple data and [[#UC6: Aggregate resources|collections of other data]], for example, a bank account balance and a collection of historical transactions. Our bank might easily have [[#Alternative scenario: create a nested container|a collection of accounts for each of its collection of customers]].

=== System and Software Development Tool Integration ===

System and software development tools typically come from a diverse set of vendors and are built on various architectures and technologies. These tools are purpose built to meet the needs for a specific domain scenario (modeling, design, requirements and so on.) Often tool vendors view integrations with other tools as a necessary evil rather than providing additional value to their end-users. Even more of an afterthought is how these tools’ data -- such as people, projects, customer-reported problems and needs -- integrate and relate to corporate and external applications that manage data such as customers, business priorities and market trends. The problem can be isolated by standardizing on a small set of tools or a set of tools from a single vendor, but this rarely occurs and if does it usually does so only within small organizations. As these organizations grow both in size and complexity, they have needs to work with outsourced development and diverse internal other organizations with their own set of tools and processes. There is a need for better support of more complete business processes (system and software development processes) that span the roles, tasks, and data addressed by multiple tools. This demand has existed for many years, and the tools vendor industry has tried several different architectural approaches to address the problem. Here are a few:

* Implement an API for each application, and then, in each application, implement “glue code” that exploits the APIs of other applications to link them together.
* Design a single database to store the data of multiple applications, and implement each of the applications against this database. In the software development tools business, these databases are often called “repositories.”
* Implement a central “hub” or “bus” that orchestrates the broader business process by exploiting the APIs described previously.

It is fair to say that although each of those approaches has its adherents and can point to some successes, none of them is wholly satisfactory. The use of Linked Data as an application integration technology has a strong appeal. [http://open-services.net/ OSLC]

=== Library Linked Data ===

The W3C Library Linked Data working group has a number of use cases cited in their Use Case Report. [http://www.w3.org/2005/Incubator/lld/wiki/UseCaseReport LLD-UC] These referenced use cases focus on the need to extract and correlate library data from disparate sources. Variants of these use cases that can provide consistent formats, as well as ways to improve or update the data, would enable simplified methods for both efficiently sharing this data as well as producing incremental updates without the need for repeated full extractions and import of data.

The 'Digital Objects Cluster' contains a number of relevant use-cases:

* Grouping: This should "Allow the end-users to define [[#UC6: Aggregate resources|groups of resources]] on the web that for some reason belong together. The relationship that exists between the resources is often left unspecified. Some of the resources in a group may not be under control of the institution that defines the groups."

* Enrichment: "Enable end-users to [[#UC4: Update existing resource|link resources together]]."

* Browsing: "[[#UC7: Filter resource description|Support end-user browsing through groups]] and resources that belong to the groups."

* Re-use: "Users should have the capability to re-use all or parts of a collection, with all or part of its metadata, elsewhere on the linked Web."

The 'Collections' cluster also contains a number of relevant use-cases:

* Collection-level description: "Provide [[#UC7: Filter resource description|metadata pertaining to a collection as a whole]], in contrast to item-level description."

* Collections discovery: "Enable innovative collection discovery such as identification of nearest location of a physical collection where a specific information resource is found or mobile device applications ... based on collection-level descriptions."

* Community information services: Identify and classify collections of special interest to the community.

=== Municipality Operational Monitoring ===

Across various cities, towns, counties, and various municipalities there is a growing number of services managed and run by municipalities that produce and consume a vast amount of information. This information is used to help monitor services, predict problems, and handle logistics. In order to effectively and efficiently collect, produce, and analyze all this data, a fundamental set of loosely coupled standard data sources are needed. A simple, low-cost way to [[#UC3: Retrieve resource description|expose data]] from the diverse set of monitored services is needed, one that can easily integrate into the municipalities of other systems that inspect and analyze the data. All these services have links and dependencies on other data and services, so having a simple and scalable linking model is key.

=== Healthcare ===

For physicians to analyze, diagnose, and propose treatment for patients requires a vast amount of complex, changing and growing knowledge. This knowledge needs to come from a number of sources, including physicians’ own subject knowledge, consultation with their network of other healthcare professionals, public health sources, food and drug regulators, and other repositories of medical research and recommendations.

To diagnose a patient’s condition requires current data on the patient’s medications and medical history. In addition, recent pharmaceutical advisories about these medications are linked into the patient’s data. If the patient experiences adverse affects from medications, these physicians need to publish information about this to an appropriate regulatory source. Other medical professionals require access to both validated and emerging effects of the medication. Similarly, if there are geographical patterns around outbreaks that allow both the awareness of new symptoms and treatments, this information needs to quickly reach a very distributed and diverse set of medical information systems. Also, reporting back to these regulatory agencies regarding new occurrences of an outbreak, including additional details of symptoms and causes, is critical in producing the most effective treatment for future incidents.

=== Metadata Enrichment in Broadcasting ===

There are many different use cases when broadcasters show interest in metadata [[#UC4: Update existing resource| enrichment]]:

* enrich archive or news metadata by linking facts, events, locations and personalities
* enrich metadata generated by automatic extraction tools such as person identification, etc.
* enrich definitions of terms in classification schemes or enumeration lists

This comes in support of more effective information management and data/content mining (if you can't find your content, it' like if you don't have and must either recreate or acquire it again, which is not financially effective).

However, there is a need for solutions facilitating linkage to other data sources and taking care of the issues such as discovery, automation, disambiguation. Etc. Other important issues that broadcasters would face are the editorial quality of the linked data, its persistence, and usage rights.

=== Aggregation and Mashups of Infrastructure Data ===

For infrastructure management (such as storage systems, virtual machine environments, and similar IaaS and PaaS concepts), it is important to provide an environment in which information from different sources can be [[#UC6: Aggregate resources|aggregated]], [[#UC7: Filter resource description|filtered]], and visualized effectively. Specifically, the following use cases need to be taken into account:

* While some data sources are based on Linked Data, others are not, and aggregation and mashups must work across these different sources.
* Consumers of the data sources and aggregated/filtered data streams are not necessarily implementing Linked Data themselves, they may be off-the-shelf components such as dashboard frameworks for composing visualizations.
* Simple versions of this scenario are pull-based, where the data is requested from data sources. In more advanced settings, without a major change in architecture it should be possible to move to a push-based interaction model, where data sources push notifications to subscribers, and data sources provide different services that consumers can subscribe to (such as "informational messages" or "critical alerts only").

In this scenario, the important factors are to have abstractions that allow easy aggregation and filtering, are independent from the internal data model of the sources that are being combined, and can be used for pull-based interactions as well as for push-based interactions.

=== Sharing payload of RDF data among low-end devices ===

Several projects around the idea of [http://worldwidesemanticweb.wordpress.com/ downscaling the Semantic Web] need to be able to ship payloads of RDF across the nodes member of a given network. The transfers are done in a constrained context in terms of bandwidth, scope of the local semantics employed by the nodes and computing capabilities of the nodes. In a P2P style, every node has the capability to act either as a data consumer or a data provider, serving its own data or acting as a relay to pass other's data along (typically in mesh networks).

The transfer of an arbitrary payload of RDF data could be implemented through the container mechanism, adding and removing sets of RDF triples to it. Currently, one of the project "SemanticXO" uses named graphs and the graph protocol to create/delete/copy graphs across the nodes but this (almost) imposes the usage of a triple store. Unfortunately, triple store are rather demanding piece of software that are not always usable on limited hardware. Some generic ReST like interaction backed up with a lightweight column store would be better approach.

=== Sharing Binary Resources and Metadata ===

When publishing datasets about stars one may want to publish links to the pictures in which those stars appear, and this may well require publishing the pictures themselves. Vice versa: when publishing a picture of space we need to know which telescope took the picture, which part of the sky it was pointing at, what filters were used, which identified stars are visible, who can read it, who can write to it, ...

If LinkedData contains information about resources that are most naturally expressed in non-rdf formats (be they binary such as pictures or videos, or human readable documents in XML formats), those non RDF formats should be just as easy to publish to the LinkedData server as the RDF relations that link those resources up. A LinkedData server should therefore allow publishing of non linked data resources too, and make it easy to publish and edit metadata about those resources.

The resource comes in two parts - the image and information about the image (which may in the image file but better external to it as it's more general). The information about the image is vital. It's a compound item of image data and other data (being application metadata about the image does not distinguish from the platform's point-of-view.

=== Data Catalogs ===

The Asset Description Metadata Schema ([http://joinup.ec.europa.eu/asset/adms/home ADMS]) provides the data model to describe semantic assets repositories contents, but this leaves many open challenges when building a federation of these repositories to serve the need of assets reuse. These include accessing and querying individual repositories and efficiently retrieving [[#UC5: Determine if a resource has changed| updated content]] without having to retrieve the whole content. Hence, we chose to build the integration solution capitalizing on the Data Warehousing integration approach. This allows us to cope with heterogeneity of sources technologies and to benefit from the optimized performance it offers, given that individual repositories do not usually change frequently. With Data Warehousing, the federation requires to:

* understand the data, i.e. understand their semantic descriptions, and other systems.
* seamlessly exchange the semantic assets metadata from different repositories
* keep itself up-to-date.

Repositories owners can maintain de-referenceable URIs for their repository description and contained assets in a Linked Data compatible manner. ADMS provides the necessary data model to enable meaningful exchange of data. However, This leaves the challenge of efficient access to the data not fully addressed.

Related: [http://spec.datacatalogs.org/ Data Catalog Schema and Protocol]

=== Constrained Devices and Networks ===

Information coming from resource constrained devices in the Web of Things ([http://en.wikipedia.org/wiki/Web_of_Things WoT]) has been identified as a major driver in many domains, from smart cities to environmental monitoring to real-time tracking. The amount of information produced by these devices is growing exponentially and needs to be accessed and integrated in a systematic, standardized and cost efficient way. By using the same standards as on the Web, integration with applications will be simplified and higher-level interactions among resource constrained devices, abstracting away heterogeneities, will become possible. Up-coming IoT/WoT standards such as [http://datatracker.ietf.org/wg/6lowpan/ 6LowPAN] - IPv6 for resource constrained devices - and the Constrained Application Protocol ([http://tools.ietf.org/html/draft-ietf-core-coap CoAP]), which provides a downscaled version of HTTP on top of UDP for the use on constrained devices, are already at a mature stage. The next step now is to support RESTful interfaces also on resource constrained devices, adhering to the Linked Data principles. Due to the limited resources available, both on the device and in the network (such as bandwidth, energy, memory) a solution based on SPARQL Update is at the current point in time considered not to be useful and/or feasible. An approach based on the [http://tools.ietf.org/html/draft-castellani-core-http-mapping HTTP-CoAP Mapping] would enable constrained devices to directly participate in a Linked Data-based environment.

=== Services Supporting the Process of Science ===
Many fields of science now include branches with in silico data-intensive methods, e.g. bioinformatics, astronomy. To support these new methods we look to move beyond the established platforms provided by scientific workflow systems to capture, assist, and preserve the complete lifecycle from record of the experiment, through local trusted sharing, analysis, dissemination (including publishing of experimental data "beyond the PDF"), and re-use.

* [[#UC6: Aggregate resources|Aggregations]], specifically ''Research Objects (ROs)'' that are exchanged between services and clients bringing together workflows, data sets, annotations, and provenance. We use an RDF model for this. While some aggregated contents are encoded using RDF and in increasing number are linked data sources, others are not; while some are stored locally "within" the RO, others are remote (in both cases this is often due to size of the resources or access policies).
* Services that are distributed and linked. Some may be centralising for e.g. publication, others may be local, e.g. per lab. We need lightweight services that can be simply and easily integrated into and scale across the wide variety of softwares and data used in science: we have adopted a RESTful approach where possible.
** Foundation services that collect and expose ROs for storage, modification, exploration, and reuse.
** Services that provide added-value to ROs such as seamless import/export from scientific workflow systems, automated stability evaluation, or recommendation (and therefore interact with the foundation services to retrieve/store/modify/ROs).

seeAlso: [http://www.wf4ever-project.org/ Wf4Ever]

=== Project Membership Information : Information Evolution ===

Information about people and projects changes as roles change, as organisations change
and as contact details change. Finding the current state of a project is important
in enabling people to contact the right person in the right role. It can also be
useful to look back and see who was performing what role in the past.

A use of a Linked Data Platform could be to give responsibility for managing
such information with the project team itself, not requiring updates to be
requested of a centralised website administrator.

This could be achieved with:

* Resource descriptions for each person and project
* A container resource to describe roles/membership in the project.

To retain the history of the project, the old version of a resources,
including container resources, should be retained so there is a need to address both specific items
and also have a notion of "current".

Access to information has two aspects:
* Access to the "current" state, regardless of the version of the resource description
* Access to historical state, via access to a specific version of the resource description

=== Cloud Infrastructure Management===

Cloud operators offer API support to provide customers with remote access for the management of Cloud infrastructure (IaaS). Infrastructure consists of Systems, Computers, Networks, Discs, etc. The overall structure can be seen as mostly hierarchical, (Cloud contains Systems, Systems contain Machines, etc), complemented with crossing links (e.g. multiple Machines connected to a Network).

The IaaS scenario makes specific requirements on lifecycle management and discovery, handling non-instant changes, history capture and query:

* Many aspects of Cloud infrastructure have associated lifecycle, e.g. a Computer can be transitioned between Running and Shutdown. This should be manageable through the API, which should include how a client discovers dynamic lifecycle options and thus help steering through an application.
* It is often the case that attaining a new lifecycle state is not instantaneous. Clients require a universal mechanism for monitoring such changes.
* A facility to retrieve all events in the lifecycle of a resource can be useful.
* Query provides the means to interrogate the resources behind the API, as well as finding new entry points into the application.

Infrastructure management may be viewed as the manipulation of the underlying graph of resources.

== Use Cases ==
The following use-cases are each derived from one or more of the user-stories above. These use-cases are explored in detail through the development of scenarios, each motivated by some key aspect exemplified by a single user-story. The examples they contain are included purely for illustrative purposes, and should not be interpreted normatively.

===UC1: Manage containers===
A number of user-stories introduce the idea of a ''container'' as a mechanism for creating and managing resources within the context of an application. Resources grouped together within the same container would typically belong to the same application. A container is identified by a URI so is a resource in its own right.
The properties of a container may also represent the ''affordances'' of that container, enabling clients to determine what other operations they can do on that container. These operations may include descriptions of application specific services that can be invoked by exchanging RDF documents.

* Provide "access guidance for ... resources" (affordances) (from user-story, [[#Maintaining Social Contact Information|Maintaining Social Contact Information]]).

====Primary scenario: create container====
Create a new container resource within the LDP server.
In [[#Services Supporting the Process of Science|Services supporting the process of science]], [http://wf4ever.github.com/ro-primer/ Research Objects] are semantically rich aggregations of resources that bring together data, methods and people in scientific investigations. A basic workflow research object will be created to aggegate [http://ceur-ws.org/Vol-903/paper-01.pdf scientific workflows] and the artefacts that result from this workflow. The research object begins life as an empty container into which workflows, datasets, results and other data will be added throughout the lifecycle of the project.

<nowiki>
@prefix ro: http://purl.org/wf4ever/ro#
@prefix dct: http://purl.org/dc/terms/
@prefix ore: http://www.openarchives.org/ore/

<> a ro:ResearchObject, ore:Aggregation ;
dct:created "2012-12-01"^^xsd:dateTime .
</nowiki>

====Alternative scenario: create a nested container====
The motivation for nested containers comes from the [[#System and Software Development Tool Integration| System and Software Development Tool Integration]] user-story. The OSLC Change Management vocabulary allows bug reports to have attachments referenced by the membership predicate <nowiki>oslc_cm:attachment</nowiki>. The 'top-level-container' contains issues, and each issue resource has its own container of attachment resources.

<nowiki>
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix oslc_cm: <http://open-services.net/ns/cm#>.
@prefix : <http://example.org/>.

:top-level-container rdfs:member :issue1234 .

:issue1234 a oslc_cm:ChangeRequest;
dcterms:identifier "1234";
dcterms:type "a bug";
dcterms:related :issue1235 ;
oslc_cm:attachments :attachments123.

:issue1235 a oslc_cm:ChangeRequest;
dcterms:title "a related bug".

:attachments a oslc_cm:AttachmentList;
oslc_cm:attachment :attachment324, :attachment251.
</nowiki>

===UC2: Manage resources===
This use-case addresses the managed lifecycle of a resource and is concerned with resource ''ownership''. The responsibility for managing resources belongs with their container.
For example, a container may accept a request from a client to make a new resource.
This use-case focuses on creation and deletion of resources in the context of a container, and the potential for transfer of ownership by moving resources between containers.
The ownership of a resource should always be clear; no resource managed in this way should ever be owned by more than one container.

Once a new resource has been created it should be identified by a URI. Clients may defer responsibility for establishing dereferenceable URIs to the container of their data.
The container is a natural choice for the endpoint for this interface as it will already have some application-specific knowledge about the contained resources.
While the LDP has ultimate control over resource naming, some applications may require more control over naming, perhaps to provide a more human-readable URI. An LDP server could support something like the [http://tools.ietf.org/html/rfc5023 Atom Publishing Protocol] slug header to convey a user defined naming 'hint'.

* Non-duplication of resources: "Eliminate multiple copies", representing resources in a single place (from [[#Maintaining Social Contact Information]]).
* Distribution of resources: Linked aata "may be stored on separate servers" (from [[#Maintaining Social Contact Information]]).
* Consistent, global naming: Resources should be "linked to consistently, ... instead of maintaining various identifiers in different formats" (from [[#Keeping Track of Personal and Business Relationships]]).

====Primary scenario: create resource====
Resources begin life by being created within a container. From user-story, [[#Maintaining Social Contact Information|Maintaining Social Contact Information]], It should be possible to "easily create a new contact and add it to my contacts." This suggests that resource creation is closely linked to the application context. The new resource is created in a container representing "my contacts." The lifecycle of the resource is linked to the lifecycle of it's container. So, for example, if "my contacts" is deleted then a user would also reasonably expect that all contacts within it would also be deleted.

Contact details are captured as an RDF description and it's properties, including "names, email addresses, telephone numbers, instant messenger identities and so on." The description may include non-standard RDF; "data about my contacts that the original design didn’t consider."
The following RDF could be used to describe contact information using the [http://www.foaf-project.org FOAF] vocabulary. A contact is represented here by a <nowiki>foaf:PersonalProfileDocument</nowiki> defining a resource that can be created and updated as a single-unit, even though it may describe ancillary resources, such as a <nowiki>foaf:Person</nowiki>, below.

<nowiki>
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

<> a foaf:PersonalProfileDocument;
foaf:PrimaryTopic [
a foaf:Person;
foaf:name "Timothy Berners-Lee";
foaf:title "Sir";
foaf:firstName "Timothy";
foaf:surname "Berners-Lee";
foaf:nick "TimBL", "timbl";
foaf:homepage <http://www.w3.org/People/Berners-Lee/>;
foaf:weblog <http://dig.csail.mit.edu/breadcrumbs/blog/4>;
foaf:mbox <mailto:timbl@w3.org>;
foaf:workplaceHomepage <http://www.w3.org/>.
]
</nowiki>

====Alternative scenario: delete resource====
Delete a resource and all it's properties. If the resource resides within a container it will be removed from that container, however other links to the deleted resource may be left as dangling references.
In the case where the resource is a container, the server may also delete any or all contained resources.
In normal practice, a deleted resource cannot be reinstated. There are however, edge-cases where limited undelete may be desirable.
Best practice states that "[http://www.w3.org/TR/cooluris/| Cool URIs don't change]", which implies that deleted URIs shouldn't be recycled.

====Alternative scenario: moving contained resources====
Many resources may have value beyond the life of their membership in a container. This implies methods to add references to revise container membership.
Cloning container members for use in other containers results in duplication of information and maintenance problems; web practice is to encourage the creation of one resource, which may be referenced as many places as necessary. A change of ownership may - or may not - imply a change of URI, depending upon the specific LDP naming policy. While assigning a new URI to a resource is discouraged [http://www.w3.org/DesignIssues/Architecture.html#HTTP], it is possible to indicate that a resource has moved with an appropriate HTTP response.

===UC3: Retrieve resource description===
Access the current description of a resource, containing properties of that resource and links to related resources. The representation may include descriptions of related resources that cannot be accessed directly.
Depending upon the application, an LDP may enrich the retrieved RDF with additional triples. Examples include adding incoming links, sameAs closure and type closure.
The HTTP response should also include versioning information (i.e. last update or entity tag) so that subsequent updates can ensure they are being applied to the correct version.

* Use standard vocabularies as appropriate to enable a "common understanding of the resource" (from [[#Maintaining Social Contact Information|Maintaining Social Contact Information]]).
* A "scalable linking model is key" (from [[#Municipality Operational Monitoring]]).

====Primary scenario====
The user-story [[#Project Membership Information : Information Evolution| Project Membership Information]] discusses the representation of information about people and projects. It calls for "Resource descriptions for each person and project" allowing project teams to review information held about these resources. The example below illustrates the kinds of information that might be held about organizational structures based on the [http://www.epimorphics.com Epimorphics] [http://www.epimorphics.com/public/vocabulary/org.html organizational ontology].

Note that the example below defines two resources (shown as separate sections below) that will be hosted on an LDP based at <nowiki>http://example.com/</nowiki>. The representations of these resources may include descriptions of related resources, such as <nowiki>http://www.w3.org/</nowiki>, that that fall under a different authority and therefore can't be served from the LDP at this location.

<nowiki>
@prefix org: <http://www.w3.org/ns/org#> .
@prefix owltime: <http://www.w3.org/2006/time> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@base <http://example.com/> .

<member1> a org:Membership ;
org:member <http://www.w3.org/People/Berners-Lee/card#i> ;
org:organization http://www.w3.org/> ;
org:role <director> ;
org:memberDuring [a owltime:Interval; owltime:hasBeginning [
owltime:inXSDDateTime "1994-10-01T00:00:00Z"^^xsd:dateTime]] .

<http://www.w3.org/> a org:FormalOrganization ;
skos:prefLabel "The World Wide Web Consortium"@en ;
skos:altLabel "W3C" .
</nowiki>

<nowiki>
@prefix org: <http://www.w3.org/ns/org#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@base <http://example.com/> .

<director> a org:Role ;
rdfs:label "Director" .
</nowiki>

====Alternative scenario: retrieve description of a non-document resource====
In many cases, the things that are of interest are not always the things that are resolvable. The example below demonstrates how a foaf profile may be used to distinguish between the person and the profile; the former being the topic of the latter. This begs the question as to what a client should do with such non-document resources. In this case the HTTP protocol requires that the fragment part be stripped off before requesting the URI from the server. The result is a resolvable URI for the profile.

<nowiki>
@base <http://www.w3.org/People/Berners-Lee/card>
@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@prefix dc: <http://purl.org/dc/elements/1.1/>.

<> a foaf:PersonalProfileDocument ;
dc:title "Tim Berners-Lee's FOAF file" ;
foaf:homepage <http://www.w3.org/People/Berners-Lee/> ;
foaf:primaryTopic <#i> .
</nowiki>

===UC4: Update existing resource===
Change the RDF description of a LDP resource, potentially removing or overwriting existing data. This allows applications to ''enrich'' the representation of a resource by addling additional links to other resources.

* Unrestricted vocabulary: It should be possible be "able to add ... application-specific data" to resources (from [[#Maintaining Social Contact Information]]).

====Primary scenario: enrichment====
This relates to user-story [[#Metadata Enrichment in Broadcasting| Metadata Enrichment in Broadcasting]] and is based on the [http://www.bbc.co.uk/ontologies/sport/ BBC Sports Ontology]. The ''resource-centric'' view of linked-data provides a natural granularity for substituting, or overwriting a resource and its data. The simplest kind of update would simply replace what is currently known about a resource with a new representation. There are two distinct resources in the example below; a sporting event and an associated award. The granularity of the LDP would allow a user to replace the information about the award without disturbing the information about the event.

<nowiki>
@prefix sport: <http://www.bbc.co.uk/ontologies/sport/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

:mens_sprint a sport:MultiStageCompetition;
rdfs:label "Men's Sprint";
sport:award <#gold_medal> .

<#gold_medal> a sport:Award .
</nowiki>

We can enrich the description as events unfold, linking to the winner of the gold medal by substituting the above description with the following.

<nowiki>
@prefix sport: <http://www.bbc.co.uk/ontologies/sport/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

:mens_sprint a sport:MultiStageCompetition;
rdfs:label "Men's Sprint";
sport:award <#gold_medal> .
<#gold_medal> a sport:Award;
sport:awarded_to [
a foaf:Agent ;
foaf:name "Chris Hoy" .
] .
</nowiki>

====Alternative scenario: selective update of a resource====
This relates to user-story [[#Data Catalogs|Data Catalogs]], based on the [http://vocab.deri.ie/dcat Data Catalog Vocabulary].
A catalogue is described by the following RDF model.

<nowiki>
@prefix dcat: <http://www.w3.org/ns/dcat#> .
@prefix dcterms: <http://purl.org/dc/terms/> .

:catalog a dcat:Catalog ;
dcat:dataset :dataset/001;
dcterms:issued "2012-12-11"^^xsd:date.
</nowiki>

A catalog may contain multiple datasets, so when linking to new datasets it would be simpler and preferable to selectively add just the new dataset links.
A Talis ''changeset'' [http://docs.api.talis.com/getting-started/changesets][http://www.w3.org/2009/12/rdf-ws/papers/ws07] could be used to add a new <nowiki>dc:title</nowiki> to the dataset. The following update would be directed to the catalogue to add an additional dataset.

<nowiki>
@prefix : <http://example.com/>.
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix cs: <http://purl.org/vocab/changeset/schema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.

<change1>
a cs:ChangeSet ;
cs:subjectOfChange :catalog ;
cs:createdDate "2012-01-01T00:00:00Z" ;
cs:changeReason "Update catalog datasets" ;
cs:addition [
a rdf:Statement ;
rdf:subject :catalog ;
rdf:predicate dcat:dataset ;
rdf:object :dataset/002 .
] .
</nowiki>

===UC5: Determine if a resource has changed===
It should be possible to retrieve versioning information about a resource (e.g. last modified or entity tag) without having to download a representation of the resource.
This information can then be compared with previous information held about that resource to determine if it has changed.
This versioning information can also be used in subsequent ''conditional'' requests to ensure they are only applied if the version is unchanged.

====Primary scenario====
Based on the user-story, [[#Constrained Devices and Networks| Constrained Devices and Networks]], an LDP could be configured to act as a proxy for a [http://tools.ietf.org/html/draft-ietf-core-coap CoAP] based [http://en.wikipedia.org/wiki/Web_of_Things Web of Things]. As an observer of CoAP resources, the LDP registers its interest so that it will be notified whenever the sensor reading changes. Clients of the LDP can interrogate the LDP to determine if the state has changed.

In this example, the information about a sensor and corresponding sensor readings can be represented as RDF resources. The first resource below, represents a sensor described using the [http://www.w3.org/2005/Incubator/ssn/ Semantic Sensor Network] ontology.
<nowiki>
@prefix : <http://example.com/energy-management/>.

<> a :MainsFrequencySensor;
rdfs:comment "Sense grid load based on mains frequency";
ssn:hasMeasurementCapability [
a :FrequencyMeasurementCapability;
ssn:hasMeasurementProperty <#property_1> .
] .
</nowiki>

The value of the sensor changes in real-time as measurements are taken. The LDP client can interrogate the resource below to determine if it has changed, ''without'' necessarily having to download the RDF representation. As different sensor properties are represented disjointly (separate RDF representations) they may change independently.

<nowiki>
@prefix : <http://example.com/energy-management/>.

<http://example.com/energy-management#property_1> :hasMeasurementPropertyValue <> .
<> a :FrequencyValue;
:hasQuantityValue "50"^^xsd:float.
</nowiki>

===UC6: Aggregate resources===
There is a requirement to be able to manage ''collections'' of resources. The concept of a collection overlaps with, but is distinct from that of a container. These collections are (weak) aggregations, unrelated to the lifecycle management of resources, and distinct from the ownership between a resource and its container. However, the composition of a container may be reflected as a collection to support navigation of the container and its contents. There is a need to be able to create collections by adding and deleting individual membership properties. Resources may belong to multiple collections, or to none.

* Resource descriptions are a "mix of simple data and collections" (from [[#Keeping Track of Personal and Business Relationships]]).
* Relative URIs: It should be possible to "ship payloads of RDF" for a collection as a whole without breaking internal links (from [[#Constrained Devices and Networks]]).

====Primary scenario: add a resource to a collection====
This example is from [[#Library Linked Data|Library Linked Data]] and [http://www.w3.org/2005/Incubator/lld/wiki/UseCaseReport LLD-UC], specifically [http://www.w3.org/2005/Incubator/lld/wiki/Use_Case_Subject_Search Subject Search].

There is an existing collection at <nowiki><http://example.com/concept-scheme/subject-heading></nowiki> that defines a collection of subject headings. This collection is defined as a skos:ConceptScheme and
the client wishes to insert a new concept into the scheme. which will be related to the collection via a <nowiki>skos:inScheme</nowiki> link. The new subject-heading, "outer space exploration", is not necessarily owned by a container. The following RDF would be added to the (item-level) description of the collection.

<nowiki>
@prefix scheme : <http://example.com/concept-scheme/>.
@prefix concept : <http://example.com/concept/>.

scheme:subject-heading a skos:ConceptScheme.

concept:Outer+space+Exploration skos:inScheme scheme:subject-heading.
</nowiki>

====Alternative scenario: add a resource to multiple collections====
Logically, a resource should not be owned by more than one container. however, it may be a member of multiple collections which define a weaker form of ''aggregation''. As this is simply a manipulation of the RDF description of a collection, it should be possible to add the same resource to multiple collections.

As a machine-readable collection of medical terms, the [http://www.ihtsdo.org| SNOMED] ontology is of key importance in [[#Healthcare | healthcare]]. SNOMED CT allows concepts with more than one parent that don't fall into a lattice.
In the example below, the same concept may fall under two different parent concepts.
The example uses skos:narrowerTransitive to elide intervening concepts.

<nowiki>
@prefix : <http://example.com/snomed/>.

:_119376003 a skos:Concept ;
skos:prefLabel "Tissue specimen"
skos:narrowerTransitive :TissueSpecimenFromHeart.

:_127462005 a skos:Concept ;
skos:prefLabel "Specimen from heart"
skos:narrowerTransitive :TissueSpecimenFromHeart.

:_128166000 a skos:Concept;
rdfs:label "Tissue specimen from heart".
</nowiki>

===UC7: Filter resource description===
This use-case extends the normal behaviour of retrieving an RDF description of a resource, by dynamically excluding specific (membership) properties.
For containers, it is often desirable to be able to read a collection, or item-level description that excludes the container membership.

====Primary scenario: retrieve collection-level description====
This scenario, based on [[#Library Linked Data| Library Linked Data]], uses the Dublin Core Metadata Initiative [http://dublincore.org/groups/collections/collection-application-profile/| Collection-Level] description.
A collection can refer to any aggregation of physical or digital items.
This scenario covers the case whereby a client can request a collection-level description as typified by the example below, without necessarily having to download a full listing of the items within the collection.

<nowiki>
@prefix rdf: <rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">.
@prefix dc: <http://purl.org/dc/elements/1.1/>.
@prefix : <http://example.org/bookshelf/>.
@prefix dcmitype: <http://purl.org/dc/dcmitype/>.
@prefix cld: <http://purl.org/cld/terms/>.
@prefix dcterms: <http://purl.org/dc/terms/>.

<> dc:type dcmitype:Collection ;
dc:title "Directory of organizations working with Linked Data" ;
dcterms:abstract "This is a directory of organisations specializing in Linked Data."
cld:isLocatedAt <http://dir.w3.org>
cld:isAccessedVia <http://dir.w3.org/rdf/2012/directory/directory-list.xhtml?construct>
</nowiki>

====Alternative scenario: retrieve item-level description of a collection====
This use-case scenario, also based on [[#Library Linked Data| Library Linked Data]], focuses on obtaining an item-level description of the resources aggregated by a collection.
The simplest scenario is where the members of a collection are returned within a single representation, so that a client can explore the data by following these links. Different applications may use different membership predicates to capture this aggregation. The example below uses <nowiki>rdfs:member</nowiki>, but many different membership predicates are in common use, including RDF Lists.
Item-level descriptions can be captured using the Functional Requirements for Bibliographic Records ([http://www.ifla.org/publications/functional-requirements-for-bibliographic-records FRBR]) [http://vocab.org/frbr/core.html ontology].

<nowiki>
@prefix frbr: <http://purl.org/vocab/frbr/core#>.

<> rdfs:member <#ebooks97>, <#ebooks21279>.

<#work97> a frbr:LiteraryWork;
dc:title "Flatland: a romance of many dimensions" ;
frbr:creator <#Abbott_Edwin>;
frbr:manifestation <ebook97>.

<#work21279> a frbr:LiteraryWork;
dc:title "2 B R 0 2 B" ;
frbr:creator <#Vonnegut_Kurt>;
frbr:manifestation <ebook21279>.
</nowiki>

Collections are potentially very large, so some means may be required to limit the size of RDF representation returned by the LDP (e.g. pagination).

===UC8: Manage media resources===
It should be possible to easily add non-RDF media resources to containers that accept them. Media resources may be updated and removed during the lifecycle of the container.

====Primary scenario: access media resources====
From the User Story [[#Sharing Binary Resources and Metadata| Sharing Binary Resources and Metadata]] it should be possible to easily add non RDF resources to a containers that accept them. Clients submit a non-RDF representation to a container in a media type accepted by that container. The container creates a URI to represent this media resource, and creates a link from the container to the new URI.The media resource may have an explicit representation of the media type. It should be possible to find the metadata about such a resource and to access and edit it in the usual ways.

This example uses the [http://www.w3.org/TR/mediaont-10/#ont-ttl Ontology for Media Resources] to describe a media resource added to a collection.
<nowiki>
@prefix ma: <http://www.w3.org/ns/ma-ont#> .

<dataset> a ma:Collection ;
:hasMember <dataset/image1.jpg>

<dataset/image1.jpg> a ma:MediaResource ;
ma:hasFormat "image/jpeg" .
</nowiki>

====Alternative scenario: media-resource attachments====
A resource may have multiple ''renditions''; the idea that you can have a PDF and a JPEG representing the same thing. A user is trying to create a work order along with an attached image showing a faulty machine part. To the user and to the work order system, these two artifacts are managed as a set. A single request may create the work order, the attachment, and the relationship between them, atomically.
When the user retrieves the work order later, they expect a single request by default to retrieve the work order plus all attachments.
When the user updates the work order, e.g. to mark it completed, they only want to update the work order proper, not its attachments.
Users may add/remove/replace attachments to the work order during its lifetime.

== Requirements ==

===Functional Requirements===
# Create Containers, from [[#UC1: Manage containers]]
# Creation of nested containers, from [[#UC1: Manage containers]]
# Creation of resources (within a container), from [[#UC2: Manage resources]]
# Deletion of resources, from [[#UC2: Manage resources]]
# Moving contained resources, from [[#UC2: Manage resources]]
# Retrieve resource description, from [[#UC3: Retrieve resource description]]
# Retrieve description of a non-document resource, from [[#UC3: Retrieve resource description]]
# Enrichment (substituting update of existing resource), from [[#UC4: Update existing resource]]
# Selective update of a resource, from [[#UC4: Update existing resource]]
# Determine if a resource has changed, from [[#UC5: Determine if a resource has changed]]
# Add a resource to a collection, from [[#UC6: Aggregate resources]]
# Add a resource to multiple collections, from [[#UC6: Aggregate resources]]
# Retrieve collection-level description, from [[#UC7: Filter resource description]]
# Retrieve item-level description of a collection, from [[#UC7: Filter resource description]]
# Access media resources, from [[#UC8: Manage media resources]]
# Media-resource attachments, from [[#UC8: Manage media resources]]

===Non-Functional Requirements===

# Provide access guidance to resources, from [[#UC1: Manage containers]]
# Non-duplication of resources, from [[#UC2: Manage resources]]
# Distribution of resources, from [[#UC2: Manage resources]]
# Consistent, global naming, from [[#UC2: Manage resources]]
# Use standard vocabularies as appropriate, from [[#UC3: Retrieve resource description]]
# Scalable linking model, from [[#UC3: Retrieve resource description]]
# Unrestricted vocabulary, from [[#UC4: Update existing resource]]
# Resource descriptions are a "mix of simple data and collections", from [[#UC6: Aggregate resources]]
# Relative URIs enabling sharing of collections, from [[#UC6: Aggregate resources]]

== Acknowledgements ==
We would like to acknowledge the contributions of user-story authors; Christophe Guéret, Roger Menday, Eric Prud'hommeaux, Steve Speicher.

== References ==

Use Cases And Requirements

Sbattle2 — Mon, 10 Dec 2012 14:04:54 GMT

Sbattle2: /* To Be Done */

= Linked Data Platform Use Cases And Requirements =

This is a working document used to collect use cases and requirements for consideration by the WG.
The starting point comes from [http://www.w3.org/Submission/2012/SUBM-ldbpucr-20120326/ Linked Data Basic Profile Use Cases and Requirements].

== Steps to Complete ==

* <strike>Nov 26? WG to confirm User Story content: add, remove, refine (see process below). Note: this is ONLY User Stories (not Use Cases, Use Case Scenarios or Requirements)</strike>
** Issues before Nov 26th? will be included into FPWD
* Editors to:
** <strike>Dec 3 refine User Stories based on feedback</strike>
** <strike>Dec 5 elaborate on Use Cases in support of User Stories</strike>
* Dec 10 - WG to review prior to FPWD
** Review period ends Dec 15th
** insert open issues into draft for FPWD
* Dec 17 - Publish FPWD
** convert wiki page to ReSpec for FPWD
* Dec ?? Deadline for publications by year end 2012

===To Be Done===
* <strike>Move [[#LDP_and_Authentication.2FAuthorization| LDP and Authentication]] to [http://www.w3.org/2012/ldp/wiki/AccessControl AccessControl]</strike>
* <strike>Complete [[#Alternative_scenario:_moving_contained_resources| moving contained resources]] scenario with content from ericP on issue-30.</strike>
* <strike>Augment [[#Cloud_Infrastructure_Management| Cloud Infrastructure Management]] scenario with content from Roger Menday.</strike>
* <strike>Ensure issue-40/41 are fully covered in [[#UC8:_Managing_non-RDF_Resources| UC8: Managing non-RDF Resources]]. 2 scenarios (single v multiple attachments) ?</strike>
* <strike>Contact owner of [[#Data_Sharing| Data Sharing]] user-story to determine if we keep or not.</strike>
* <strike>Review [[#Requirements| Requirements]] section for functional/non-functional requirements arising in UCs.</strike>
* <strike>Propose resolutions to open issues against UC&R where possible.</strike>
* <strike>Identify and acknowledge user-story contributors.</strike>
* <strike>Check hyperlinks</strike>
* Convert to ReSpec
* Annotate document with open issues against UC&R
** [http://www.w3.org/2012/ldp/track/issues/30 ISSUE-30] (OPEN)
** [http://www.w3.org/2012/ldp/track/issues/40 ISSUE-40] (RAISED)
** [http://www.w3.org/2012/ldp/track/issues/41 ISSUE-41] (RAISED)

=== Process to introduce new User Stories & Use Cases ===

Open an Issue in the tracker against the UC&R product. The WG will review these and decide whether they are valid.

== Scope and Motivation ==

Linked Data was defined by Tim Berners-Lee with the following guidelines [http://www.w3.org/DesignIssues/LinkedData.html]:

# Use URIs as names for things
# Use HTTP URIs so that people can look up those names
# When someone looks up a URI, provide useful information, using the standards (RDF*, SPARQL)
# Include links to other URIs. so that they can discover more things

These four rules have proven very effective in guiding and inspiring people to publish Linked Data on the web. The amount of data, especially public data, available on the web has grown rapidly, and an impressive number of extremely creative and useful “mashups” have been created using this data as result.

There has been much less focus on the potential of Linked Data as a model for managing data on the web - the majority of the Application Programming Interfaces (APIs) available on the Internet for creating and updating data follow a Remote Procedure Call (RPC) model rather than a Linked Data model.

If Linked Data were just another model for doing something that RPC models can already do, it would be of only marginal interest. Interest in Linked Data arises from the fact that applications with an interface defined using Linked Data can be much more easily and seamlessly integrated with each other than applications that offer an RPC interface. In many problem domains, the most important problems and the greatest value are found not in the implementation of new applications, but in the successful integration of multiple applications into larger systems.

Some of the features that make Linked Data exceptionally well suited for integration include:

* A single interface – defined by a common set of HTTP methods – that is universally understood and is constant across all applications. This is in contrast with the RPC architecture where each application has a unique interface that has to be learned and coded to.
* A universal addressing scheme – provided by HTTP URLs – for both identifying and accessing all “entities”. This is in contrast with the RPC architecture where there is no uniform way to either identify or access data.
* A simple yet extensible data model – provided by RDF – for describing data about a resource in a way which doesn’t require prior knowledge of vocabulary being used.

Experience implementing applications and integrating them using Linked Data has shown very promising results, but has also demonstrated that the original four rules defined by Tim Berners-Lee for Linked Data are not sufficient to guide and constrain a writable Linked Data API. As was the case with the original four rules, the need generally is not for the invention of fundamental new technologies, but rather for a series of additional rules and patterns that guide and constrain the use of existing technologies in the construction of a Basic Profile for Linked Data to achieve interoperability.

The following list illustrates a few of the issues that require additional rules and patterns:
* What URLs do I post to in order to create new resources?
* How do I get lists of existing resources, and how do I get basic information about them without having to access each one?
* How should I detect and deal with race conditions on write?
* What media-types/representations should I use?
* What standard vocabularies should I use?
* What primitive data types should I use?

A good goal for the Basic Profile for Linked Data would be to define a specification required to allow the definition of a writable Linked Data API equivalent to the simple application APIs that are often written on the web today using the Atom Publishing Protocol (APP). APP shares some characteristics with Linked Data, such as the use of HTTP and URLs. One difference is that Linked Data relies on a flexible data model with RDF, which allows for multiple representations.

== Organization of this Document ==

This document is organized as follows:

* '''[[#User Stories| User Stories]]''' capture statements about system requirements written from a user or application perspective. They are typically lightweight and informal and can run from one line to a paragraph or two (sometimes described as an 'epic') [http://www.agilemodeling.com/artifacts/userStory.htm]. Analysis of each user story will reveal a number of (functional) use-cases and other non-functional requirements. See [http://www.w3.org/TR/dap-policy-reqs/| Device API Access Control Use Cases and Requirements] for a good example of user stories and their analysis.

* '''[[#Use Cases| Use Cases]]''' are used to capture and model functional requirements. Use cases describe the system’s behavior under various conditions [http://alistair.cockburn.us/get/2465], cataloguing who does what with the system, for what purpose, but without concern for system design or implementation [http://www.bredemeyer.com/pdf_files/functreq.pdf]. Each use case is identified by a reference number to aid cross-reference from other documentation; use-case indexing in this document is based on [http://www.w3.org/TR/rdb2rdf-ucr/ rdb2rdf use-cases]. A variety of styles may be used to capture use-cases, from a simple narrative to a structured description with actors, pre/post conditions, and step-by-step behaviours as in [http://www.w3.org/TR/powder-use-cases/ POWDER: Use Cases and Requirements], and non-functional requirements raised by the use-case. Use cases act like the hub of a wheel, with spokes supporting requirements analysis, scenario-based evaluation, testing, and integration with non-functional, or quality requirements.

* '''Scenarios''' are more focused still, representing a single instance of a use case in action. Scenarios may range from lightweight narratives as seen in [http://www.w3.org/TR/media-frags-reqs/ Use cases and requirements for Media Fragments], to being formally modeled as interaction diagrams. Each use-case should include at least a primary scenario, and possibly other alternative scenarios.

* '''[[#Requirements| Requirements]]''' list non-functional or quality requirements, and the use cases they may be derived from. This approach is exemplified in the [http://dvcs.w3.org/hg/gld/raw-file/default/dcat-ucr/index.html Use Cases and Requirements for the Data Catalog Vocabulary].

== User Stories ==

=== Maintaining Social Contact Information ===

Many of us have multiple email accounts that include information about the people and organizations we interact with – names, email addresses, telephone numbers, instant messenger identities and so on. When someone’s email address or telephone number changes (or they acquire a new one), our lives would be much simpler if we could update that information in one spot and all copies of it would automatically be updated. In other words, those copies would all be linked to some definition of “the contact.” There might also be good reasons (like off-line email addressing) to maintain a local copy of the contact, but ideally any copies would still be linked to some central “master.”

Agreeing on a format for “the contact” is not enough, however. Even if all our email providers agreed on the format of a contact, we would still need to use each provider’s custom interface to update or replace the provider’s copy, or we would have to agree on a way for each email provider to link to the “master”. If we look outside our own personal interests, it would be even more useful if the person or organization exposed their own contact information so we could link to it.

What would work in either case is a common understanding of the resource, a few formats needed, and access guidance for these resources. This would support how to acquire a link to a contact, and how to use those links to interact with a contact (including [[#UC3: Retrieve resource description|reading]], [[#UC4: Update existing resource|updating]], and [[#Alternative scenario: delete resource|deleting]] it), as well as how to easily [[#Primary scenario: create resource|create a new contact]] and add it to my contacts and when deleting a contact, how it would be removed from my list of contacts. It would also be good to be able to add some application-specific data about my contacts that the original design didn’t consider. Ideally we’d like to eliminate multiple copies of contacts, there would be additional valuable information about my contacts that may be stored on separate servers and need a simple way to link this information back to the contacts. Regardless of whether a contact collection is my own, shared by an organization, or all contacts known to an email provider (or to a single email account at an email provider), it would be nice if they all worked pretty much the same way.

=== Keeping Track of Personal and Business Relationships ===

In our daily lives, we deal with many different organizations in many different relationships, and they each have data about us. However, it is unlikely that any one organization has all the information about us. Each of them typically gives us access to the information (at least some of it), many through websites where we are uniquely identified by some string – an account number, user ID, and so on. We have to use their applications to interact with the data about us, however, and we have to use their identifier(s) for us. If we want to build any semblance of a holistic picture of ourselves (more accurately, collect all the data about us that they externalize), we as humans must use their custom applications to find the data, copy it, and organize it to suit our needs.

Would it not be simpler if at least the Web-addressable portion of that data could be linked to consistently, so that instead of maintaining various identifiers in different formats and instead of having to manually supply those identifiers to each one’s corresponding custom application, we could essentially build a set of bookmarks to it all? When we want to [[#UC3: Retrieve resource description|examine]] or [[#UC4: Update existing resource|change]] their contents, would it not be simpler if there were a single consistent application interface that they all supported? Of course it would.

Our set of links would probably be a [[#UC6: Aggregate resources|simple collection]]. The information held by any single organization might be a mix of simple data and [[#UC6: Aggregate resources|collections of other data]], for example, a bank account balance and a collection of historical transactions. Our bank might easily have [[#Alternative scenario: create a nested container|a collection of accounts for each of its collection of customers]].

=== System and Software Development Tool Integration ===

System and software development tools typically come from a diverse set of vendors and are built on various architectures and technologies. These tools are purpose built to meet the needs for a specific domain scenario (modeling, design, requirements and so on.) Often tool vendors view integrations with other tools as a necessary evil rather than providing additional value to their end-users. Even more of an afterthought is how these tools’ data -- such as people, projects, customer-reported problems and needs -- integrate and relate to corporate and external applications that manage data such as customers, business priorities and market trends. The problem can be isolated by standardizing on a small set of tools or a set of tools from a single vendor, but this rarely occurs and if does it usually does so only within small organizations. As these organizations grow both in size and complexity, they have needs to work with outsourced development and diverse internal other organizations with their own set of tools and processes. There is a need for better support of more complete business processes (system and software development processes) that span the roles, tasks, and data addressed by multiple tools. This demand has existed for many years, and the tools vendor industry has tried several different architectural approaches to address the problem. Here are a few:

* Implement an API for each application, and then, in each application, implement “glue code” that exploits the APIs of other applications to link them together.
* Design a single database to store the data of multiple applications, and implement each of the applications against this database. In the software development tools business, these databases are often called “repositories.”
* Implement a central “hub” or “bus” that orchestrates the broader business process by exploiting the APIs described previously.

It is fair to say that although each of those approaches has its adherents and can point to some successes, none of them is wholly satisfactory. The use of Linked Data as an application integration technology has a strong appeal. [http://open-services.net/ OSLC]

=== Library Linked Data ===

The W3C Library Linked Data working group has a number of use cases cited in their Use Case Report. [http://www.w3.org/2005/Incubator/lld/wiki/UseCaseReport LLD-UC] These referenced use cases focus on the need to extract and correlate library data from disparate sources. Variants of these use cases that can provide consistent formats, as well as ways to improve or update the data, would enable simplified methods for both efficiently sharing this data as well as producing incremental updates without the need for repeated full extractions and import of data.

The 'Digital Objects Cluster' contains a number of relevant use-cases:

* Grouping: This should "Allow the end-users to define [[#UC6: Aggregate resources|groups of resources]] on the web that for some reason belong together. The relationship that exists between the resources is often left unspecified. Some of the resources in a group may not be under control of the institution that defines the groups."

* Enrichment: "Enable end-users to [[#UC4: Update existing resource|link resources together]]."

* Browsing: "[[#UC7: Filter resource description|Support end-user browsing through groups]] and resources that belong to the groups."

* Re-use: "Users should have the capability to re-use all or parts of a collection, with all or part of its metadata, elsewhere on the linked Web."

The 'Collections' cluster also contains a number of relevant use-cases:

* Collection-level description: "Provide [[#UC7: Filter resource description|metadata pertaining to a collection as a whole]], in contrast to item-level description."

* Collections discovery: "Enable innovative collection discovery such as identification of nearest location of a physical collection where a specific information resource is found or mobile device applications ... based on collection-level descriptions."

* Community information services: Identify and classify collections of special interest to the community.

=== Municipality Operational Monitoring ===

Across various cities, towns, counties, and various municipalities there is a growing number of services managed and run by municipalities that produce and consume a vast amount of information. This information is used to help monitor services, predict problems, and handle logistics. In order to effectively and efficiently collect, produce, and analyze all this data, a fundamental set of loosely coupled standard data sources are needed. A simple, low-cost way to [[#UC3: Retrieve resource description|expose data]] from the diverse set of monitored services is needed, one that can easily integrate into the municipalities of other systems that inspect and analyze the data. All these services have links and dependencies on other data and services, so having a simple and scalable linking model is key.

=== Healthcare ===

For physicians to analyze, diagnose, and propose treatment for patients requires a vast amount of complex, changing and growing knowledge. This knowledge needs to come from a number of sources, including physicians’ own subject knowledge, consultation with their network of other healthcare professionals, public health sources, food and drug regulators, and other repositories of medical research and recommendations.

To diagnose a patient’s condition requires current data on the patient’s medications and medical history. In addition, recent pharmaceutical advisories about these medications are linked into the patient’s data. If the patient experiences adverse affects from medications, these physicians need to publish information about this to an appropriate regulatory source. Other medical professionals require access to both validated and emerging effects of the medication. Similarly, if there are geographical patterns around outbreaks that allow both the awareness of new symptoms and treatments, this information needs to quickly reach a very distributed and diverse set of medical information systems. Also, reporting back to these regulatory agencies regarding new occurrences of an outbreak, including additional details of symptoms and causes, is critical in producing the most effective treatment for future incidents.

=== Metadata Enrichment in Broadcasting ===

There are many different use cases when broadcasters show interest in metadata [[#UC4: Update existing resource| enrichment]]:

* enrich archive or news metadata by linking facts, events, locations and personalities
* enrich metadata generated by automatic extraction tools such as person identification, etc.
* enrich definitions of terms in classification schemes or enumeration lists

This comes in support of more effective information management and data/content mining (if you can't find your content, it' like if you don't have and must either recreate or acquire it again, which is not financially effective).

However, there is a need for solutions facilitating linkage to other data sources and taking care of the issues such as discovery, automation, disambiguation. Etc. Other important issues that broadcasters would face are the editorial quality of the linked data, its persistence, and usage rights.

=== Aggregation and Mashups of Infrastructure Data ===

For infrastructure management (such as storage systems, virtual machine environments, and similar IaaS and PaaS concepts), it is important to provide an environment in which information from different sources can be [[#UC6: Aggregate resources|aggregated]], [[#UC7: Filter resource description|filtered]], and visualized effectively. Specifically, the following use cases need to be taken into account:

* While some data sources are based on Linked Data, others are not, and aggregation and mashups must work across these different sources.
* Consumers of the data sources and aggregated/filtered data streams are not necessarily implementing Linked Data themselves, they may be off-the-shelf components such as dashboard frameworks for composing visualizations.
* Simple versions of this scenario are pull-based, where the data is requested from data sources. In more advanced settings, without a major change in architecture it should be possible to move to a push-based interaction model, where data sources push notifications to subscribers, and data sources provide different services that consumers can subscribe to (such as "informational messages" or "critical alerts only").

In this scenario, the important factors are to have abstractions that allow easy aggregation and filtering, are independent from the internal data model of the sources that are being combined, and can be used for pull-based interactions as well as for push-based interactions.

=== Sharing payload of RDF data among low-end devices ===

Several projects around the idea of [http://worldwidesemanticweb.wordpress.com/ downscaling the Semantic Web] need to be able to ship payloads of RDF across the nodes member of a given network. The transfers are done in a constrained context in terms of bandwidth, scope of the local semantics employed by the nodes and computing capabilities of the nodes. In a P2P style, every node has the capability to act either as a data consumer or a data provider, serving its own data or acting as a relay to pass other's data along (typically in mesh networks).

The transfer of an arbitrary payload of RDF data could be implemented through the container mechanism, adding and removing sets of RDF triples to it. Currently, one of the project "SemanticXO" uses named graphs and the graph protocol to create/delete/copy graphs across the nodes but this (almost) imposes the usage of a triple store. Unfortunately, triple store are rather demanding piece of software that are not always usable on limited hardware. Some generic ReST like interaction backed up with a lightweight column store would be better approach.

=== Sharing Binary Resources and Metadata ===

When publishing datasets about stars one may want to publish links to the pictures in which those stars appear, and this may well require publishing the pictures themselves. Vice versa: when publishing a picture of space we need to know which telescope took the picture, which part of the sky it was pointing at, what filters were used, which identified stars are visible, who can read it, who can write to it, ...

If LinkedData contains information about resources that are most naturally expressed in non-rdf formats (be they binary such as pictures or videos, or human readable documents in XML formats), those non RDF formats should be just as easy to publish to the LinkedData server as the RDF relations that link those resources up. A LinkedData server should therefore allow publishing of non linked data resources too, and make it easy to publish and edit metadata about those resources.

The resource comes in two parts - the image and information about the image (which may in the image file but better external to it as it's more general). The information about the image is vital. It's a compound item of image data and other data (being application metadata about the image does not distinguish from the platform's point-of-view.

=== Data Catalogs ===

The Asset Description Metadata Schema ([http://joinup.ec.europa.eu/asset/adms/home ADMS]) provides the data model to describe semantic assets repositories contents, but this leaves many open challenges when building a federation of these repositories to serve the need of assets reuse. These include accessing and querying individual repositories and efficiently retrieving [[#UC5: Determine if a resource has changed| updated content]] without having to retrieve the whole content. Hence, we chose to build the integration solution capitalizing on the Data Warehousing integration approach. This allows us to cope with heterogeneity of sources technologies and to benefit from the optimized performance it offers, given that individual repositories do not usually change frequently. With Data Warehousing, the federation requires to:

* understand the data, i.e. understand their semantic descriptions, and other systems.
* seamlessly exchange the semantic assets metadata from different repositories
* keep itself up-to-date.

Repositories owners can maintain de-referenceable URIs for their repository description and contained assets in a Linked Data compatible manner. ADMS provides the necessary data model to enable meaningful exchange of data. However, This leaves the challenge of efficient access to the data not fully addressed.

Related: [http://spec.datacatalogs.org/ Data Catalog Schema and Protocol]

=== Constrained Devices and Networks ===

Information coming from resource constrained devices in the Web of Things ([http://en.wikipedia.org/wiki/Web_of_Things WoT]) has been identified as a major driver in many domains, from smart cities to environmental monitoring to real-time tracking. The amount of information produced by these devices is growing exponentially and needs to be accessed and integrated in a systematic, standardized and cost efficient way. By using the same standards as on the Web, integration with applications will be simplified and higher-level interactions among resource constrained devices, abstracting away heterogeneities, will become possible. Up-coming IoT/WoT standards such as [http://datatracker.ietf.org/wg/6lowpan/ 6LowPAN] - IPv6 for resource constrained devices - and the Constrained Application Protocol ([http://tools.ietf.org/html/draft-ietf-core-coap CoAP]), which provides a downscaled version of HTTP on top of UDP for the use on constrained devices, are already at a mature stage. The next step now is to support RESTful interfaces also on resource constrained devices, adhering to the Linked Data principles. Due to the limited resources available, both on the device and in the network (such as bandwidth, energy, memory) a solution based on SPARQL Update is at the current point in time considered not to be useful and/or feasible. An approach based on the [http://tools.ietf.org/html/draft-castellani-core-http-mapping HTTP-CoAP Mapping] would enable constrained devices to directly participate in a Linked Data-based environment.

=== Services Supporting the Process of Science ===
Many fields of science now include branches with in silico data-intensive methods, e.g. bioinformatics, astronomy. To support these new methods we look to move beyond the established platforms provided by scientific workflow systems to capture, assist, and preserve the complete lifecycle from record of the experiment, through local trusted sharing, analysis, dissemination (including publishing of experimental data "beyond the PDF"), and re-use.

* [[#UC6: Aggregate resources|Aggregations]], specifically ''Research Objects (ROs)'' that are exchanged between services and clients bringing together workflows, data sets, annotations, and provenance. We use an RDF model for this. While some aggregated contents are encoded using RDF and in increasing number are linked data sources, others are not; while some are stored locally "within" the RO, others are remote (in both cases this is often due to size of the resources or access policies).
* Services that are distributed and linked. Some may be centralising for e.g. publication, others may be local, e.g. per lab. We need lightweight services that can be simply and easily integrated into and scale across the wide variety of softwares and data used in science: we have adopted a RESTful approach where possible.
** Foundation services that collect and expose ROs for storage, modification, exploration, and reuse.
** Services that provide added-value to ROs such as seamless import/export from scientific workflow systems, automated stability evaluation, or recommendation (and therefore interact with the foundation services to retrieve/store/modify/ROs).

seeAlso: [http://www.wf4ever-project.org/ Wf4Ever]

=== Project Membership Information : Information Evolution ===

Information about people and projects changes as roles change, as organisations change
and as contact details change. Finding the current state of a project is important
in enabling people to contact the right person in the right role. It can also be
useful to look back and see who was performing what role in the past.

A use of a Linked Data Platform could be to give responsibility for managing
such information with the project team itself, not requiring updates to be
requested of a centralised website administrator.

This could be achieved with:

* Resource descriptions for each person and project
* A container resource to describe roles/membership in the project.

To retain the history of the project, the old version of a resources,
including container resources, should be retained so there is a need to address both specific items
and also have a notion of "current".

Access to information has two aspects:
* Access to the "current" state, regardless of the version of the resource description
* Access to historical state, via access to a specific version of the resource description

=== Cloud Infrastructure Management===

Cloud operators offer API support to provide customers with remote access for the management of Cloud infrastructure (IaaS). Infrastructure consists of Systems, Computers, Networks, Discs, etc. The overall structure can be seen as mostly hierarchical, (Cloud contains Systems, Systems contain Machines, etc), complemented with crossing links (e.g. multiple Machines connected to a Network).

The IaaS scenario makes specific requirements on lifecycle management and discovery, handling non-instant changes, history capture and query:

* Many aspects of Cloud infrastructure have associated lifecycle, e.g. a Computer can be transitioned between Running and Shutdown. This should be manageable through the API, which should include how a client discovers dynamic lifecycle options and thus help steering through an application.
* It is often the case that attaining a new lifecycle state is not instantaneous. Clients require a universal mechanism for monitoring such changes.
* A facility to retrieve all events in the lifecycle of a resource can be useful.
* Query provides the means to interrogate the resources behind the API, as well as finding new entry points into the application.

Infrastructure management may be viewed as the manipulation of the underlying graph of resources.

== Use Cases ==
The following use-cases are each derived from one or more of the user-stories above. These use-cases are explored in detail through the development of scenarios, each motivated by some key aspect exemplified by a single user-story. The examples they contain are included purely for illustrative purposes, and should not be interpreted normatively.

===UC1: Manage containers===
A number of user-stories introduce the idea of a ''container'' as a mechanism for creating and managing resources within the context of an application. Resources grouped together within the same container would typically belong to the same application. A container is identified by a URI so is a resource in its own right.
The properties of a container may also represent the ''affordances'' of that container, enabling clients to determine what other operations they can do on that container. These operations may include descriptions of application specific services that can be invoked by exchanging RDF documents.

* Provide "access guidance for ... resources" (affordances) (from user-story, [[#Maintaining Social Contact Information|Maintaining Social Contact Information]]).

====Primary scenario: create container====
Create a new container resource within the LDP server.
In [[#Services Supporting the Process of Science|Services supporting the process of science]], [http://wf4ever.github.com/ro-primer/ Research Objects] are semantically rich aggregations of resources that bring together data, methods and people in scientific investigations. A basic workflow research object will be created to aggegate [http://ceur-ws.org/Vol-903/paper-01.pdf scientific workflows] and the artefacts that result from this workflow. The research object begins life as an empty container into which workflows, datasets, results and other data will be added throughout the lifecycle of the project.

<nowiki>
@prefix ro: http://purl.org/wf4ever/ro#
@prefix dct: http://purl.org/dc/terms/
@prefix ore: http://www.openarchives.org/ore/

<> a ro:ResearchObject, ore:Aggregation ;
dct:created "2012-12-01"^^xsd:dateTime .
</nowiki>

====Alternative scenario: create a nested container====
The motivation for nested containers comes from the [[#System and Software Development Tool Integration| System and Software Development Tool Integration]] user-story. The OSLC Change Management vocabulary allows bug reports to have attachments referenced by the membership predicate <nowiki>oslc_cm:attachment</nowiki>. The 'top-level-container' contains issues, and each issue resource has its own container of attachment resources.

<nowiki>
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix oslc_cm: <http://open-services.net/ns/cm#>.
@prefix : <http://example.org/>.

:top-level-container rdfs:member :issue1234 .

:issue1234 a oslc_cm:ChangeRequest;
dcterms:identifier "1234";
dcterms:type "a bug";
dcterms:related :issue1235 ;
oslc_cm:attachments :attachments123.

:issue1235 a oslc_cm:ChangeRequest;
dcterms:title "a related bug".

:attachments a oslc_cm:AttachmentList;
oslc_cm:attachment :attachment324, :attachment251.
</nowiki>

===UC2: Manage resources===
This use-case addresses the managed lifecycle of a resource and is concerned with resource ''ownership''. The responsibility for managing resources belongs with their container.
For example, a container may accept a request from a client to make a new resource.
This use-case focuses on creation and deletion of resources in the context of a container, and the potential for transfer of ownership by moving resources between containers.
The ownership of a resource should always be clear; no resource managed in this way should ever be owned by more than one container.

Once a new resource has been created it should be identified by a URI. Clients may defer responsibility for establishing dereferenceable URIs to the container of their data.
The container is a natural choice for the endpoint for this interface as it will already have some application-specific knowledge about the contained resources.
While the LDP has ultimate control over resource naming, some applications may require more control over naming, perhaps to provide a more human-readable URI. An LDP server could support something like the [http://tools.ietf.org/html/rfc5023 Atom Publishing Protocol] slug header to convey a user defined naming 'hint'.

* Non-duplication of resources: "Eliminate multiple copies", representing resources in a single place (from [[#Maintaining Social Contact Information]]).
* Distribution of resources: Linked aata "may be stored on separate servers" (from [[#Maintaining Social Contact Information]]).
* Consistent, global naming: Resources should be "linked to consistently, ... instead of maintaining various identifiers in different formats" (from [[#Keeping Track of Personal and Business Relationships]]).

====Primary scenario: create resource====
Resources begin life by being created within a container. From user-story, [[#Maintaining Social Contact Information|Maintaining Social Contact Information]], It should be possible to "easily create a new contact and add it to my contacts." This suggests that resource creation is closely linked to the application context. The new resource is created in a container representing "my contacts." The lifecycle of the resource is linked to the lifecycle of it's container. So, for example, if "my contacts" is deleted then a user would also reasonably expect that all contacts within it would also be deleted.

Contact details are captured as an RDF description and it's properties, including "names, email addresses, telephone numbers, instant messenger identities and so on." The description may include non-standard RDF; "data about my contacts that the original design didn’t consider."
The following RDF could be used to describe contact information using the [http://www.foaf-project.org FOAF] vocabulary. A contact is represented here by a <nowiki>foaf:PersonalProfileDocument</nowiki> defining a resource that can be created and updated as a single-unit, even though it may describe ancillary resources, such as a <nowiki>foaf:Person</nowiki>, below.

<nowiki>
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

<> a foaf:PersonalProfileDocument;
foaf:PrimaryTopic [
a foaf:Person;
foaf:name "Timothy Berners-Lee";
foaf:title "Sir";
foaf:firstName "Timothy";
foaf:surname "Berners-Lee";
foaf:nick "TimBL", "timbl";
foaf:homepage <http://www.w3.org/People/Berners-Lee/>;
foaf:weblog <http://dig.csail.mit.edu/breadcrumbs/blog/4>;
foaf:mbox <mailto:timbl@w3.org>;
foaf:workplaceHomepage <http://www.w3.org/>.
]
</nowiki>

====Alternative scenario: delete resource====
Delete a resource and all it's properties. If the resource resides within a container it will be removed from that container, however other links to the deleted resource may be left as dangling references.
In the case where the resource is a container, the server may also delete any or all contained resources.
In normal practice, a deleted resource cannot be reinstated. There are however, edge-cases where limited undelete may be desirable.
Best practice states that "[http://www.w3.org/TR/cooluris/| Cool URIs don't change]", which implies that deleted URIs shouldn't be recycled.

====Alternative scenario: moving contained resources====
Many resources may have value beyond the life of their membership in a container. This implies methods to add references to revise container membership.
Cloning container members for use in other containers results in duplication of information and maintenance problems; web practice is to encourage the creation of one resource, which may be referenced as many places as necessary. A change of ownership may - or may not - imply a change of URI, depending upon the specific LDP naming policy. While assigning a new URI to a resource is discouraged [http://www.w3.org/DesignIssues/Architecture.html#HTTP], it is possible to indicate that a resource has moved with an appropriate HTTP response.

===UC3: Retrieve resource description===
Access the current description of a resource, containing properties of that resource and links to related resources. The representation may include descriptions of related resources that cannot be accessed directly.
Depending upon the application, an LDP may enrich the retrieved RDF with additional triples. Examples include adding incoming links, sameAs closure and type closure.
The HTTP response should also include versioning information (i.e. last update or entity tag) so that subsequent updates can ensure they are being applied to the correct version.

* Use standard vocabularies as appropriate to enable a "common understanding of the resource" (from [[#Maintaining Social Contact Information|Maintaining Social Contact Information]]).
* A "scalable linking model is key" (from [[#Municipality Operational Monitoring]]).

====Primary scenario====
The user-story [[#Project Membership Information : Information Evolution| Project Membership Information]] discusses the representation of information about people and projects. It calls for "Resource descriptions for each person and project" allowing project teams to review information held about these resources. The example below illustrates the kinds of information that might be held about organizational structures based on the [http://www.epimorphics.com Epimorphics] [http://www.epimorphics.com/public/vocabulary/org.html organizational ontology].

Note that the example below defines two resources (shown as separate sections below) that will be hosted on an LDP based at <nowiki>http://example.com/</nowiki>. The representations of these resources may include descriptions of related resources, such as <nowiki>http://www.w3.org/</nowiki>, that that fall under a different authority and therefore can't be served from the LDP at this location.

<nowiki>
@prefix org: <http://www.w3.org/ns/org#> .
@prefix owltime: <http://www.w3.org/2006/time> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@base <http://example.com/> .

<member1> a org:Membership ;
org:member <http://www.w3.org/People/Berners-Lee/card#i> ;
org:organization http://www.w3.org/> ;
org:role <director> ;
org:memberDuring [a owltime:Interval; owltime:hasBeginning [
owltime:inXSDDateTime "1994-10-01T00:00:00Z"^^xsd:dateTime]] .

<http://www.w3.org/> a org:FormalOrganization ;
skos:prefLabel "The World Wide Web Consortium"@en ;
skos:altLabel "W3C" .
</nowiki>

<nowiki>
@prefix org: <http://www.w3.org/ns/org#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@base <http://example.com/> .

<director> a org:Role ;
rdfs:label "Director" .
</nowiki>

====Alternative scenario: retrieve description of a non-document resource====
In many cases, the things that are of interest are not always the things that are resolvable. The example below demonstrates how a foaf profile may be used to distinguish between the person and the profile; the former being the topic of the latter. This begs the question as to what a client should do with such non-document resources. In this case the HTTP protocol requires that the fragment part be stripped off before requesting the URI from the server. The result is a resolvable URI for the profile.

<nowiki>
@base <http://www.w3.org/People/Berners-Lee/card>
@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@prefix dc: <http://purl.org/dc/elements/1.1/>.

<> a foaf:PersonalProfileDocument ;
dc:title "Tim Berners-Lee's FOAF file" ;
foaf:homepage <http://www.w3.org/People/Berners-Lee/> ;
foaf:primaryTopic <#i> .
</nowiki>

===UC4: Update existing resource===
Change the RDF description of a LDP resource, potentially removing or overwriting existing data. This allows applications to ''enrich'' the representation of a resource by addling additional links to other resources.

* Unrestricted vocabulary: It should be possible be "able to add ... application-specific data" to resources (from [[#Maintaining Social Contact Information]]).

====Primary scenario: enrichment====
This relates to user-story [[#Metadata Enrichment in Broadcasting| Metadata Enrichment in Broadcasting]] and is based on the [http://www.bbc.co.uk/ontologies/sport/ BBC Sports Ontology]. The ''resource-centric'' view of linked-data provides a natural granularity for substituting, or overwriting a resource and its data. The simplest kind of update would simply replace what is currently known about a resource with a new representation. There are two distinct resources in the example below; a sporting event and an associated award. The granularity of the LDP would allow a user to replace the information about the award without disturbing the information about the event.

<nowiki>
@prefix sport: <http://www.bbc.co.uk/ontologies/sport/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

:mens_sprint a sport:MultiStageCompetition;
rdfs:label "Men's Sprint";
sport:award <#gold_medal> .

<#gold_medal> a sport:Award .
</nowiki>

We can enrich the description as events unfold, linking to the winner of the gold medal by substituting the above description with the following.

<nowiki>
@prefix sport: <http://www.bbc.co.uk/ontologies/sport/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

:mens_sprint a sport:MultiStageCompetition;
rdfs:label "Men's Sprint";
sport:award <#gold_medal> .
<#gold_medal> a sport:Award;
sport:awarded_to [
a foaf:Agent ;
foaf:name "Chris Hoy" .
] .
</nowiki>

====Alternative scenario: selective update of a resource====
This relates to user-story [[#Data Catalogs|Data Catalogs]], based on the [http://vocab.deri.ie/dcat Data Catalog Vocabulary].
A catalogue is described by the following RDF model.

<nowiki>
@prefix dcat: <http://www.w3.org/ns/dcat#> .
@prefix dcterms: <http://purl.org/dc/terms/> .

:catalog a dcat:Catalog ;
dcat:dataset :dataset/001;
dcterms:issued "2012-12-11"^^xsd:date.
</nowiki>

A catalog may contain multiple datasets, so when linking to new datasets it would be simpler and preferable to selectively add just the new dataset links.
A Talis ''changeset'' [http://docs.api.talis.com/getting-started/changesets][http://www.w3.org/2009/12/rdf-ws/papers/ws07] could be used to add a new <nowiki>dc:title</nowiki> to the dataset. The following update would be directed to the catalogue to add an additional dataset.

<nowiki>
@prefix : <http://example.com/>.
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix cs: <http://purl.org/vocab/changeset/schema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.

<change1>
a cs:ChangeSet ;
cs:subjectOfChange :catalog ;
cs:createdDate "2012-01-01T00:00:00Z" ;
cs:changeReason "Update catalog datasets" ;
cs:addition [
a rdf:Statement ;
rdf:subject :catalog ;
rdf:predicate dcat:dataset ;
rdf:object :dataset/002 .
] .
</nowiki>

===UC5: Determine if a resource has changed===
It should be possible to retrieve versioning information about a resource (e.g. last modified or entity tag) without having to download a representation of the resource.
This information can then be compared with previous information held about that resource to determine if it has changed.
This versioning information can also be used in subsequent ''conditional'' requests to ensure they are only applied if the version is unchanged.

====Primary scenario====
Based on the user-story, [[#Constrained Devices and Networks| Constrained Devices and Networks]], an LDP could be configured to act as a proxy for a [http://tools.ietf.org/html/draft-ietf-core-coap CoAP] based [http://en.wikipedia.org/wiki/Web_of_Things Web of Things]. As an observer of CoAP resources, the LDP registers its interest so that it will be notified whenever the sensor reading changes. Clients of the LDP can interrogate the LDP to determine if the state has changed.

In this example, the information about a sensor and corresponding sensor readings can be represented as RDF resources. The first resource below, represents a sensor described using the [http://www.w3.org/2005/Incubator/ssn/ Semantic Sensor Network] ontology.
<nowiki>
@prefix : <http://example.com/energy-management/>.

<> a :MainsFrequencySensor;
rdfs:comment "Sense grid load based on mains frequency";
ssn:hasMeasurementCapability [
a :FrequencyMeasurementCapability;
ssn:hasMeasurementProperty <#property_1> .
] .
</nowiki>

The value of the sensor changes in real-time as measurements are taken. The LDP client can interrogate the resource below to determine if it has changed, ''without'' necessarily having to download the RDF representation. As different sensor properties are represented disjointly (separate RDF representations) they may change independently.

<nowiki>
@prefix : <http://example.com/energy-management/>.

<http://example.com/energy-management#property_1> :hasMeasurementPropertyValue <> .
<> a :FrequencyValue;
:hasQuantityValue "50"^^xsd:float.
</nowiki>

===UC6: Aggregate resources===
There is a requirement to be able to manage ''collections'' of resources. The concept of a collection overlaps with, but is distinct from that of a container. These collections are (weak) aggregations, unrelated to the lifecycle management of resources, and distinct from the ownership between a resource and its container. However, the composition of a container may be reflected as a collection to support navigation of the container and its contents. There is a need to be able to create collections by adding and deleting individual membership properties. Resources may belong to multiple collections, or to none.

* Resource descriptions are a "mix of simple data and collections" (from [[#Keeping Track of Personal and Business Relationships]]).
* Relative URIs: It should be possible to "ship payloads of RDF" for a collection as a whole without breaking internal links (from [[#Constrained Devices and Networks]]).

====Primary scenario: add a resource to a collection====
This example is from [[#Library Linked Data|Library Linked Data]] and [http://www.w3.org/2005/Incubator/lld/wiki/UseCaseReport LLD-UC], specifically [http://www.w3.org/2005/Incubator/lld/wiki/Use_Case_Subject_Search Subject Search].

There is an existing collection at <nowiki><http://example.com/concept-scheme/subject-heading></nowiki> that defines a collection of subject headings. This collection is defined as a skos:ConceptScheme and
the client wishes to insert a new concept into the scheme. which will be related to the collection via a <nowiki>skos:inScheme</nowiki> link. The new subject-heading, "outer space exploration", is not necessarily owned by a container. The following RDF would be added to the (item-level) description of the collection.

<nowiki>
@prefix scheme : <http://example.com/concept-scheme/>.
@prefix concept : <http://example.com/concept/>.

scheme:subject-heading a skos:ConceptScheme.

concept:Outer+space+Exploration skos:inScheme scheme:subject-heading.
</nowiki>

====Alternative scenario: add a resource to multiple collections====
Logically, a resource should not be owned by more than one container. however, it may be a member of multiple collections which define a weaker form of ''aggregation''. As this is simply a manipulation of the RDF description of a collection, it should be possible to add the same resource to multiple collections.

As a machine-readable collection of medical terms, the [http://www.ihtsdo.org| SNOMED] ontology is of key importance in [[#Healthcare | healthcare]]. SNOMED CT allows concepts with more than one parent that don't fall into a lattice.
In the example below, the same concept may fall under two different parent concepts.
The example uses skos:narrowerTransitive to elide intervening concepts.

<nowiki>
@prefix : <http://example.com/snomed/>.

:_119376003 a skos:Concept ;
skos:prefLabel "Tissue specimen"
skos:narrowerTransitive :TissueSpecimenFromHeart.

:_127462005 a skos:Concept ;
skos:prefLabel "Specimen from heart"
skos:narrowerTransitive :TissueSpecimenFromHeart.

:_128166000 a skos:Concept;
rdfs:label "Tissue specimen from heart".
</nowiki>

===UC7: Filter resource description===
This use-case extends the normal behaviour of retrieving an RDF description of a resource, by dynamically excluding specific (membership) properties.
For containers, it is often desirable to be able to read a collection, or item-level description that excludes the container membership.

====Primary scenario: retrieve collection-level description====
This scenario, based on [[#Library Linked Data| Library Linked Data]], uses the Dublin Core Metadata Initiative [http://dublincore.org/groups/collections/collection-application-profile/| Collection-Level] description.
A collection can refer to any aggregation of physical or digital items.
This scenario covers the case whereby a client can request a collection-level description as typified by the example below, without necessarily having to download a full listing of the items within the collection.

<nowiki>
@prefix rdf: <rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">.
@prefix dc: <http://purl.org/dc/elements/1.1/>.
@prefix : <http://example.org/bookshelf/>.
@prefix dcmitype: <http://purl.org/dc/dcmitype/>.
@prefix cld: <http://purl.org/cld/terms/>.
@prefix dcterms: <http://purl.org/dc/terms/>.

<> dc:type dcmitype:Collection ;
dc:title "Directory of organizations working with Linked Data" ;
dcterms:abstract "This is a directory of organisations specializing in Linked Data."
cld:isLocatedAt <http://dir.w3.org>
cld:isAccessedVia <http://dir.w3.org/rdf/2012/directory/directory-list.xhtml?construct>
</nowiki>

====Alternative scenario: retrieve item-level description of a collection====
This use-case scenario, also based on [[#Library Linked Data| Library Linked Data]], focuses on obtaining an item-level description of the resources aggregated by a collection.
The simplest scenario is where the members of a collection are returned within a single representation, so that a client can explore the data by following these links. Different applications may use different membership predicates to capture this aggregation. The example below uses <nowiki>rdfs:member</nowiki>, but many different membership predicates are in common use, including RDF Lists.
Item-level descriptions can be captured using the Functional Requirements for Bibliographic Records ([http://www.ifla.org/publications/functional-requirements-for-bibliographic-records FRBR]) [http://vocab.org/frbr/core.html ontology].

<nowiki>
@prefix frbr: <http://purl.org/vocab/frbr/core#>.

<> rdfs:member <#ebooks97>, <#ebooks21279>.

<#work97> a frbr:LiteraryWork;
dc:title "Flatland: a romance of many dimensions" ;
frbr:creator <#Abbott_Edwin>;
frbr:manifestation <ebook97>.

<#work21279> a frbr:LiteraryWork;
dc:title "2 B R 0 2 B" ;
frbr:creator <#Vonnegut_Kurt>;
frbr:manifestation <ebook21279>.
</nowiki>

Collections are potentially very large, so some means may be required to limit the size of RDF representation returned by the LDP (e.g. pagination).

===UC8: Manage media resources===
It should be possible to easily add non-RDF media resources to containers that accept them. Media resources may be updated and removed during the lifecycle of the container.

====Primary scenario: access media resources====
From the User Story [[#Sharing Binary Resources and Metadata| Sharing Binary Resources and Metadata]] it should be possible to easily add non RDF resources to a containers that accept them. Clients submit a non-RDF representation to a container in a media type accepted by that container. The container creates a URI to represent this media resource, and creates a link from the container to the new URI.The media resource may have an explicit representation of the media type. It should be possible to find the metadata about such a resource and to access and edit it in the usual ways.

This example uses the [http://www.w3.org/TR/mediaont-10/#ont-ttl Ontology for Media Resources] to describe a media resource added to a collection.
<nowiki>
@prefix ma: <http://www.w3.org/ns/ma-ont#> .

<dataset> a ma:Collection ;
:hasMember <dataset/image1.jpg>

<dataset/image1.jpg> a ma:MediaResource ;
ma:hasFormat "image/jpeg" .
</nowiki>

====Alternative scenario: media-resource attachments====
A resource may have multiple ''renditions''; the idea that you can have a PDF and a JPEG representing the same thing. A user is trying to create a work order along with an attached image showing a faulty machine part. To the user and to the work order system, these two artifacts are managed as a set. A single request may create the work order, the attachment, and the relationship between them, atomically.
When the user retrieves the work order later, they expect a single request by default to retrieve the work order plus all attachments.
When the user updates the work order, e.g. to mark it completed, they only want to update the work order proper, not its attachments.
Users may add/remove/replace attachments to the work order during its lifetime.

== Requirements ==

===Functional Requirements===
# Create Containers, from [[#UC1: Manage containers]]
# Creation of nested containers, from [[#UC1: Manage containers]]
# Creation of resources (within a container), from [[#UC2: Manage resources]]
# Deletion of resources, from [[#UC2: Manage resources]]
# Moving contained resources, from [[#UC2: Manage resources]]
# Retrieve resource description, from [[#UC3: Retrieve resource description]]
# Retrieve description of a non-document resource, from [[#UC3: Retrieve resource description]]
# Enrichment (substituting update of existing resource), from [[#UC4: Update existing resource]]
# Selective update of a resource, from [[#UC4: Update existing resource]]
# Determine if a resource has changed, from [[#UC5: Determine if a resource has changed]]
# Add a resource to a collection, from [[#UC6: Aggregate resources]]
# Add a resource to multiple collections, from [[#UC6: Aggregate resources]]
# Retrieve collection-level description, from [[#UC7: Filter resource description]]
# Retrieve item-level description of a collection, from [[#UC7: Filter resource description]]
# Access media resources, from [[#UC8: Manage media resources]]
# Media-resource attachments, from [[#UC8: Manage media resources]]

===Non-Functional Requirements===

# Provide access guidance to resources, from [[#UC1: Manage containers]]
# Non-duplication of resources, from [[#UC2: Manage resources]]
# Distribution of resources, from [[#UC2: Manage resources]]
# Consistent, global naming, from [[#UC2: Manage resources]]
# Use standard vocabularies as appropriate, from [[#UC3: Retrieve resource description]]
# Scalable linking model, from [[#UC3: Retrieve resource description]]
# Unrestricted vocabulary, from [[#UC4: Update existing resource]]
# Resource descriptions are a "mix of simple data and collections", from [[#UC6: Aggregate resources]]
# Relative URIs enabling sharing of collections, from [[#UC6: Aggregate resources]]

== Acknowledgements ==
We would like to acknowledge the contributions of user-story authors; Christophe Guéret, Roger Menday, Eric Prud'hommeaux.

== References ==

Use Cases And Requirements

Sbattle2 — Mon, 10 Dec 2012 11:21:24 GMT

Sbattle2: /* To Be Done */

= Linked Data Platform Use Cases And Requirements =

This is a working document used to collect use cases and requirements for consideration by the WG.
The starting point comes from [http://www.w3.org/Submission/2012/SUBM-ldbpucr-20120326/ Linked Data Basic Profile Use Cases and Requirements].

== Steps to Complete ==

* <strike>Nov 26? WG to confirm User Story content: add, remove, refine (see process below). Note: this is ONLY User Stories (not Use Cases, Use Case Scenarios or Requirements)</strike>
** Issues before Nov 26th? will be included into FPWD
* Editors to:
** <strike>Dec 3 refine User Stories based on feedback</strike>
** <strike>Dec 5 elaborate on Use Cases in support of User Stories</strike>
* Dec 10 - WG to review prior to FPWD
** Review period ends Dec 15th
** insert open issues into draft for FPWD
* Dec 17 - Publish FPWD
** convert wiki page to ReSpec for FPWD
* Dec ?? Deadline for publications by year end 2012

===To Be Done===
* <strike>Move [[#LDP_and_Authentication.2FAuthorization| LDP and Authentication]] to [http://www.w3.org/2012/ldp/wiki/AccessControl AccessControl]</strike>
* <strike>Complete [[#Alternative_scenario:_moving_contained_resources| moving contained resources]] scenario with content from ericP on issue-30.</strike>
* Augment [[#Cloud_Infrastructure_Management| Cloud Infrastructure Management]] scenario with content from Roger Menday.
* <strike>Ensure issue-40/41 are fully covered in [[#UC8:_Managing_non-RDF_Resources| UC8: Managing non-RDF Resources]]. 2 scenarios (single v multiple attachments) ?</strike>
* <strike>Contact owner of [[#Data_Sharing| Data Sharing]] user-story to determine if we keep or not.</strike>
* <strike>Review [[#Requirements| Requirements]] section for functional/non-functional requirements arising in UCs.</strike>
* <strike>Propose resolutions to open issues against UC&R where possible.</strike>
* <strike>Identify and acknowledge user-story contributors.</strike>
* <strike>Check hyperlinks</strike>
* Convert to ReSpec
* Annotate document with open issues against UC&R
** [http://www.w3.org/2012/ldp/track/issues/30 ISSUE-30] (OPEN)
** [http://www.w3.org/2012/ldp/track/issues/40 ISSUE-40] (RAISED)
** [http://www.w3.org/2012/ldp/track/issues/41 ISSUE-41] (RAISED)

=== Process to introduce new User Stories & Use Cases ===

Open an Issue in the tracker against the UC&R product. The WG will review these and decide whether they are valid.

== Scope and Motivation ==

Linked Data was defined by Tim Berners-Lee with the following guidelines [http://www.w3.org/DesignIssues/LinkedData.html]:

# Use URIs as names for things
# Use HTTP URIs so that people can look up those names
# When someone looks up a URI, provide useful information, using the standards (RDF*, SPARQL)
# Include links to other URIs. so that they can discover more things

These four rules have proven very effective in guiding and inspiring people to publish Linked Data on the web. The amount of data, especially public data, available on the web has grown rapidly, and an impressive number of extremely creative and useful “mashups” have been created using this data as result.

There has been much less focus on the potential of Linked Data as a model for managing data on the web - the majority of the Application Programming Interfaces (APIs) available on the Internet for creating and updating data follow a Remote Procedure Call (RPC) model rather than a Linked Data model.

If Linked Data were just another model for doing something that RPC models can already do, it would be of only marginal interest. Interest in Linked Data arises from the fact that applications with an interface defined using Linked Data can be much more easily and seamlessly integrated with each other than applications that offer an RPC interface. In many problem domains, the most important problems and the greatest value are found not in the implementation of new applications, but in the successful integration of multiple applications into larger systems.

Some of the features that make Linked Data exceptionally well suited for integration include:

* A single interface – defined by a common set of HTTP methods – that is universally understood and is constant across all applications. This is in contrast with the RPC architecture where each application has a unique interface that has to be learned and coded to.
* A universal addressing scheme – provided by HTTP URLs – for both identifying and accessing all “entities”. This is in contrast with the RPC architecture where there is no uniform way to either identify or access data.
* A simple yet extensible data model – provided by RDF – for describing data about a resource in a way which doesn’t require prior knowledge of vocabulary being used.

Experience implementing applications and integrating them using Linked Data has shown very promising results, but has also demonstrated that the original four rules defined by Tim Berners-Lee for Linked Data are not sufficient to guide and constrain a writable Linked Data API. As was the case with the original four rules, the need generally is not for the invention of fundamental new technologies, but rather for a series of additional rules and patterns that guide and constrain the use of existing technologies in the construction of a Basic Profile for Linked Data to achieve interoperability.

The following list illustrates a few of the issues that require additional rules and patterns:
* What URLs do I post to in order to create new resources?
* How do I get lists of existing resources, and how do I get basic information about them without having to access each one?
* How should I detect and deal with race conditions on write?
* What media-types/representations should I use?
* What standard vocabularies should I use?
* What primitive data types should I use?

A good goal for the Basic Profile for Linked Data would be to define a specification required to allow the definition of a writable Linked Data API equivalent to the simple application APIs that are often written on the web today using the Atom Publishing Protocol (APP). APP shares some characteristics with Linked Data, such as the use of HTTP and URLs. One difference is that Linked Data relies on a flexible data model with RDF, which allows for multiple representations.

== Organization of this Document ==

This document is organized as follows:

* '''[[#User Stories| User Stories]]''' capture statements about system requirements written from a user or application perspective. They are typically lightweight and informal and can run from one line to a paragraph or two (sometimes described as an 'epic') [http://www.agilemodeling.com/artifacts/userStory.htm]. Analysis of each user story will reveal a number of (functional) use-cases and other non-functional requirements. See [http://www.w3.org/TR/dap-policy-reqs/| Device API Access Control Use Cases and Requirements] for a good example of user stories and their analysis.

* '''[[#Use Cases| Use Cases]]''' are used to capture and model functional requirements. Use cases describe the system’s behavior under various conditions [http://alistair.cockburn.us/get/2465], cataloguing who does what with the system, for what purpose, but without concern for system design or implementation [http://www.bredemeyer.com/pdf_files/functreq.pdf]. Each use case is identified by a reference number to aid cross-reference from other documentation; use-case indexing in this document is based on [http://www.w3.org/TR/rdb2rdf-ucr/ rdb2rdf use-cases]. A variety of styles may be used to capture use-cases, from a simple narrative to a structured description with actors, pre/post conditions, and step-by-step behaviours as in [http://www.w3.org/TR/powder-use-cases/ POWDER: Use Cases and Requirements], and non-functional requirements raised by the use-case. Use cases act like the hub of a wheel, with spokes supporting requirements analysis, scenario-based evaluation, testing, and integration with non-functional, or quality requirements.

* '''Scenarios''' are more focused still, representing a single instance of a use case in action. Scenarios may range from lightweight narratives as seen in [http://www.w3.org/TR/media-frags-reqs/ Use cases and requirements for Media Fragments], to being formally modeled as interaction diagrams. Each use-case should include at least a primary scenario, and possibly other alternative scenarios.

* '''[[#Requirements| Requirements]]''' list non-functional or quality requirements, and the use cases they may be derived from. This approach is exemplified in the [http://dvcs.w3.org/hg/gld/raw-file/default/dcat-ucr/index.html Use Cases and Requirements for the Data Catalog Vocabulary].

== User Stories ==

=== Maintaining Social Contact Information ===

Many of us have multiple email accounts that include information about the people and organizations we interact with – names, email addresses, telephone numbers, instant messenger identities and so on. When someone’s email address or telephone number changes (or they acquire a new one), our lives would be much simpler if we could update that information in one spot and all copies of it would automatically be updated. In other words, those copies would all be linked to some definition of “the contact.” There might also be good reasons (like off-line email addressing) to maintain a local copy of the contact, but ideally any copies would still be linked to some central “master.”

Agreeing on a format for “the contact” is not enough, however. Even if all our email providers agreed on the format of a contact, we would still need to use each provider’s custom interface to update or replace the provider’s copy, or we would have to agree on a way for each email provider to link to the “master”. If we look outside our own personal interests, it would be even more useful if the person or organization exposed their own contact information so we could link to it.

What would work in either case is a common understanding of the resource, a few formats needed, and access guidance for these resources. This would support how to acquire a link to a contact, and how to use those links to interact with a contact (including [[#UC3: Retrieve resource description|reading]], [[#UC4: Update existing resource|updating]], and [[#Alternative scenario: delete resource|deleting]] it), as well as how to easily [[#Primary scenario: create resource|create a new contact]] and add it to my contacts and when deleting a contact, how it would be removed from my list of contacts. It would also be good to be able to add some application-specific data about my contacts that the original design didn’t consider. Ideally we’d like to eliminate multiple copies of contacts, there would be additional valuable information about my contacts that may be stored on separate servers and need a simple way to link this information back to the contacts. Regardless of whether a contact collection is my own, shared by an organization, or all contacts known to an email provider (or to a single email account at an email provider), it would be nice if they all worked pretty much the same way.

=== Keeping Track of Personal and Business Relationships ===

In our daily lives, we deal with many different organizations in many different relationships, and they each have data about us. However, it is unlikely that any one organization has all the information about us. Each of them typically gives us access to the information (at least some of it), many through websites where we are uniquely identified by some string – an account number, user ID, and so on. We have to use their applications to interact with the data about us, however, and we have to use their identifier(s) for us. If we want to build any semblance of a holistic picture of ourselves (more accurately, collect all the data about us that they externalize), we as humans must use their custom applications to find the data, copy it, and organize it to suit our needs.

Would it not be simpler if at least the Web-addressable portion of that data could be linked to consistently, so that instead of maintaining various identifiers in different formats and instead of having to manually supply those identifiers to each one’s corresponding custom application, we could essentially build a set of bookmarks to it all? When we want to [[#UC3: Retrieve resource description|examine]] or [[#UC4: Update existing resource|change]] their contents, would it not be simpler if there were a single consistent application interface that they all supported? Of course it would.

Our set of links would probably be a [[#UC6: Aggregate resources|simple collection]]. The information held by any single organization might be a mix of simple data and [[#UC6: Aggregate resources|collections of other data]], for example, a bank account balance and a collection of historical transactions. Our bank might easily have [[#Alternative scenario: create a nested container|a collection of accounts for each of its collection of customers]].

=== System and Software Development Tool Integration ===

System and software development tools typically come from a diverse set of vendors and are built on various architectures and technologies. These tools are purpose built to meet the needs for a specific domain scenario (modeling, design, requirements and so on.) Often tool vendors view integrations with other tools as a necessary evil rather than providing additional value to their end-users. Even more of an afterthought is how these tools’ data -- such as people, projects, customer-reported problems and needs -- integrate and relate to corporate and external applications that manage data such as customers, business priorities and market trends. The problem can be isolated by standardizing on a small set of tools or a set of tools from a single vendor, but this rarely occurs and if does it usually does so only within small organizations. As these organizations grow both in size and complexity, they have needs to work with outsourced development and diverse internal other organizations with their own set of tools and processes. There is a need for better support of more complete business processes (system and software development processes) that span the roles, tasks, and data addressed by multiple tools. This demand has existed for many years, and the tools vendor industry has tried several different architectural approaches to address the problem. Here are a few:

* Implement an API for each application, and then, in each application, implement “glue code” that exploits the APIs of other applications to link them together.
* Design a single database to store the data of multiple applications, and implement each of the applications against this database. In the software development tools business, these databases are often called “repositories.”
* Implement a central “hub” or “bus” that orchestrates the broader business process by exploiting the APIs described previously.

It is fair to say that although each of those approaches has its adherents and can point to some successes, none of them is wholly satisfactory. The use of Linked Data as an application integration technology has a strong appeal. [http://open-services.net/ OSLC]

=== Library Linked Data ===

The W3C Library Linked Data working group has a number of use cases cited in their Use Case Report. [http://www.w3.org/2005/Incubator/lld/wiki/UseCaseReport LLD-UC] These referenced use cases focus on the need to extract and correlate library data from disparate sources. Variants of these use cases that can provide consistent formats, as well as ways to improve or update the data, would enable simplified methods for both efficiently sharing this data as well as producing incremental updates without the need for repeated full extractions and import of data.

The 'Digital Objects Cluster' contains a number of relevant use-cases:

* Grouping: This should "Allow the end-users to define [[#UC6: Aggregate resources|groups of resources]] on the web that for some reason belong together. The relationship that exists between the resources is often left unspecified. Some of the resources in a group may not be under control of the institution that defines the groups."

* Enrichment: "Enable end-users to [[#UC4: Update existing resource|link resources together]]."

* Browsing: "[[#UC7: Filter resource description|Support end-user browsing through groups]] and resources that belong to the groups."

* Re-use: "Users should have the capability to re-use all or parts of a collection, with all or part of its metadata, elsewhere on the linked Web."

The 'Collections' cluster also contains a number of relevant use-cases:

* Collection-level description: "Provide [[#UC7: Filter resource description|metadata pertaining to a collection as a whole]], in contrast to item-level description."

* Collections discovery: "Enable innovative collection discovery such as identification of nearest location of a physical collection where a specific information resource is found or mobile device applications ... based on collection-level descriptions."

* Community information services: Identify and classify collections of special interest to the community.

=== Municipality Operational Monitoring ===

Across various cities, towns, counties, and various municipalities there is a growing number of services managed and run by municipalities that produce and consume a vast amount of information. This information is used to help monitor services, predict problems, and handle logistics. In order to effectively and efficiently collect, produce, and analyze all this data, a fundamental set of loosely coupled standard data sources are needed. A simple, low-cost way to [[#UC3: Retrieve resource description|expose data]] from the diverse set of monitored services is needed, one that can easily integrate into the municipalities of other systems that inspect and analyze the data. All these services have links and dependencies on other data and services, so having a simple and scalable linking model is key.

=== Healthcare ===

For physicians to analyze, diagnose, and propose treatment for patients requires a vast amount of complex, changing and growing knowledge. This knowledge needs to come from a number of sources, including physicians’ own subject knowledge, consultation with their network of other healthcare professionals, public health sources, food and drug regulators, and other repositories of medical research and recommendations.

To diagnose a patient’s condition requires current data on the patient’s medications and medical history. In addition, recent pharmaceutical advisories about these medications are linked into the patient’s data. If the patient experiences adverse affects from medications, these physicians need to publish information about this to an appropriate regulatory source. Other medical professionals require access to both validated and emerging effects of the medication. Similarly, if there are geographical patterns around outbreaks that allow both the awareness of new symptoms and treatments, this information needs to quickly reach a very distributed and diverse set of medical information systems. Also, reporting back to these regulatory agencies regarding new occurrences of an outbreak, including additional details of symptoms and causes, is critical in producing the most effective treatment for future incidents.

=== Metadata Enrichment in Broadcasting ===

There are many different use cases when broadcasters show interest in metadata [[#UC4: Update existing resource| enrichment]]:

* enrich archive or news metadata by linking facts, events, locations and personalities
* enrich metadata generated by automatic extraction tools such as person identification, etc.
* enrich definitions of terms in classification schemes or enumeration lists

This comes in support of more effective information management and data/content mining (if you can't find your content, it' like if you don't have and must either recreate or acquire it again, which is not financially effective).

However, there is a need for solutions facilitating linkage to other data sources and taking care of the issues such as discovery, automation, disambiguation. Etc. Other important issues that broadcasters would face are the editorial quality of the linked data, its persistence, and usage rights.

=== Aggregation and Mashups of Infrastructure Data ===

For infrastructure management (such as storage systems, virtual machine environments, and similar IaaS and PaaS concepts), it is important to provide an environment in which information from different sources can be [[#UC6: Aggregate resources|aggregated]], [[#UC7: Filter resource description|filtered]], and visualized effectively. Specifically, the following use cases need to be taken into account:

* While some data sources are based on Linked Data, others are not, and aggregation and mashups must work across these different sources.
* Consumers of the data sources and aggregated/filtered data streams are not necessarily implementing Linked Data themselves, they may be off-the-shelf components such as dashboard frameworks for composing visualizations.
* Simple versions of this scenario are pull-based, where the data is requested from data sources. In more advanced settings, without a major change in architecture it should be possible to move to a push-based interaction model, where data sources push notifications to subscribers, and data sources provide different services that consumers can subscribe to (such as "informational messages" or "critical alerts only").

In this scenario, the important factors are to have abstractions that allow easy aggregation and filtering, are independent from the internal data model of the sources that are being combined, and can be used for pull-based interactions as well as for push-based interactions.

=== Sharing payload of RDF data among low-end devices ===

Several projects around the idea of [http://worldwidesemanticweb.wordpress.com/ downscaling the Semantic Web] need to be able to ship payloads of RDF across the nodes member of a given network. The transfers are done in a constrained context in terms of bandwidth, scope of the local semantics employed by the nodes and computing capabilities of the nodes. In a P2P style, every node has the capability to act either as a data consumer or a data provider, serving its own data or acting as a relay to pass other's data along (typically in mesh networks).

The transfer of an arbitrary payload of RDF data could be implemented through the container mechanism, adding and removing sets of RDF triples to it. Currently, one of the project "SemanticXO" uses named graphs and the graph protocol to create/delete/copy graphs across the nodes but this (almost) imposes the usage of a triple store. Unfortunately, triple store are rather demanding piece of software that are not always usable on limited hardware. Some generic ReST like interaction backed up with a lightweight column store would be better approach.

=== Sharing Binary Resources and Metadata ===

When publishing datasets about stars one may want to publish links to the pictures in which those stars appear, and this may well require publishing the pictures themselves. Vice versa: when publishing a picture of space we need to know which telescope took the picture, which part of the sky it was pointing at, what filters were used, which identified stars are visible, who can read it, who can write to it, ...

If LinkedData contains information about resources that are most naturally expressed in non-rdf formats (be they binary such as pictures or videos, or human readable documents in XML formats), those non RDF formats should be just as easy to publish to the LinkedData server as the RDF relations that link those resources up. A LinkedData server should therefore allow publishing of non linked data resources too, and make it easy to publish and edit metadata about those resources.

The resource comes in two parts - the image and information about the image (which may in the image file but better external to it as it's more general). The information about the image is vital. It's a compound item of image data and other data (being application metadata about the image does not distinguish from the platform's point-of-view.

=== Data Catalogs ===

The Asset Description Metadata Schema ([http://joinup.ec.europa.eu/asset/adms/home ADMS]) provides the data model to describe semantic assets repositories contents, but this leaves many open challenges when building a federation of these repositories to serve the need of assets reuse. These include accessing and querying individual repositories and efficiently retrieving [[#UC5: Determine if a resource has changed| updated content]] without having to retrieve the whole content. Hence, we chose to build the integration solution capitalizing on the Data Warehousing integration approach. This allows us to cope with heterogeneity of sources technologies and to benefit from the optimized performance it offers, given that individual repositories do not usually change frequently. With Data Warehousing, the federation requires to:

* understand the data, i.e. understand their semantic descriptions, and other systems.
* seamlessly exchange the semantic assets metadata from different repositories
* keep itself up-to-date.

Repositories owners can maintain de-referenceable URIs for their repository description and contained assets in a Linked Data compatible manner. ADMS provides the necessary data model to enable meaningful exchange of data. However, This leaves the challenge of efficient access to the data not fully addressed.

Related: [http://spec.datacatalogs.org/ Data Catalog Schema and Protocol]

=== Constrained Devices and Networks ===

Information coming from resource constrained devices in the Web of Things ([http://en.wikipedia.org/wiki/Web_of_Things WoT]) has been identified as a major driver in many domains, from smart cities to environmental monitoring to real-time tracking. The amount of information produced by these devices is growing exponentially and needs to be accessed and integrated in a systematic, standardized and cost efficient way. By using the same standards as on the Web, integration with applications will be simplified and higher-level interactions among resource constrained devices, abstracting away heterogeneities, will become possible. Up-coming IoT/WoT standards such as [http://datatracker.ietf.org/wg/6lowpan/ 6LowPAN] - IPv6 for resource constrained devices - and the Constrained Application Protocol ([http://tools.ietf.org/html/draft-ietf-core-coap CoAP]), which provides a downscaled version of HTTP on top of UDP for the use on constrained devices, are already at a mature stage. The next step now is to support RESTful interfaces also on resource constrained devices, adhering to the Linked Data principles. Due to the limited resources available, both on the device and in the network (such as bandwidth, energy, memory) a solution based on SPARQL Update is at the current point in time considered not to be useful and/or feasible. An approach based on the [http://tools.ietf.org/html/draft-castellani-core-http-mapping HTTP-CoAP Mapping] would enable constrained devices to directly participate in a Linked Data-based environment.

=== Services Supporting the Process of Science ===
Many fields of science now include branches with in silico data-intensive methods, e.g. bioinformatics, astronomy. To support these new methods we look to move beyond the established platforms provided by scientific workflow systems to capture, assist, and preserve the complete lifecycle from record of the experiment, through local trusted sharing, analysis, dissemination (including publishing of experimental data "beyond the PDF"), and re-use.

* [[#UC6: Aggregate resources|Aggregations]], specifically ''Research Objects (ROs)'' that are exchanged between services and clients bringing together workflows, data sets, annotations, and provenance. We use an RDF model for this. While some aggregated contents are encoded using RDF and in increasing number are linked data sources, others are not; while some are stored locally "within" the RO, others are remote (in both cases this is often due to size of the resources or access policies).
* Services that are distributed and linked. Some may be centralising for e.g. publication, others may be local, e.g. per lab. We need lightweight services that can be simply and easily integrated into and scale across the wide variety of softwares and data used in science: we have adopted a RESTful approach where possible.
** Foundation services that collect and expose ROs for storage, modification, exploration, and reuse.
** Services that provide added-value to ROs such as seamless import/export from scientific workflow systems, automated stability evaluation, or recommendation (and therefore interact with the foundation services to retrieve/store/modify/ROs).

seeAlso: [http://www.wf4ever-project.org/ Wf4Ever]

=== Project Membership Information : Information Evolution ===

Information about people and projects changes as roles change, as organisations change
and as contact details change. Finding the current state of a project is important
in enabling people to contact the right person in the right role. It can also be
useful to look back and see who was performing what role in the past.

A use of a Linked Data Platform could be to give responsibility for managing
such information with the project team itself, not requiring updates to be
requested of a centralised website administrator.

This could be achieved with:

* Resource descriptions for each person and project
* A container resource to describe roles/membership in the project.

To retain the history of the project, the old version of a resources,
including container resources, should be retained so there is a need to address both specific items
and also have a notion of "current".

Access to information has two aspects:
* Access to the "current" state, regardless of the version of the resource description
* Access to historical state, via access to a specific version of the resource description

=== Cloud Infrastructure Management===

Cloud operators offer API support to provide customers with remote access for infrastructure management. Infrastructure consists of Systems, Computers, Networks, Discs, etc, and the overall structure can be seen as mostly hierarchical, (Cloud contains Systems, Systems contain Machines, etc). This is complemented with crossing links (e.g. Machines connected to a Network). The IaaS scenario also makes requirements for lifecycle management, non-instant changes and history capture. Infrastructure management can be seen as the manipulation of the underlying graph.

== Use Cases ==
The following use-cases are each derived from one or more of the user-stories above. These use-cases are explored in detail through the development of scenarios, each motivated by some key aspect exemplified by a single user-story. The examples they contain are included purely for illustrative purposes, and should not be interpreted normatively.

===UC1: Manage containers===
A number of user-stories introduce the idea of a ''container'' as a mechanism for creating and managing resources within the context of an application. Resources grouped together within the same container would typically belong to the same application. A container is identified by a URI so is a resource in its own right.
The properties of a container may also represent the ''affordances'' of that container, enabling clients to determine what other operations they can do on that container. These operations may include descriptions of application specific services that can be invoked by exchanging RDF documents.

* Provide "access guidance for ... resources" (affordances) (from user-story, [[#Maintaining Social Contact Information|Maintaining Social Contact Information]]).

====Primary scenario: create container====
Create a new container resource within the LDP server.
In [[#Services Supporting the Process of Science|Services supporting the process of science]], [http://wf4ever.github.com/ro-primer/ Research Objects] are semantically rich aggregations of resources that bring together data, methods and people in scientific investigations. A basic workflow research object will be created to aggegate [http://ceur-ws.org/Vol-903/paper-01.pdf scientific workflows] and the artefacts that result from this workflow. The research object begins life as an empty container into which workflows, datasets, results and other data will be added throughout the lifecycle of the project.

<nowiki>
@prefix ro: http://purl.org/wf4ever/ro#
@prefix dct: http://purl.org/dc/terms/
@prefix ore: http://www.openarchives.org/ore/

<> a ro:ResearchObject, ore:Aggregation ;
dct:created "2012-12-01"^^xsd:dateTime .
</nowiki>

====Alternative scenario: create a nested container====
The motivation for nested containers comes from the [[#System and Software Development Tool Integration| System and Software Development Tool Integration]] user-story. The OSLC Change Management vocabulary allows bug reports to have attachments referenced by the membership predicate <nowiki>oslc_cm:attachment</nowiki>. The 'top-level-container' contains issues, and each issue resource has its own container of attachment resources.

<nowiki>
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix oslc_cm: <http://open-services.net/ns/cm#>.
@prefix : <http://example.org/>.

:top-level-container rdfs:member :issue1234 .

:issue1234 a oslc_cm:ChangeRequest;
dcterms:identifier "1234";
dcterms:type "a bug";
dcterms:related :issue1235 ;
oslc_cm:attachments :attachments123.

:issue1235 a oslc_cm:ChangeRequest;
dcterms:title "a related bug".

:attachments a oslc_cm:AttachmentList;
oslc_cm:attachment :attachment324, :attachment251.
</nowiki>

===UC2: Manage resources===
This use-case addresses the managed lifecycle of a resource and is concerned with resource ''ownership''. The responsibility for managing resources belongs with their container.
For example, a container may accept a request from a client to make a new resource.
This use-case focuses on creation and deletion of resources in the context of a container, and the potential for transfer of ownership by moving resources between containers.
The ownership of a resource should always be clear; no resource managed in this way should ever be owned by more than one container.

Once a new resource has been created it should be identified by a URI. Clients may defer responsibility for establishing dereferenceable URIs to the container of their data.
The container is a natural choice for the endpoint for this interface as it will already have some application-specific knowledge about the contained resources.
While the LDP has ultimate control over resource naming, some applications may require more control over naming, perhaps to provide a more human-readable URI. An LDP server could support something like the [http://tools.ietf.org/html/rfc5023 Atom Publishing Protocol] slug header to convey a user defined naming 'hint'.

* Non-duplication of resources: "Eliminate multiple copies", representing resources in a single place (from [[#Maintaining Social Contact Information]]).
* Distribution of resources: Linked aata "may be stored on separate servers" (from [[#Maintaining Social Contact Information]]).
* Consistent, global naming: Resources should be "linked to consistently, ... instead of maintaining various identifiers in different formats" (from [[#Keeping Track of Personal and Business Relationships]]).

====Primary scenario: create resource====
Resources begin life by being created within a container. From user-story, [[#Maintaining Social Contact Information|Maintaining Social Contact Information]], It should be possible to "easily create a new contact and add it to my contacts." This suggests that resource creation is closely linked to the application context. The new resource is created in a container representing "my contacts." The lifecycle of the resource is linked to the lifecycle of it's container. So, for example, if "my contacts" is deleted then a user would also reasonably expect that all contacts within it would also be deleted.

Contact details are captured as an RDF description and it's properties, including "names, email addresses, telephone numbers, instant messenger identities and so on." The description may include non-standard RDF; "data about my contacts that the original design didn’t consider."
The following RDF could be used to describe contact information using the [http://www.foaf-project.org FOAF] vocabulary. A contact is represented here by a <nowiki>foaf:PersonalProfileDocument</nowiki> defining a resource that can be created and updated as a single-unit, even though it may describe ancillary resources, such as a <nowiki>foaf:Person</nowiki>, below.

<nowiki>
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

<> a foaf:PersonalProfileDocument;
foaf:PrimaryTopic [
a foaf:Person;
foaf:name "Timothy Berners-Lee";
foaf:title "Sir";
foaf:firstName "Timothy";
foaf:surname "Berners-Lee";
foaf:nick "TimBL", "timbl";
foaf:homepage <http://www.w3.org/People/Berners-Lee/>;
foaf:weblog <http://dig.csail.mit.edu/breadcrumbs/blog/4>;
foaf:mbox <mailto:timbl@w3.org>;
foaf:workplaceHomepage <http://www.w3.org/>.
]
</nowiki>

====Alternative scenario: delete resource====
Delete a resource and all it's properties. If the resource resides within a container it will be removed from that container, however other links to the deleted resource may be left as dangling references.
In the case where the resource is a container, the server may also delete any or all contained resources.
In normal practice, a deleted resource cannot be reinstated. There are however, edge-cases where limited undelete may be desirable.
Best practice states that "[http://www.w3.org/TR/cooluris/| Cool URIs don't change]", which implies that deleted URIs shouldn't be recycled.

====Alternative scenario: moving contained resources====
Many resources may have value beyond the life of their membership in a container. This implies methods to add references to revise container membership.
Cloning container members for use in other containers results in duplication of information and maintenance problems; web practice is to encourage the creation of one resource, which may be referenced as many places as necessary. A change of ownership may - or may not - imply a change of URI, depending upon the specific LDP naming policy. While assigning a new URI to a resource is discouraged [http://www.w3.org/DesignIssues/Architecture.html#HTTP], it is possible to indicate that a resource has moved with an appropriate HTTP response.

===UC3: Retrieve resource description===
Access the current description of a resource, containing properties of that resource and links to related resources. The representation may include descriptions of related resources that cannot be accessed directly.
Depending upon the application, an LDP may enrich the retrieved RDF with additional triples. Examples include adding incoming links, sameAs closure and type closure.
The HTTP response should also include versioning information (i.e. last update or entity tag) so that subsequent updates can ensure they are being applied to the correct version.

* Use standard vocabularies as appropriate to enable a "common understanding of the resource" (from [[#Maintaining Social Contact Information|Maintaining Social Contact Information]]).
* A "scalable linking model is key" (from [[#Municipality Operational Monitoring]]).

====Primary scenario====
The user-story [[#Project Membership Information : Information Evolution| Project Membership Information]] discusses the representation of information about people and projects. It calls for "Resource descriptions for each person and project" allowing project teams to review information held about these resources. The example below illustrates the kinds of information that might be held about organizational structures based on the [http://www.epimorphics.com Epimorphics] [http://www.epimorphics.com/public/vocabulary/org.html organizational ontology].

Note that the example below defines two resources (shown as separate sections below) that will be hosted on an LDP based at <nowiki>http://example.com/</nowiki>. The representations of these resources may include descriptions of related resources, such as <nowiki>http://www.w3.org/</nowiki>, that that fall under a different authority and therefore can't be served from the LDP at this location.

<nowiki>
@prefix org: <http://www.w3.org/ns/org#> .
@prefix owltime: <http://www.w3.org/2006/time> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@base <http://example.com/> .

<member1> a org:Membership ;
org:member <http://www.w3.org/People/Berners-Lee/card#i> ;
org:organization http://www.w3.org/> ;
org:role <director> ;
org:memberDuring [a owltime:Interval; owltime:hasBeginning [
owltime:inXSDDateTime "1994-10-01T00:00:00Z"^^xsd:dateTime]] .

<http://www.w3.org/> a org:FormalOrganization ;
skos:prefLabel "The World Wide Web Consortium"@en ;
skos:altLabel "W3C" .
</nowiki>

<nowiki>
@prefix org: <http://www.w3.org/ns/org#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@base <http://example.com/> .

<director> a org:Role ;
rdfs:label "Director" .
</nowiki>

====Alternative scenario: retrieve description of a non-document resource====
In many cases, the things that are of interest are not always the things that are resolvable. The example below demonstrates how a foaf profile may be used to distinguish between the person and the profile; the former being the topic of the latter. This begs the question as to what a client should do with such non-document resources. In this case the HTTP protocol requires that the fragment part be stripped off before requesting the URI from the server. The result is a resolvable URI for the profile.

<nowiki>
@base <http://www.w3.org/People/Berners-Lee/card>
@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@prefix dc: <http://purl.org/dc/elements/1.1/>.

<> a foaf:PersonalProfileDocument ;
dc:title "Tim Berners-Lee's FOAF file" ;
foaf:homepage <http://www.w3.org/People/Berners-Lee/> ;
foaf:primaryTopic <#i> .
</nowiki>

===UC4: Update existing resource===
Change the RDF description of a LDP resource, potentially removing or overwriting existing data. This allows applications to ''enrich'' the representation of a resource by addling additional links to other resources.

* Unrestricted vocabulary: It should be possible be "able to add ... application-specific data" to resources (from [[#Maintaining Social Contact Information]]).

====Primary scenario: enrichment====
This relates to user-story [[#Metadata Enrichment in Broadcasting| Metadata Enrichment in Broadcasting]] and is based on the [http://www.bbc.co.uk/ontologies/sport/ BBC Sports Ontology]. The ''resource-centric'' view of linked-data provides a natural granularity for substituting, or overwriting a resource and its data. The simplest kind of update would simply replace what is currently known about a resource with a new representation. There are two distinct resources in the example below; a sporting event and an associated award. The granularity of the LDP would allow a user to replace the information about the award without disturbing the information about the event.

<nowiki>
@prefix sport: <http://www.bbc.co.uk/ontologies/sport/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

:mens_sprint a sport:MultiStageCompetition;
rdfs:label "Men's Sprint";
sport:award <#gold_medal> .

<#gold_medal> a sport:Award .
</nowiki>

We can enrich the description as events unfold, linking to the winner of the gold medal by substituting the above description with the following.

<nowiki>
@prefix sport: <http://www.bbc.co.uk/ontologies/sport/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

:mens_sprint a sport:MultiStageCompetition;
rdfs:label "Men's Sprint";
sport:award <#gold_medal> .
<#gold_medal> a sport:Award;
sport:awarded_to [
a foaf:Agent ;
foaf:name "Chris Hoy" .
] .
</nowiki>

====Alternative scenario: selective update of a resource====
This relates to user-story [[#Data Catalogs|Data Catalogs]], based on the [http://vocab.deri.ie/dcat Data Catalog Vocabulary].
A catalogue is described by the following RDF model.

<nowiki>
@prefix dcat: <http://www.w3.org/ns/dcat#> .
@prefix dcterms: <http://purl.org/dc/terms/> .

:catalog a dcat:Catalog ;
dcat:dataset :dataset/001;
dcterms:issued "2012-12-11"^^xsd:date.
</nowiki>

A catalog may contain multiple datasets, so when linking to new datasets it would be simpler and preferable to selectively add just the new dataset links.
A Talis ''changeset'' [http://docs.api.talis.com/getting-started/changesets][http://www.w3.org/2009/12/rdf-ws/papers/ws07] could be used to add a new <nowiki>dc:title</nowiki> to the dataset. The following update would be directed to the catalogue to add an additional dataset.

<nowiki>
@prefix : <http://example.com/>.
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix cs: <http://purl.org/vocab/changeset/schema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.

<change1>
a cs:ChangeSet ;
cs:subjectOfChange :catalog ;
cs:createdDate "2012-01-01T00:00:00Z" ;
cs:changeReason "Update catalog datasets" ;
cs:addition [
a rdf:Statement ;
rdf:subject :catalog ;
rdf:predicate dcat:dataset ;
rdf:object :dataset/002 .
] .
</nowiki>

===UC5: Determine if a resource has changed===
It should be possible to retrieve versioning information about a resource (e.g. last modified or entity tag) without having to download a representation of the resource.
This information can then be compared with previous information held about that resource to determine if it has changed.
This versioning information can also be used in subsequent ''conditional'' requests to ensure they are only applied if the version is unchanged.

====Primary scenario====
Based on the user-story, [[#Constrained Devices and Networks| Constrained Devices and Networks]], an LDP could be configured to act as a proxy for a [http://tools.ietf.org/html/draft-ietf-core-coap CoAP] based [http://en.wikipedia.org/wiki/Web_of_Things Web of Things]. As an observer of CoAP resources, the LDP registers its interest so that it will be notified whenever the sensor reading changes. Clients of the LDP can interrogate the LDP to determine if the state has changed.

In this example, the information about a sensor and corresponding sensor readings can be represented as RDF resources. The first resource below, represents a sensor described using the [http://www.w3.org/2005/Incubator/ssn/ Semantic Sensor Network] ontology.
<nowiki>
@prefix : <http://example.com/energy-management/>.

<> a :MainsFrequencySensor;
rdfs:comment "Sense grid load based on mains frequency";
ssn:hasMeasurementCapability [
a :FrequencyMeasurementCapability;
ssn:hasMeasurementProperty <#property_1> .
] .
</nowiki>

The value of the sensor changes in real-time as measurements are taken. The LDP client can interrogate the resource below to determine if it has changed, ''without'' necessarily having to download the RDF representation. As different sensor properties are represented disjointly (separate RDF representations) they may change independently.

<nowiki>
@prefix : <http://example.com/energy-management/>.

<http://example.com/energy-management#property_1> :hasMeasurementPropertyValue <> .
<> a :FrequencyValue;
:hasQuantityValue "50"^^xsd:float.
</nowiki>

===UC6: Aggregate resources===
There is a requirement to be able to manage ''collections'' of resources. The concept of a collection overlaps with, but is distinct from that of a container. These collections are (weak) aggregations, unrelated to the lifecycle management of resources, and distinct from the ownership between a resource and its container. However, the composition of a container may be reflected as a collection to support navigation of the container and its contents. There is a need to be able to create collections by adding and deleting individual membership properties. Resources may belong to multiple collections, or to none.

* Resource descriptions are a "mix of simple data and collections" (from [[#Keeping Track of Personal and Business Relationships]]).
* Relative URIs: It should be possible to "ship payloads of RDF" for a collection as a whole without breaking internal links (from [[#Constrained Devices and Networks]]).

====Primary scenario: add a resource to a collection====
This example is from [[#Library Linked Data|Library Linked Data]] and [http://www.w3.org/2005/Incubator/lld/wiki/UseCaseReport LLD-UC], specifically [http://www.w3.org/2005/Incubator/lld/wiki/Use_Case_Subject_Search Subject Search].

There is an existing collection at <nowiki><http://example.com/concept-scheme/subject-heading></nowiki> that defines a collection of subject headings. This collection is defined as a skos:ConceptScheme and
the client wishes to insert a new concept into the scheme. which will be related to the collection via a <nowiki>skos:inScheme</nowiki> link. The new subject-heading, "outer space exploration", is not necessarily owned by a container. The following RDF would be added to the (item-level) description of the collection.

<nowiki>
@prefix scheme : <http://example.com/concept-scheme/>.
@prefix concept : <http://example.com/concept/>.

scheme:subject-heading a skos:ConceptScheme.

concept:Outer+space+Exploration skos:inScheme scheme:subject-heading.
</nowiki>

====Alternative scenario: add a resource to multiple collections====
Logically, a resource should not be owned by more than one container. however, it may be a member of multiple collections which define a weaker form of ''aggregation''. As this is simply a manipulation of the RDF description of a collection, it should be possible to add the same resource to multiple collections.

As a machine-readable collection of medical terms, the [http://www.ihtsdo.org| SNOMED] ontology is of key importance in [[#Healthcare | healthcare]]. SNOMED CT allows concepts with more than one parent that don't fall into a lattice.
In the example below, the same concept may fall under two different parent concepts.
The example uses skos:narrowerTransitive to elide intervening concepts.

<nowiki>
@prefix : <http://example.com/snomed/>.

:_119376003 a skos:Concept ;
skos:prefLabel "Tissue specimen"
skos:narrowerTransitive :TissueSpecimenFromHeart.

:_127462005 a skos:Concept ;
skos:prefLabel "Specimen from heart"
skos:narrowerTransitive :TissueSpecimenFromHeart.

:_128166000 a skos:Concept;
rdfs:label "Tissue specimen from heart".
</nowiki>

===UC7: Filter resource description===
This use-case extends the normal behaviour of retrieving an RDF description of a resource, by dynamically excluding specific (membership) properties.
For containers, it is often desirable to be able to read a collection, or item-level description that excludes the container membership.

====Primary scenario: retrieve collection-level description====
This scenario, based on [[#Library Linked Data| Library Linked Data]], uses the Dublin Core Metadata Initiative [http://dublincore.org/groups/collections/collection-application-profile/| Collection-Level] description.
A collection can refer to any aggregation of physical or digital items.
This scenario covers the case whereby a client can request a collection-level description as typified by the example below, without necessarily having to download a full listing of the items within the collection.

<nowiki>
@prefix rdf: <rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">.
@prefix dc: <http://purl.org/dc/elements/1.1/>.
@prefix : <http://example.org/bookshelf/>.
@prefix dcmitype: <http://purl.org/dc/dcmitype/>.
@prefix cld: <http://purl.org/cld/terms/>.
@prefix dcterms: <http://purl.org/dc/terms/>.

<> dc:type dcmitype:Collection ;
dc:title "Directory of organizations working with Linked Data" ;
dcterms:abstract "This is a directory of organisations specializing in Linked Data."
cld:isLocatedAt <http://dir.w3.org>
cld:isAccessedVia <http://dir.w3.org/rdf/2012/directory/directory-list.xhtml?construct>
</nowiki>

====Alternative scenario: retrieve item-level description of a collection====
This use-case scenario, also based on [[#Library Linked Data| Library Linked Data]], focuses on obtaining an item-level description of the resources aggregated by a collection.
The simplest scenario is where the members of a collection are returned within a single representation, so that a client can explore the data by following these links. Different applications may use different membership predicates to capture this aggregation. The example below uses <nowiki>rdfs:member</nowiki>, but many different membership predicates are in common use, including RDF Lists.
Item-level descriptions can be captured using the Functional Requirements for Bibliographic Records ([http://www.ifla.org/publications/functional-requirements-for-bibliographic-records FRBR]) [http://vocab.org/frbr/core.html ontology].

<nowiki>
@prefix frbr: <http://purl.org/vocab/frbr/core#>.

<> rdfs:member <#ebooks97>, <#ebooks21279>.

<#work97> a frbr:LiteraryWork;
dc:title "Flatland: a romance of many dimensions" ;
frbr:creator <#Abbott_Edwin>;
frbr:manifestation <ebook97>.

<#work21279> a frbr:LiteraryWork;
dc:title "2 B R 0 2 B" ;
frbr:creator <#Vonnegut_Kurt>;
frbr:manifestation <ebook21279>.
</nowiki>

Collections are potentially very large, so some means may be required to limit the size of RDF representation returned by the LDP (e.g. pagination).

===UC8: Manage media resources===
It should be possible to easily add non-RDF media resources to containers that accept them. Media resources may be updated and removed during the lifecycle of the container.

====Primary scenario: access media resources====
From the User Story [[#Sharing Binary Resources and Metadata| Sharing Binary Resources and Metadata]] it should be possible to easily add non RDF resources to a containers that accept them. Clients submit a non-RDF representation to a container in a media type accepted by that container. The container creates a URI to represent this media resource, and creates a link from the container to the new URI.The media resource may have an explicit representation of the media type. It should be possible to find the metadata about such a resource and to access and edit it in the usual ways.

This example uses the [http://www.w3.org/TR/mediaont-10/#ont-ttl Ontology for Media Resources] to describe a media resource added to a collection.
<nowiki>
@prefix ma: <http://www.w3.org/ns/ma-ont#> .

<dataset> a ma:Collection ;
:hasMember <dataset/image1.jpg>

<dataset/image1.jpg> a ma:MediaResource ;
ma:hasFormat "image/jpeg" .
</nowiki>

====Alternative scenario: media-resource attachments====
A resource may have multiple ''renditions''; the idea that you can have a PDF and a JPEG representing the same thing. A user is trying to create a work order along with an attached image showing a faulty machine part. To the user and to the work order system, these two artifacts are managed as a set. A single request may create the work order, the attachment, and the relationship between them, atomically.
When the user retrieves the work order later, they expect a single request by default to retrieve the work order plus all attachments.
When the user updates the work order, e.g. to mark it completed, they only want to update the work order proper, not its attachments.
Users may add/remove/replace attachments to the work order during its lifetime.

== Requirements ==

===Functional Requirements===
# Create Containers, from [[#UC1: Manage containers]]
# Creation of nested containers, from [[#UC1: Manage containers]]
# Creation of resources (within a container), from [[#UC2: Manage resources]]
# Deletion of resources, from [[#UC2: Manage resources]]
# Moving contained resources, from [[#UC2: Manage resources]]
# Retrieve resource description, from [[#UC3: Retrieve resource description]]
# Retrieve description of a non-document resource, from [[#UC3: Retrieve resource description]]
# Enrichment (substituting update of existing resource), from [[#UC4: Update existing resource]]
# Selective update of a resource, from [[#UC4: Update existing resource]]
# Determine if a resource has changed, from [[#UC5: Determine if a resource has changed]]
# Add a resource to a collection, from [[#UC6: Aggregate resources]]
# Add a resource to multiple collections, from [[#UC6: Aggregate resources]]
# Retrieve collection-level description, from [[#UC7: Filter resource description]]
# Retrieve item-level description of a collection, from [[#UC7: Filter resource description]]
# Access media resources, from [[#UC8: Manage media resources]]
# Media-resource attachments, from [[#UC8: Manage media resources]]

===Non-Functional Requirements===

# Provide access guidance to resources, from [[#UC1: Manage containers]]
# Non-duplication of resources, from [[#UC2: Manage resources]]
# Distribution of resources, from [[#UC2: Manage resources]]
# Consistent, global naming, from [[#UC2: Manage resources]]
# Use standard vocabularies as appropriate, from [[#UC3: Retrieve resource description]]
# Scalable linking model, from [[#UC3: Retrieve resource description]]
# Unrestricted vocabulary, from [[#UC4: Update existing resource]]
# Resource descriptions are a "mix of simple data and collections", from [[#UC6: Aggregate resources]]
# Relative URIs enabling sharing of collections, from [[#UC6: Aggregate resources]]

== Acknowledgements ==
We would like to acknowledge the contributions of user-story authors; Christophe Guéret, Roger Menday, Eric Prud'hommeaux.

== References ==

Use Cases And Requirements

Sbattle2 — Mon, 10 Dec 2012 11:20:46 GMT

Sbattle2: /* Requirements */

= Linked Data Platform Use Cases And Requirements =

This is a working document used to collect use cases and requirements for consideration by the WG.
The starting point comes from [http://www.w3.org/Submission/2012/SUBM-ldbpucr-20120326/ Linked Data Basic Profile Use Cases and Requirements].

== Steps to Complete ==

* <strike>Nov 26? WG to confirm User Story content: add, remove, refine (see process below). Note: this is ONLY User Stories (not Use Cases, Use Case Scenarios or Requirements)</strike>
** Issues before Nov 26th? will be included into FPWD
* Editors to:
** <strike>Dec 3 refine User Stories based on feedback</strike>
** <strike>Dec 5 elaborate on Use Cases in support of User Stories</strike>
* Dec 10 - WG to review prior to FPWD
** Review period ends Dec 15th
** insert open issues into draft for FPWD
* Dec 17 - Publish FPWD
** convert wiki page to ReSpec for FPWD
* Dec ?? Deadline for publications by year end 2012

===To Be Done===
* <strike>Move [[#LDP_and_Authentication.2FAuthorization| LDP and Authentication]] to [http://www.w3.org/2012/ldp/wiki/AccessControl AccessControl]</strike>
* <strike>Complete [[#Alternative_scenario:_moving_contained_resources| moving contained resources]] scenario with content from ericP on issue-30.</strike>
* Augment [[#Cloud_Infrastructure_Management| Cloud Infrastructure Management]] scenario with content from Roger Menday.
* <strike>Ensure issue-40/41 are fully covered in [[#UC8:_Managing_non-RDF_Resources| UC8: Managing non-RDF Resources]]. 2 scenarios (single v multiple attachments) ?</strike>
* <strike>Contact owner of [[#Data_Sharing| Data Sharing]] user-story to determine if we keep or not.</strike>
* Review [[#Requirements| Requirements]] section for functional/non-functional requirements arising in UCs.
* <strike>Propose resolutions to open issues against UC&R where possible.</strike>
* <strike>Identify and acknowledge user-story contributors.</strike>
* Check hyperlinks
* Convert to ReSpec
* Annotate document with open issues against UC&R
** [http://www.w3.org/2012/ldp/track/issues/30 ISSUE-30] (OPEN)
** [http://www.w3.org/2012/ldp/track/issues/40 ISSUE-40] (RAISED)
** [http://www.w3.org/2012/ldp/track/issues/41 ISSUE-41] (RAISED)

=== Process to introduce new User Stories & Use Cases ===

Open an Issue in the tracker against the UC&R product. The WG will review these and decide whether they are valid.

== Scope and Motivation ==

Linked Data was defined by Tim Berners-Lee with the following guidelines [http://www.w3.org/DesignIssues/LinkedData.html]:

# Use URIs as names for things
# Use HTTP URIs so that people can look up those names
# When someone looks up a URI, provide useful information, using the standards (RDF*, SPARQL)
# Include links to other URIs. so that they can discover more things

These four rules have proven very effective in guiding and inspiring people to publish Linked Data on the web. The amount of data, especially public data, available on the web has grown rapidly, and an impressive number of extremely creative and useful “mashups” have been created using this data as result.

There has been much less focus on the potential of Linked Data as a model for managing data on the web - the majority of the Application Programming Interfaces (APIs) available on the Internet for creating and updating data follow a Remote Procedure Call (RPC) model rather than a Linked Data model.

If Linked Data were just another model for doing something that RPC models can already do, it would be of only marginal interest. Interest in Linked Data arises from the fact that applications with an interface defined using Linked Data can be much more easily and seamlessly integrated with each other than applications that offer an RPC interface. In many problem domains, the most important problems and the greatest value are found not in the implementation of new applications, but in the successful integration of multiple applications into larger systems.

Some of the features that make Linked Data exceptionally well suited for integration include:

* A single interface – defined by a common set of HTTP methods – that is universally understood and is constant across all applications. This is in contrast with the RPC architecture where each application has a unique interface that has to be learned and coded to.
* A universal addressing scheme – provided by HTTP URLs – for both identifying and accessing all “entities”. This is in contrast with the RPC architecture where there is no uniform way to either identify or access data.
* A simple yet extensible data model – provided by RDF – for describing data about a resource in a way which doesn’t require prior knowledge of vocabulary being used.

Experience implementing applications and integrating them using Linked Data has shown very promising results, but has also demonstrated that the original four rules defined by Tim Berners-Lee for Linked Data are not sufficient to guide and constrain a writable Linked Data API. As was the case with the original four rules, the need generally is not for the invention of fundamental new technologies, but rather for a series of additional rules and patterns that guide and constrain the use of existing technologies in the construction of a Basic Profile for Linked Data to achieve interoperability.

The following list illustrates a few of the issues that require additional rules and patterns:
* What URLs do I post to in order to create new resources?
* How do I get lists of existing resources, and how do I get basic information about them without having to access each one?
* How should I detect and deal with race conditions on write?
* What media-types/representations should I use?
* What standard vocabularies should I use?
* What primitive data types should I use?

A good goal for the Basic Profile for Linked Data would be to define a specification required to allow the definition of a writable Linked Data API equivalent to the simple application APIs that are often written on the web today using the Atom Publishing Protocol (APP). APP shares some characteristics with Linked Data, such as the use of HTTP and URLs. One difference is that Linked Data relies on a flexible data model with RDF, which allows for multiple representations.

== Organization of this Document ==

This document is organized as follows:

* '''[[#User Stories| User Stories]]''' capture statements about system requirements written from a user or application perspective. They are typically lightweight and informal and can run from one line to a paragraph or two (sometimes described as an 'epic') [http://www.agilemodeling.com/artifacts/userStory.htm]. Analysis of each user story will reveal a number of (functional) use-cases and other non-functional requirements. See [http://www.w3.org/TR/dap-policy-reqs/| Device API Access Control Use Cases and Requirements] for a good example of user stories and their analysis.

* '''[[#Use Cases| Use Cases]]''' are used to capture and model functional requirements. Use cases describe the system’s behavior under various conditions [http://alistair.cockburn.us/get/2465], cataloguing who does what with the system, for what purpose, but without concern for system design or implementation [http://www.bredemeyer.com/pdf_files/functreq.pdf]. Each use case is identified by a reference number to aid cross-reference from other documentation; use-case indexing in this document is based on [http://www.w3.org/TR/rdb2rdf-ucr/ rdb2rdf use-cases]. A variety of styles may be used to capture use-cases, from a simple narrative to a structured description with actors, pre/post conditions, and step-by-step behaviours as in [http://www.w3.org/TR/powder-use-cases/ POWDER: Use Cases and Requirements], and non-functional requirements raised by the use-case. Use cases act like the hub of a wheel, with spokes supporting requirements analysis, scenario-based evaluation, testing, and integration with non-functional, or quality requirements.

* '''Scenarios''' are more focused still, representing a single instance of a use case in action. Scenarios may range from lightweight narratives as seen in [http://www.w3.org/TR/media-frags-reqs/ Use cases and requirements for Media Fragments], to being formally modeled as interaction diagrams. Each use-case should include at least a primary scenario, and possibly other alternative scenarios.

* '''[[#Requirements| Requirements]]''' list non-functional or quality requirements, and the use cases they may be derived from. This approach is exemplified in the [http://dvcs.w3.org/hg/gld/raw-file/default/dcat-ucr/index.html Use Cases and Requirements for the Data Catalog Vocabulary].

== User Stories ==

=== Maintaining Social Contact Information ===

Many of us have multiple email accounts that include information about the people and organizations we interact with – names, email addresses, telephone numbers, instant messenger identities and so on. When someone’s email address or telephone number changes (or they acquire a new one), our lives would be much simpler if we could update that information in one spot and all copies of it would automatically be updated. In other words, those copies would all be linked to some definition of “the contact.” There might also be good reasons (like off-line email addressing) to maintain a local copy of the contact, but ideally any copies would still be linked to some central “master.”

Agreeing on a format for “the contact” is not enough, however. Even if all our email providers agreed on the format of a contact, we would still need to use each provider’s custom interface to update or replace the provider’s copy, or we would have to agree on a way for each email provider to link to the “master”. If we look outside our own personal interests, it would be even more useful if the person or organization exposed their own contact information so we could link to it.

What would work in either case is a common understanding of the resource, a few formats needed, and access guidance for these resources. This would support how to acquire a link to a contact, and how to use those links to interact with a contact (including [[#UC3: Retrieve resource description|reading]], [[#UC4: Update existing resource|updating]], and [[#Alternative scenario: delete resource|deleting]] it), as well as how to easily [[#Primary scenario: create resource|create a new contact]] and add it to my contacts and when deleting a contact, how it would be removed from my list of contacts. It would also be good to be able to add some application-specific data about my contacts that the original design didn’t consider. Ideally we’d like to eliminate multiple copies of contacts, there would be additional valuable information about my contacts that may be stored on separate servers and need a simple way to link this information back to the contacts. Regardless of whether a contact collection is my own, shared by an organization, or all contacts known to an email provider (or to a single email account at an email provider), it would be nice if they all worked pretty much the same way.

=== Keeping Track of Personal and Business Relationships ===

In our daily lives, we deal with many different organizations in many different relationships, and they each have data about us. However, it is unlikely that any one organization has all the information about us. Each of them typically gives us access to the information (at least some of it), many through websites where we are uniquely identified by some string – an account number, user ID, and so on. We have to use their applications to interact with the data about us, however, and we have to use their identifier(s) for us. If we want to build any semblance of a holistic picture of ourselves (more accurately, collect all the data about us that they externalize), we as humans must use their custom applications to find the data, copy it, and organize it to suit our needs.

Would it not be simpler if at least the Web-addressable portion of that data could be linked to consistently, so that instead of maintaining various identifiers in different formats and instead of having to manually supply those identifiers to each one’s corresponding custom application, we could essentially build a set of bookmarks to it all? When we want to [[#UC3: Retrieve resource description|examine]] or [[#UC4: Update existing resource|change]] their contents, would it not be simpler if there were a single consistent application interface that they all supported? Of course it would.

Our set of links would probably be a [[#UC6: Aggregate resources|simple collection]]. The information held by any single organization might be a mix of simple data and [[#UC6: Aggregate resources|collections of other data]], for example, a bank account balance and a collection of historical transactions. Our bank might easily have [[#Alternative scenario: create a nested container|a collection of accounts for each of its collection of customers]].

=== System and Software Development Tool Integration ===

System and software development tools typically come from a diverse set of vendors and are built on various architectures and technologies. These tools are purpose built to meet the needs for a specific domain scenario (modeling, design, requirements and so on.) Often tool vendors view integrations with other tools as a necessary evil rather than providing additional value to their end-users. Even more of an afterthought is how these tools’ data -- such as people, projects, customer-reported problems and needs -- integrate and relate to corporate and external applications that manage data such as customers, business priorities and market trends. The problem can be isolated by standardizing on a small set of tools or a set of tools from a single vendor, but this rarely occurs and if does it usually does so only within small organizations. As these organizations grow both in size and complexity, they have needs to work with outsourced development and diverse internal other organizations with their own set of tools and processes. There is a need for better support of more complete business processes (system and software development processes) that span the roles, tasks, and data addressed by multiple tools. This demand has existed for many years, and the tools vendor industry has tried several different architectural approaches to address the problem. Here are a few:

* Implement an API for each application, and then, in each application, implement “glue code” that exploits the APIs of other applications to link them together.
* Design a single database to store the data of multiple applications, and implement each of the applications against this database. In the software development tools business, these databases are often called “repositories.”
* Implement a central “hub” or “bus” that orchestrates the broader business process by exploiting the APIs described previously.

It is fair to say that although each of those approaches has its adherents and can point to some successes, none of them is wholly satisfactory. The use of Linked Data as an application integration technology has a strong appeal. [http://open-services.net/ OSLC]

=== Library Linked Data ===

The W3C Library Linked Data working group has a number of use cases cited in their Use Case Report. [http://www.w3.org/2005/Incubator/lld/wiki/UseCaseReport LLD-UC] These referenced use cases focus on the need to extract and correlate library data from disparate sources. Variants of these use cases that can provide consistent formats, as well as ways to improve or update the data, would enable simplified methods for both efficiently sharing this data as well as producing incremental updates without the need for repeated full extractions and import of data.

The 'Digital Objects Cluster' contains a number of relevant use-cases:

* Grouping: This should "Allow the end-users to define [[#UC6: Aggregate resources|groups of resources]] on the web that for some reason belong together. The relationship that exists between the resources is often left unspecified. Some of the resources in a group may not be under control of the institution that defines the groups."

* Enrichment: "Enable end-users to [[#UC4: Update existing resource|link resources together]]."

* Browsing: "[[#UC7: Filter resource description|Support end-user browsing through groups]] and resources that belong to the groups."

* Re-use: "Users should have the capability to re-use all or parts of a collection, with all or part of its metadata, elsewhere on the linked Web."

The 'Collections' cluster also contains a number of relevant use-cases:

* Collection-level description: "Provide [[#UC7: Filter resource description|metadata pertaining to a collection as a whole]], in contrast to item-level description."

* Collections discovery: "Enable innovative collection discovery such as identification of nearest location of a physical collection where a specific information resource is found or mobile device applications ... based on collection-level descriptions."

* Community information services: Identify and classify collections of special interest to the community.

=== Municipality Operational Monitoring ===

Across various cities, towns, counties, and various municipalities there is a growing number of services managed and run by municipalities that produce and consume a vast amount of information. This information is used to help monitor services, predict problems, and handle logistics. In order to effectively and efficiently collect, produce, and analyze all this data, a fundamental set of loosely coupled standard data sources are needed. A simple, low-cost way to [[#UC3: Retrieve resource description|expose data]] from the diverse set of monitored services is needed, one that can easily integrate into the municipalities of other systems that inspect and analyze the data. All these services have links and dependencies on other data and services, so having a simple and scalable linking model is key.

=== Healthcare ===

For physicians to analyze, diagnose, and propose treatment for patients requires a vast amount of complex, changing and growing knowledge. This knowledge needs to come from a number of sources, including physicians’ own subject knowledge, consultation with their network of other healthcare professionals, public health sources, food and drug regulators, and other repositories of medical research and recommendations.

To diagnose a patient’s condition requires current data on the patient’s medications and medical history. In addition, recent pharmaceutical advisories about these medications are linked into the patient’s data. If the patient experiences adverse affects from medications, these physicians need to publish information about this to an appropriate regulatory source. Other medical professionals require access to both validated and emerging effects of the medication. Similarly, if there are geographical patterns around outbreaks that allow both the awareness of new symptoms and treatments, this information needs to quickly reach a very distributed and diverse set of medical information systems. Also, reporting back to these regulatory agencies regarding new occurrences of an outbreak, including additional details of symptoms and causes, is critical in producing the most effective treatment for future incidents.

=== Metadata Enrichment in Broadcasting ===

There are many different use cases when broadcasters show interest in metadata [[#UC4: Update existing resource| enrichment]]:

* enrich archive or news metadata by linking facts, events, locations and personalities
* enrich metadata generated by automatic extraction tools such as person identification, etc.
* enrich definitions of terms in classification schemes or enumeration lists

This comes in support of more effective information management and data/content mining (if you can't find your content, it' like if you don't have and must either recreate or acquire it again, which is not financially effective).

However, there is a need for solutions facilitating linkage to other data sources and taking care of the issues such as discovery, automation, disambiguation. Etc. Other important issues that broadcasters would face are the editorial quality of the linked data, its persistence, and usage rights.

=== Aggregation and Mashups of Infrastructure Data ===

For infrastructure management (such as storage systems, virtual machine environments, and similar IaaS and PaaS concepts), it is important to provide an environment in which information from different sources can be [[#UC6: Aggregate resources|aggregated]], [[#UC7: Filter resource description|filtered]], and visualized effectively. Specifically, the following use cases need to be taken into account:

* While some data sources are based on Linked Data, others are not, and aggregation and mashups must work across these different sources.
* Consumers of the data sources and aggregated/filtered data streams are not necessarily implementing Linked Data themselves, they may be off-the-shelf components such as dashboard frameworks for composing visualizations.
* Simple versions of this scenario are pull-based, where the data is requested from data sources. In more advanced settings, without a major change in architecture it should be possible to move to a push-based interaction model, where data sources push notifications to subscribers, and data sources provide different services that consumers can subscribe to (such as "informational messages" or "critical alerts only").

In this scenario, the important factors are to have abstractions that allow easy aggregation and filtering, are independent from the internal data model of the sources that are being combined, and can be used for pull-based interactions as well as for push-based interactions.

=== Sharing payload of RDF data among low-end devices ===

Several projects around the idea of [http://worldwidesemanticweb.wordpress.com/ downscaling the Semantic Web] need to be able to ship payloads of RDF across the nodes member of a given network. The transfers are done in a constrained context in terms of bandwidth, scope of the local semantics employed by the nodes and computing capabilities of the nodes. In a P2P style, every node has the capability to act either as a data consumer or a data provider, serving its own data or acting as a relay to pass other's data along (typically in mesh networks).

The transfer of an arbitrary payload of RDF data could be implemented through the container mechanism, adding and removing sets of RDF triples to it. Currently, one of the project "SemanticXO" uses named graphs and the graph protocol to create/delete/copy graphs across the nodes but this (almost) imposes the usage of a triple store. Unfortunately, triple store are rather demanding piece of software that are not always usable on limited hardware. Some generic ReST like interaction backed up with a lightweight column store would be better approach.

=== Sharing Binary Resources and Metadata ===

When publishing datasets about stars one may want to publish links to the pictures in which those stars appear, and this may well require publishing the pictures themselves. Vice versa: when publishing a picture of space we need to know which telescope took the picture, which part of the sky it was pointing at, what filters were used, which identified stars are visible, who can read it, who can write to it, ...

If LinkedData contains information about resources that are most naturally expressed in non-rdf formats (be they binary such as pictures or videos, or human readable documents in XML formats), those non RDF formats should be just as easy to publish to the LinkedData server as the RDF relations that link those resources up. A LinkedData server should therefore allow publishing of non linked data resources too, and make it easy to publish and edit metadata about those resources.

The resource comes in two parts - the image and information about the image (which may in the image file but better external to it as it's more general). The information about the image is vital. It's a compound item of image data and other data (being application metadata about the image does not distinguish from the platform's point-of-view.

=== Data Catalogs ===

The Asset Description Metadata Schema ([http://joinup.ec.europa.eu/asset/adms/home ADMS]) provides the data model to describe semantic assets repositories contents, but this leaves many open challenges when building a federation of these repositories to serve the need of assets reuse. These include accessing and querying individual repositories and efficiently retrieving [[#UC5: Determine if a resource has changed| updated content]] without having to retrieve the whole content. Hence, we chose to build the integration solution capitalizing on the Data Warehousing integration approach. This allows us to cope with heterogeneity of sources technologies and to benefit from the optimized performance it offers, given that individual repositories do not usually change frequently. With Data Warehousing, the federation requires to:

* understand the data, i.e. understand their semantic descriptions, and other systems.
* seamlessly exchange the semantic assets metadata from different repositories
* keep itself up-to-date.

Repositories owners can maintain de-referenceable URIs for their repository description and contained assets in a Linked Data compatible manner. ADMS provides the necessary data model to enable meaningful exchange of data. However, This leaves the challenge of efficient access to the data not fully addressed.

Related: [http://spec.datacatalogs.org/ Data Catalog Schema and Protocol]

=== Constrained Devices and Networks ===

Information coming from resource constrained devices in the Web of Things ([http://en.wikipedia.org/wiki/Web_of_Things WoT]) has been identified as a major driver in many domains, from smart cities to environmental monitoring to real-time tracking. The amount of information produced by these devices is growing exponentially and needs to be accessed and integrated in a systematic, standardized and cost efficient way. By using the same standards as on the Web, integration with applications will be simplified and higher-level interactions among resource constrained devices, abstracting away heterogeneities, will become possible. Up-coming IoT/WoT standards such as [http://datatracker.ietf.org/wg/6lowpan/ 6LowPAN] - IPv6 for resource constrained devices - and the Constrained Application Protocol ([http://tools.ietf.org/html/draft-ietf-core-coap CoAP]), which provides a downscaled version of HTTP on top of UDP for the use on constrained devices, are already at a mature stage. The next step now is to support RESTful interfaces also on resource constrained devices, adhering to the Linked Data principles. Due to the limited resources available, both on the device and in the network (such as bandwidth, energy, memory) a solution based on SPARQL Update is at the current point in time considered not to be useful and/or feasible. An approach based on the [http://tools.ietf.org/html/draft-castellani-core-http-mapping HTTP-CoAP Mapping] would enable constrained devices to directly participate in a Linked Data-based environment.

=== Services Supporting the Process of Science ===
Many fields of science now include branches with in silico data-intensive methods, e.g. bioinformatics, astronomy. To support these new methods we look to move beyond the established platforms provided by scientific workflow systems to capture, assist, and preserve the complete lifecycle from record of the experiment, through local trusted sharing, analysis, dissemination (including publishing of experimental data "beyond the PDF"), and re-use.

* [[#UC6: Aggregate resources|Aggregations]], specifically ''Research Objects (ROs)'' that are exchanged between services and clients bringing together workflows, data sets, annotations, and provenance. We use an RDF model for this. While some aggregated contents are encoded using RDF and in increasing number are linked data sources, others are not; while some are stored locally "within" the RO, others are remote (in both cases this is often due to size of the resources or access policies).
* Services that are distributed and linked. Some may be centralising for e.g. publication, others may be local, e.g. per lab. We need lightweight services that can be simply and easily integrated into and scale across the wide variety of softwares and data used in science: we have adopted a RESTful approach where possible.
** Foundation services that collect and expose ROs for storage, modification, exploration, and reuse.
** Services that provide added-value to ROs such as seamless import/export from scientific workflow systems, automated stability evaluation, or recommendation (and therefore interact with the foundation services to retrieve/store/modify/ROs).

seeAlso: [http://www.wf4ever-project.org/ Wf4Ever]

=== Project Membership Information : Information Evolution ===

Information about people and projects changes as roles change, as organisations change
and as contact details change. Finding the current state of a project is important
in enabling people to contact the right person in the right role. It can also be
useful to look back and see who was performing what role in the past.

A use of a Linked Data Platform could be to give responsibility for managing
such information with the project team itself, not requiring updates to be
requested of a centralised website administrator.

This could be achieved with:

* Resource descriptions for each person and project
* A container resource to describe roles/membership in the project.

To retain the history of the project, the old version of a resources,
including container resources, should be retained so there is a need to address both specific items
and also have a notion of "current".

Access to information has two aspects:
* Access to the "current" state, regardless of the version of the resource description
* Access to historical state, via access to a specific version of the resource description

=== Cloud Infrastructure Management===

Cloud operators offer API support to provide customers with remote access for infrastructure management. Infrastructure consists of Systems, Computers, Networks, Discs, etc, and the overall structure can be seen as mostly hierarchical, (Cloud contains Systems, Systems contain Machines, etc). This is complemented with crossing links (e.g. Machines connected to a Network). The IaaS scenario also makes requirements for lifecycle management, non-instant changes and history capture. Infrastructure management can be seen as the manipulation of the underlying graph.

== Use Cases ==
The following use-cases are each derived from one or more of the user-stories above. These use-cases are explored in detail through the development of scenarios, each motivated by some key aspect exemplified by a single user-story. The examples they contain are included purely for illustrative purposes, and should not be interpreted normatively.

===UC1: Manage containers===
A number of user-stories introduce the idea of a ''container'' as a mechanism for creating and managing resources within the context of an application. Resources grouped together within the same container would typically belong to the same application. A container is identified by a URI so is a resource in its own right.
The properties of a container may also represent the ''affordances'' of that container, enabling clients to determine what other operations they can do on that container. These operations may include descriptions of application specific services that can be invoked by exchanging RDF documents.

* Provide "access guidance for ... resources" (affordances) (from user-story, [[#Maintaining Social Contact Information|Maintaining Social Contact Information]]).

====Primary scenario: create container====
Create a new container resource within the LDP server.
In [[#Services Supporting the Process of Science|Services supporting the process of science]], [http://wf4ever.github.com/ro-primer/ Research Objects] are semantically rich aggregations of resources that bring together data, methods and people in scientific investigations. A basic workflow research object will be created to aggegate [http://ceur-ws.org/Vol-903/paper-01.pdf scientific workflows] and the artefacts that result from this workflow. The research object begins life as an empty container into which workflows, datasets, results and other data will be added throughout the lifecycle of the project.

<nowiki>
@prefix ro: http://purl.org/wf4ever/ro#
@prefix dct: http://purl.org/dc/terms/
@prefix ore: http://www.openarchives.org/ore/

<> a ro:ResearchObject, ore:Aggregation ;
dct:created "2012-12-01"^^xsd:dateTime .
</nowiki>

====Alternative scenario: create a nested container====
The motivation for nested containers comes from the [[#System and Software Development Tool Integration| System and Software Development Tool Integration]] user-story. The OSLC Change Management vocabulary allows bug reports to have attachments referenced by the membership predicate <nowiki>oslc_cm:attachment</nowiki>. The 'top-level-container' contains issues, and each issue resource has its own container of attachment resources.

<nowiki>
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix oslc_cm: <http://open-services.net/ns/cm#>.
@prefix : <http://example.org/>.

:top-level-container rdfs:member :issue1234 .

:issue1234 a oslc_cm:ChangeRequest;
dcterms:identifier "1234";
dcterms:type "a bug";
dcterms:related :issue1235 ;
oslc_cm:attachments :attachments123.

:issue1235 a oslc_cm:ChangeRequest;
dcterms:title "a related bug".

:attachments a oslc_cm:AttachmentList;
oslc_cm:attachment :attachment324, :attachment251.
</nowiki>

===UC2: Manage resources===
This use-case addresses the managed lifecycle of a resource and is concerned with resource ''ownership''. The responsibility for managing resources belongs with their container.
For example, a container may accept a request from a client to make a new resource.
This use-case focuses on creation and deletion of resources in the context of a container, and the potential for transfer of ownership by moving resources between containers.
The ownership of a resource should always be clear; no resource managed in this way should ever be owned by more than one container.

Once a new resource has been created it should be identified by a URI. Clients may defer responsibility for establishing dereferenceable URIs to the container of their data.
The container is a natural choice for the endpoint for this interface as it will already have some application-specific knowledge about the contained resources.
While the LDP has ultimate control over resource naming, some applications may require more control over naming, perhaps to provide a more human-readable URI. An LDP server could support something like the [http://tools.ietf.org/html/rfc5023 Atom Publishing Protocol] slug header to convey a user defined naming 'hint'.

* Non-duplication of resources: "Eliminate multiple copies", representing resources in a single place (from [[#Maintaining Social Contact Information]]).
* Distribution of resources: Linked aata "may be stored on separate servers" (from [[#Maintaining Social Contact Information]]).
* Consistent, global naming: Resources should be "linked to consistently, ... instead of maintaining various identifiers in different formats" (from [[#Keeping Track of Personal and Business Relationships]]).

====Primary scenario: create resource====
Resources begin life by being created within a container. From user-story, [[#Maintaining Social Contact Information|Maintaining Social Contact Information]], It should be possible to "easily create a new contact and add it to my contacts." This suggests that resource creation is closely linked to the application context. The new resource is created in a container representing "my contacts." The lifecycle of the resource is linked to the lifecycle of it's container. So, for example, if "my contacts" is deleted then a user would also reasonably expect that all contacts within it would also be deleted.

Contact details are captured as an RDF description and it's properties, including "names, email addresses, telephone numbers, instant messenger identities and so on." The description may include non-standard RDF; "data about my contacts that the original design didn’t consider."
The following RDF could be used to describe contact information using the [http://www.foaf-project.org FOAF] vocabulary. A contact is represented here by a <nowiki>foaf:PersonalProfileDocument</nowiki> defining a resource that can be created and updated as a single-unit, even though it may describe ancillary resources, such as a <nowiki>foaf:Person</nowiki>, below.

<nowiki>
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

<> a foaf:PersonalProfileDocument;
foaf:PrimaryTopic [
a foaf:Person;
foaf:name "Timothy Berners-Lee";
foaf:title "Sir";
foaf:firstName "Timothy";
foaf:surname "Berners-Lee";
foaf:nick "TimBL", "timbl";
foaf:homepage <http://www.w3.org/People/Berners-Lee/>;
foaf:weblog <http://dig.csail.mit.edu/breadcrumbs/blog/4>;
foaf:mbox <mailto:timbl@w3.org>;
foaf:workplaceHomepage <http://www.w3.org/>.
]
</nowiki>

====Alternative scenario: delete resource====
Delete a resource and all it's properties. If the resource resides within a container it will be removed from that container, however other links to the deleted resource may be left as dangling references.
In the case where the resource is a container, the server may also delete any or all contained resources.
In normal practice, a deleted resource cannot be reinstated. There are however, edge-cases where limited undelete may be desirable.
Best practice states that "[http://www.w3.org/TR/cooluris/| Cool URIs don't change]", which implies that deleted URIs shouldn't be recycled.

====Alternative scenario: moving contained resources====
Many resources may have value beyond the life of their membership in a container. This implies methods to add references to revise container membership.
Cloning container members for use in other containers results in duplication of information and maintenance problems; web practice is to encourage the creation of one resource, which may be referenced as many places as necessary. A change of ownership may - or may not - imply a change of URI, depending upon the specific LDP naming policy. While assigning a new URI to a resource is discouraged [http://www.w3.org/DesignIssues/Architecture.html#HTTP], it is possible to indicate that a resource has moved with an appropriate HTTP response.

===UC3: Retrieve resource description===
Access the current description of a resource, containing properties of that resource and links to related resources. The representation may include descriptions of related resources that cannot be accessed directly.
Depending upon the application, an LDP may enrich the retrieved RDF with additional triples. Examples include adding incoming links, sameAs closure and type closure.
The HTTP response should also include versioning information (i.e. last update or entity tag) so that subsequent updates can ensure they are being applied to the correct version.

* Use standard vocabularies as appropriate to enable a "common understanding of the resource" (from [[#Maintaining Social Contact Information|Maintaining Social Contact Information]]).
* A "scalable linking model is key" (from [[#Municipality Operational Monitoring]]).

====Primary scenario====
The user-story [[#Project Membership Information : Information Evolution| Project Membership Information]] discusses the representation of information about people and projects. It calls for "Resource descriptions for each person and project" allowing project teams to review information held about these resources. The example below illustrates the kinds of information that might be held about organizational structures based on the [http://www.epimorphics.com Epimorphics] [http://www.epimorphics.com/public/vocabulary/org.html organizational ontology].

Note that the example below defines two resources (shown as separate sections below) that will be hosted on an LDP based at <nowiki>http://example.com/</nowiki>. The representations of these resources may include descriptions of related resources, such as <nowiki>http://www.w3.org/</nowiki>, that that fall under a different authority and therefore can't be served from the LDP at this location.

<nowiki>
@prefix org: <http://www.w3.org/ns/org#> .
@prefix owltime: <http://www.w3.org/2006/time> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@base <http://example.com/> .

<member1> a org:Membership ;
org:member <http://www.w3.org/People/Berners-Lee/card#i> ;
org:organization http://www.w3.org/> ;
org:role <director> ;
org:memberDuring [a owltime:Interval; owltime:hasBeginning [
owltime:inXSDDateTime "1994-10-01T00:00:00Z"^^xsd:dateTime]] .

<http://www.w3.org/> a org:FormalOrganization ;
skos:prefLabel "The World Wide Web Consortium"@en ;
skos:altLabel "W3C" .
</nowiki>

<nowiki>
@prefix org: <http://www.w3.org/ns/org#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@base <http://example.com/> .

<director> a org:Role ;
rdfs:label "Director" .
</nowiki>

====Alternative scenario: retrieve description of a non-document resource====
In many cases, the things that are of interest are not always the things that are resolvable. The example below demonstrates how a foaf profile may be used to distinguish between the person and the profile; the former being the topic of the latter. This begs the question as to what a client should do with such non-document resources. In this case the HTTP protocol requires that the fragment part be stripped off before requesting the URI from the server. The result is a resolvable URI for the profile.

<nowiki>
@base <http://www.w3.org/People/Berners-Lee/card>
@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@prefix dc: <http://purl.org/dc/elements/1.1/>.

<> a foaf:PersonalProfileDocument ;
dc:title "Tim Berners-Lee's FOAF file" ;
foaf:homepage <http://www.w3.org/People/Berners-Lee/> ;
foaf:primaryTopic <#i> .
</nowiki>

===UC4: Update existing resource===
Change the RDF description of a LDP resource, potentially removing or overwriting existing data. This allows applications to ''enrich'' the representation of a resource by addling additional links to other resources.

* Unrestricted vocabulary: It should be possible be "able to add ... application-specific data" to resources (from [[#Maintaining Social Contact Information]]).

====Primary scenario: enrichment====
This relates to user-story [[#Metadata Enrichment in Broadcasting| Metadata Enrichment in Broadcasting]] and is based on the [http://www.bbc.co.uk/ontologies/sport/ BBC Sports Ontology]. The ''resource-centric'' view of linked-data provides a natural granularity for substituting, or overwriting a resource and its data. The simplest kind of update would simply replace what is currently known about a resource with a new representation. There are two distinct resources in the example below; a sporting event and an associated award. The granularity of the LDP would allow a user to replace the information about the award without disturbing the information about the event.

<nowiki>
@prefix sport: <http://www.bbc.co.uk/ontologies/sport/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

:mens_sprint a sport:MultiStageCompetition;
rdfs:label "Men's Sprint";
sport:award <#gold_medal> .

<#gold_medal> a sport:Award .
</nowiki>

We can enrich the description as events unfold, linking to the winner of the gold medal by substituting the above description with the following.

<nowiki>
@prefix sport: <http://www.bbc.co.uk/ontologies/sport/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

:mens_sprint a sport:MultiStageCompetition;
rdfs:label "Men's Sprint";
sport:award <#gold_medal> .
<#gold_medal> a sport:Award;
sport:awarded_to [
a foaf:Agent ;
foaf:name "Chris Hoy" .
] .
</nowiki>

====Alternative scenario: selective update of a resource====
This relates to user-story [[#Data Catalogs|Data Catalogs]], based on the [http://vocab.deri.ie/dcat Data Catalog Vocabulary].
A catalogue is described by the following RDF model.

<nowiki>
@prefix dcat: <http://www.w3.org/ns/dcat#> .
@prefix dcterms: <http://purl.org/dc/terms/> .

:catalog a dcat:Catalog ;
dcat:dataset :dataset/001;
dcterms:issued "2012-12-11"^^xsd:date.
</nowiki>

A catalog may contain multiple datasets, so when linking to new datasets it would be simpler and preferable to selectively add just the new dataset links.
A Talis ''changeset'' [http://docs.api.talis.com/getting-started/changesets][http://www.w3.org/2009/12/rdf-ws/papers/ws07] could be used to add a new <nowiki>dc:title</nowiki> to the dataset. The following update would be directed to the catalogue to add an additional dataset.

<nowiki>
@prefix : <http://example.com/>.
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix cs: <http://purl.org/vocab/changeset/schema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.

<change1>
a cs:ChangeSet ;
cs:subjectOfChange :catalog ;
cs:createdDate "2012-01-01T00:00:00Z" ;
cs:changeReason "Update catalog datasets" ;
cs:addition [
a rdf:Statement ;
rdf:subject :catalog ;
rdf:predicate dcat:dataset ;
rdf:object :dataset/002 .
] .
</nowiki>

===UC5: Determine if a resource has changed===
It should be possible to retrieve versioning information about a resource (e.g. last modified or entity tag) without having to download a representation of the resource.
This information can then be compared with previous information held about that resource to determine if it has changed.
This versioning information can also be used in subsequent ''conditional'' requests to ensure they are only applied if the version is unchanged.

====Primary scenario====
Based on the user-story, [[#Constrained Devices and Networks| Constrained Devices and Networks]], an LDP could be configured to act as a proxy for a [http://tools.ietf.org/html/draft-ietf-core-coap CoAP] based [http://en.wikipedia.org/wiki/Web_of_Things Web of Things]. As an observer of CoAP resources, the LDP registers its interest so that it will be notified whenever the sensor reading changes. Clients of the LDP can interrogate the LDP to determine if the state has changed.

In this example, the information about a sensor and corresponding sensor readings can be represented as RDF resources. The first resource below, represents a sensor described using the [http://www.w3.org/2005/Incubator/ssn/ Semantic Sensor Network] ontology.
<nowiki>
@prefix : <http://example.com/energy-management/>.

<> a :MainsFrequencySensor;
rdfs:comment "Sense grid load based on mains frequency";
ssn:hasMeasurementCapability [
a :FrequencyMeasurementCapability;
ssn:hasMeasurementProperty <#property_1> .
] .
</nowiki>

The value of the sensor changes in real-time as measurements are taken. The LDP client can interrogate the resource below to determine if it has changed, ''without'' necessarily having to download the RDF representation. As different sensor properties are represented disjointly (separate RDF representations) they may change independently.

<nowiki>
@prefix : <http://example.com/energy-management/>.

<http://example.com/energy-management#property_1> :hasMeasurementPropertyValue <> .
<> a :FrequencyValue;
:hasQuantityValue "50"^^xsd:float.
</nowiki>

===UC6: Aggregate resources===
There is a requirement to be able to manage ''collections'' of resources. The concept of a collection overlaps with, but is distinct from that of a container. These collections are (weak) aggregations, unrelated to the lifecycle management of resources, and distinct from the ownership between a resource and its container. However, the composition of a container may be reflected as a collection to support navigation of the container and its contents. There is a need to be able to create collections by adding and deleting individual membership properties. Resources may belong to multiple collections, or to none.

* Resource descriptions are a "mix of simple data and collections" (from [[#Keeping Track of Personal and Business Relationships]]).
* Relative URIs: It should be possible to "ship payloads of RDF" for a collection as a whole without breaking internal links (from [[#Constrained Devices and Networks]]).

====Primary scenario: add a resource to a collection====
This example is from [[#Library Linked Data|Library Linked Data]] and [http://www.w3.org/2005/Incubator/lld/wiki/UseCaseReport LLD-UC], specifically [http://www.w3.org/2005/Incubator/lld/wiki/Use_Case_Subject_Search Subject Search].

There is an existing collection at <nowiki><http://example.com/concept-scheme/subject-heading></nowiki> that defines a collection of subject headings. This collection is defined as a skos:ConceptScheme and
the client wishes to insert a new concept into the scheme. which will be related to the collection via a <nowiki>skos:inScheme</nowiki> link. The new subject-heading, "outer space exploration", is not necessarily owned by a container. The following RDF would be added to the (item-level) description of the collection.

<nowiki>
@prefix scheme : <http://example.com/concept-scheme/>.
@prefix concept : <http://example.com/concept/>.

scheme:subject-heading a skos:ConceptScheme.

concept:Outer+space+Exploration skos:inScheme scheme:subject-heading.
</nowiki>

====Alternative scenario: add a resource to multiple collections====
Logically, a resource should not be owned by more than one container. however, it may be a member of multiple collections which define a weaker form of ''aggregation''. As this is simply a manipulation of the RDF description of a collection, it should be possible to add the same resource to multiple collections.

As a machine-readable collection of medical terms, the [http://www.ihtsdo.org| SNOMED] ontology is of key importance in [[#Healthcare | healthcare]]. SNOMED CT allows concepts with more than one parent that don't fall into a lattice.
In the example below, the same concept may fall under two different parent concepts.
The example uses skos:narrowerTransitive to elide intervening concepts.

<nowiki>
@prefix : <http://example.com/snomed/>.

:_119376003 a skos:Concept ;
skos:prefLabel "Tissue specimen"
skos:narrowerTransitive :TissueSpecimenFromHeart.

:_127462005 a skos:Concept ;
skos:prefLabel "Specimen from heart"
skos:narrowerTransitive :TissueSpecimenFromHeart.

:_128166000 a skos:Concept;
rdfs:label "Tissue specimen from heart".
</nowiki>

===UC7: Filter resource description===
This use-case extends the normal behaviour of retrieving an RDF description of a resource, by dynamically excluding specific (membership) properties.
For containers, it is often desirable to be able to read a collection, or item-level description that excludes the container membership.

====Primary scenario: retrieve collection-level description====
This scenario, based on [[#Library Linked Data| Library Linked Data]], uses the Dublin Core Metadata Initiative [http://dublincore.org/groups/collections/collection-application-profile/| Collection-Level] description.
A collection can refer to any aggregation of physical or digital items.
This scenario covers the case whereby a client can request a collection-level description as typified by the example below, without necessarily having to download a full listing of the items within the collection.

<nowiki>
@prefix rdf: <rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">.
@prefix dc: <http://purl.org/dc/elements/1.1/>.
@prefix : <http://example.org/bookshelf/>.
@prefix dcmitype: <http://purl.org/dc/dcmitype/>.
@prefix cld: <http://purl.org/cld/terms/>.
@prefix dcterms: <http://purl.org/dc/terms/>.

<> dc:type dcmitype:Collection ;
dc:title "Directory of organizations working with Linked Data" ;
dcterms:abstract "This is a directory of organisations specializing in Linked Data."
cld:isLocatedAt <http://dir.w3.org>
cld:isAccessedVia <http://dir.w3.org/rdf/2012/directory/directory-list.xhtml?construct>
</nowiki>

====Alternative scenario: retrieve item-level description of a collection====
This use-case scenario, also based on [[#Library Linked Data| Library Linked Data]], focuses on obtaining an item-level description of the resources aggregated by a collection.
The simplest scenario is where the members of a collection are returned within a single representation, so that a client can explore the data by following these links. Different applications may use different membership predicates to capture this aggregation. The example below uses <nowiki>rdfs:member</nowiki>, but many different membership predicates are in common use, including RDF Lists.
Item-level descriptions can be captured using the Functional Requirements for Bibliographic Records ([http://www.ifla.org/publications/functional-requirements-for-bibliographic-records FRBR]) [http://vocab.org/frbr/core.html ontology].

<nowiki>
@prefix frbr: <http://purl.org/vocab/frbr/core#>.

<> rdfs:member <#ebooks97>, <#ebooks21279>.

<#work97> a frbr:LiteraryWork;
dc:title "Flatland: a romance of many dimensions" ;
frbr:creator <#Abbott_Edwin>;
frbr:manifestation <ebook97>.

<#work21279> a frbr:LiteraryWork;
dc:title "2 B R 0 2 B" ;
frbr:creator <#Vonnegut_Kurt>;
frbr:manifestation <ebook21279>.
</nowiki>

Collections are potentially very large, so some means may be required to limit the size of RDF representation returned by the LDP (e.g. pagination).

===UC8: Manage media resources===
It should be possible to easily add non-RDF media resources to containers that accept them. Media resources may be updated and removed during the lifecycle of the container.

====Primary scenario: access media resources====
From the User Story [[#Sharing Binary Resources and Metadata| Sharing Binary Resources and Metadata]] it should be possible to easily add non RDF resources to a containers that accept them. Clients submit a non-RDF representation to a container in a media type accepted by that container. The container creates a URI to represent this media resource, and creates a link from the container to the new URI.The media resource may have an explicit representation of the media type. It should be possible to find the metadata about such a resource and to access and edit it in the usual ways.

This example uses the [http://www.w3.org/TR/mediaont-10/#ont-ttl Ontology for Media Resources] to describe a media resource added to a collection.
<nowiki>
@prefix ma: <http://www.w3.org/ns/ma-ont#> .

<dataset> a ma:Collection ;
:hasMember <dataset/image1.jpg>

<dataset/image1.jpg> a ma:MediaResource ;
ma:hasFormat "image/jpeg" .
</nowiki>

====Alternative scenario: media-resource attachments====
A resource may have multiple ''renditions''; the idea that you can have a PDF and a JPEG representing the same thing. A user is trying to create a work order along with an attached image showing a faulty machine part. To the user and to the work order system, these two artifacts are managed as a set. A single request may create the work order, the attachment, and the relationship between them, atomically.
When the user retrieves the work order later, they expect a single request by default to retrieve the work order plus all attachments.
When the user updates the work order, e.g. to mark it completed, they only want to update the work order proper, not its attachments.
Users may add/remove/replace attachments to the work order during its lifetime.

== Requirements ==

===Functional Requirements===
# Create Containers, from [[#UC1: Manage containers]]
# Creation of nested containers, from [[#UC1: Manage containers]]
# Creation of resources (within a container), from [[#UC2: Manage resources]]
# Deletion of resources, from [[#UC2: Manage resources]]
# Moving contained resources, from [[#UC2: Manage resources]]
# Retrieve resource description, from [[#UC3: Retrieve resource description]]
# Retrieve description of a non-document resource, from [[#UC3: Retrieve resource description]]
# Enrichment (substituting update of existing resource), from [[#UC4: Update existing resource]]
# Selective update of a resource, from [[#UC4: Update existing resource]]
# Determine if a resource has changed, from [[#UC5: Determine if a resource has changed]]
# Add a resource to a collection, from [[#UC6: Aggregate resources]]
# Add a resource to multiple collections, from [[#UC6: Aggregate resources]]
# Retrieve collection-level description, from [[#UC7: Filter resource description]]
# Retrieve item-level description of a collection, from [[#UC7: Filter resource description]]
# Access media resources, from [[#UC8: Manage media resources]]
# Media-resource attachments, from [[#UC8: Manage media resources]]

===Non-Functional Requirements===

# Provide access guidance to resources, from [[#UC1: Manage containers]]
# Non-duplication of resources, from [[#UC2: Manage resources]]
# Distribution of resources, from [[#UC2: Manage resources]]
# Consistent, global naming, from [[#UC2: Manage resources]]
# Use standard vocabularies as appropriate, from [[#UC3: Retrieve resource description]]
# Scalable linking model, from [[#UC3: Retrieve resource description]]
# Unrestricted vocabulary, from [[#UC4: Update existing resource]]
# Resource descriptions are a "mix of simple data and collections", from [[#UC6: Aggregate resources]]
# Relative URIs enabling sharing of collections, from [[#UC6: Aggregate resources]]

== Acknowledgements ==
We would like to acknowledge the contributions of user-story authors; Christophe Guéret, Roger Menday, Eric Prud'hommeaux.

== References ==

Use Cases And Requirements

Sbattle2 — Mon, 10 Dec 2012 11:20:26 GMT

Sbattle2: /* Functional Requirements */

= Linked Data Platform Use Cases And Requirements =

This is a working document used to collect use cases and requirements for consideration by the WG.
The starting point comes from [http://www.w3.org/Submission/2012/SUBM-ldbpucr-20120326/ Linked Data Basic Profile Use Cases and Requirements].

== Steps to Complete ==

* <strike>Nov 26? WG to confirm User Story content: add, remove, refine (see process below). Note: this is ONLY User Stories (not Use Cases, Use Case Scenarios or Requirements)</strike>
** Issues before Nov 26th? will be included into FPWD
* Editors to:
** <strike>Dec 3 refine User Stories based on feedback</strike>
** <strike>Dec 5 elaborate on Use Cases in support of User Stories</strike>
* Dec 10 - WG to review prior to FPWD
** Review period ends Dec 15th
** insert open issues into draft for FPWD
* Dec 17 - Publish FPWD
** convert wiki page to ReSpec for FPWD
* Dec ?? Deadline for publications by year end 2012

===To Be Done===
* <strike>Move [[#LDP_and_Authentication.2FAuthorization| LDP and Authentication]] to [http://www.w3.org/2012/ldp/wiki/AccessControl AccessControl]</strike>
* <strike>Complete [[#Alternative_scenario:_moving_contained_resources| moving contained resources]] scenario with content from ericP on issue-30.</strike>
* Augment [[#Cloud_Infrastructure_Management| Cloud Infrastructure Management]] scenario with content from Roger Menday.
* <strike>Ensure issue-40/41 are fully covered in [[#UC8:_Managing_non-RDF_Resources| UC8: Managing non-RDF Resources]]. 2 scenarios (single v multiple attachments) ?</strike>
* <strike>Contact owner of [[#Data_Sharing| Data Sharing]] user-story to determine if we keep or not.</strike>
* Review [[#Requirements| Requirements]] section for functional/non-functional requirements arising in UCs.
* <strike>Propose resolutions to open issues against UC&R where possible.</strike>
* <strike>Identify and acknowledge user-story contributors.</strike>
* Check hyperlinks
* Convert to ReSpec
* Annotate document with open issues against UC&R
** [http://www.w3.org/2012/ldp/track/issues/30 ISSUE-30] (OPEN)
** [http://www.w3.org/2012/ldp/track/issues/40 ISSUE-40] (RAISED)
** [http://www.w3.org/2012/ldp/track/issues/41 ISSUE-41] (RAISED)

=== Process to introduce new User Stories & Use Cases ===

Open an Issue in the tracker against the UC&R product. The WG will review these and decide whether they are valid.

== Scope and Motivation ==

Linked Data was defined by Tim Berners-Lee with the following guidelines [http://www.w3.org/DesignIssues/LinkedData.html]:

# Use URIs as names for things
# Use HTTP URIs so that people can look up those names
# When someone looks up a URI, provide useful information, using the standards (RDF*, SPARQL)
# Include links to other URIs. so that they can discover more things

These four rules have proven very effective in guiding and inspiring people to publish Linked Data on the web. The amount of data, especially public data, available on the web has grown rapidly, and an impressive number of extremely creative and useful “mashups” have been created using this data as result.

There has been much less focus on the potential of Linked Data as a model for managing data on the web - the majority of the Application Programming Interfaces (APIs) available on the Internet for creating and updating data follow a Remote Procedure Call (RPC) model rather than a Linked Data model.

If Linked Data were just another model for doing something that RPC models can already do, it would be of only marginal interest. Interest in Linked Data arises from the fact that applications with an interface defined using Linked Data can be much more easily and seamlessly integrated with each other than applications that offer an RPC interface. In many problem domains, the most important problems and the greatest value are found not in the implementation of new applications, but in the successful integration of multiple applications into larger systems.

Some of the features that make Linked Data exceptionally well suited for integration include:

* A single interface – defined by a common set of HTTP methods – that is universally understood and is constant across all applications. This is in contrast with the RPC architecture where each application has a unique interface that has to be learned and coded to.
* A universal addressing scheme – provided by HTTP URLs – for both identifying and accessing all “entities”. This is in contrast with the RPC architecture where there is no uniform way to either identify or access data.
* A simple yet extensible data model – provided by RDF – for describing data about a resource in a way which doesn’t require prior knowledge of vocabulary being used.

Experience implementing applications and integrating them using Linked Data has shown very promising results, but has also demonstrated that the original four rules defined by Tim Berners-Lee for Linked Data are not sufficient to guide and constrain a writable Linked Data API. As was the case with the original four rules, the need generally is not for the invention of fundamental new technologies, but rather for a series of additional rules and patterns that guide and constrain the use of existing technologies in the construction of a Basic Profile for Linked Data to achieve interoperability.

The following list illustrates a few of the issues that require additional rules and patterns:
* What URLs do I post to in order to create new resources?
* How do I get lists of existing resources, and how do I get basic information about them without having to access each one?
* How should I detect and deal with race conditions on write?
* What media-types/representations should I use?
* What standard vocabularies should I use?
* What primitive data types should I use?

A good goal for the Basic Profile for Linked Data would be to define a specification required to allow the definition of a writable Linked Data API equivalent to the simple application APIs that are often written on the web today using the Atom Publishing Protocol (APP). APP shares some characteristics with Linked Data, such as the use of HTTP and URLs. One difference is that Linked Data relies on a flexible data model with RDF, which allows for multiple representations.

== Organization of this Document ==

This document is organized as follows:

* '''[[#User Stories| User Stories]]''' capture statements about system requirements written from a user or application perspective. They are typically lightweight and informal and can run from one line to a paragraph or two (sometimes described as an 'epic') [http://www.agilemodeling.com/artifacts/userStory.htm]. Analysis of each user story will reveal a number of (functional) use-cases and other non-functional requirements. See [http://www.w3.org/TR/dap-policy-reqs/| Device API Access Control Use Cases and Requirements] for a good example of user stories and their analysis.

* '''[[#Use Cases| Use Cases]]''' are used to capture and model functional requirements. Use cases describe the system’s behavior under various conditions [http://alistair.cockburn.us/get/2465], cataloguing who does what with the system, for what purpose, but without concern for system design or implementation [http://www.bredemeyer.com/pdf_files/functreq.pdf]. Each use case is identified by a reference number to aid cross-reference from other documentation; use-case indexing in this document is based on [http://www.w3.org/TR/rdb2rdf-ucr/ rdb2rdf use-cases]. A variety of styles may be used to capture use-cases, from a simple narrative to a structured description with actors, pre/post conditions, and step-by-step behaviours as in [http://www.w3.org/TR/powder-use-cases/ POWDER: Use Cases and Requirements], and non-functional requirements raised by the use-case. Use cases act like the hub of a wheel, with spokes supporting requirements analysis, scenario-based evaluation, testing, and integration with non-functional, or quality requirements.

* '''Scenarios''' are more focused still, representing a single instance of a use case in action. Scenarios may range from lightweight narratives as seen in [http://www.w3.org/TR/media-frags-reqs/ Use cases and requirements for Media Fragments], to being formally modeled as interaction diagrams. Each use-case should include at least a primary scenario, and possibly other alternative scenarios.

* '''[[#Requirements| Requirements]]''' list non-functional or quality requirements, and the use cases they may be derived from. This approach is exemplified in the [http://dvcs.w3.org/hg/gld/raw-file/default/dcat-ucr/index.html Use Cases and Requirements for the Data Catalog Vocabulary].

== User Stories ==

=== Maintaining Social Contact Information ===

Many of us have multiple email accounts that include information about the people and organizations we interact with – names, email addresses, telephone numbers, instant messenger identities and so on. When someone’s email address or telephone number changes (or they acquire a new one), our lives would be much simpler if we could update that information in one spot and all copies of it would automatically be updated. In other words, those copies would all be linked to some definition of “the contact.” There might also be good reasons (like off-line email addressing) to maintain a local copy of the contact, but ideally any copies would still be linked to some central “master.”

Agreeing on a format for “the contact” is not enough, however. Even if all our email providers agreed on the format of a contact, we would still need to use each provider’s custom interface to update or replace the provider’s copy, or we would have to agree on a way for each email provider to link to the “master”. If we look outside our own personal interests, it would be even more useful if the person or organization exposed their own contact information so we could link to it.

What would work in either case is a common understanding of the resource, a few formats needed, and access guidance for these resources. This would support how to acquire a link to a contact, and how to use those links to interact with a contact (including [[#UC3: Retrieve resource description|reading]], [[#UC4: Update existing resource|updating]], and [[#Alternative scenario: delete resource|deleting]] it), as well as how to easily [[#Primary scenario: create resource|create a new contact]] and add it to my contacts and when deleting a contact, how it would be removed from my list of contacts. It would also be good to be able to add some application-specific data about my contacts that the original design didn’t consider. Ideally we’d like to eliminate multiple copies of contacts, there would be additional valuable information about my contacts that may be stored on separate servers and need a simple way to link this information back to the contacts. Regardless of whether a contact collection is my own, shared by an organization, or all contacts known to an email provider (or to a single email account at an email provider), it would be nice if they all worked pretty much the same way.

=== Keeping Track of Personal and Business Relationships ===

In our daily lives, we deal with many different organizations in many different relationships, and they each have data about us. However, it is unlikely that any one organization has all the information about us. Each of them typically gives us access to the information (at least some of it), many through websites where we are uniquely identified by some string – an account number, user ID, and so on. We have to use their applications to interact with the data about us, however, and we have to use their identifier(s) for us. If we want to build any semblance of a holistic picture of ourselves (more accurately, collect all the data about us that they externalize), we as humans must use their custom applications to find the data, copy it, and organize it to suit our needs.

Would it not be simpler if at least the Web-addressable portion of that data could be linked to consistently, so that instead of maintaining various identifiers in different formats and instead of having to manually supply those identifiers to each one’s corresponding custom application, we could essentially build a set of bookmarks to it all? When we want to [[#UC3: Retrieve resource description|examine]] or [[#UC4: Update existing resource|change]] their contents, would it not be simpler if there were a single consistent application interface that they all supported? Of course it would.

Our set of links would probably be a [[#UC6: Aggregate resources|simple collection]]. The information held by any single organization might be a mix of simple data and [[#UC6: Aggregate resources|collections of other data]], for example, a bank account balance and a collection of historical transactions. Our bank might easily have [[#Alternative scenario: create a nested container|a collection of accounts for each of its collection of customers]].

=== System and Software Development Tool Integration ===

System and software development tools typically come from a diverse set of vendors and are built on various architectures and technologies. These tools are purpose built to meet the needs for a specific domain scenario (modeling, design, requirements and so on.) Often tool vendors view integrations with other tools as a necessary evil rather than providing additional value to their end-users. Even more of an afterthought is how these tools’ data -- such as people, projects, customer-reported problems and needs -- integrate and relate to corporate and external applications that manage data such as customers, business priorities and market trends. The problem can be isolated by standardizing on a small set of tools or a set of tools from a single vendor, but this rarely occurs and if does it usually does so only within small organizations. As these organizations grow both in size and complexity, they have needs to work with outsourced development and diverse internal other organizations with their own set of tools and processes. There is a need for better support of more complete business processes (system and software development processes) that span the roles, tasks, and data addressed by multiple tools. This demand has existed for many years, and the tools vendor industry has tried several different architectural approaches to address the problem. Here are a few:

* Implement an API for each application, and then, in each application, implement “glue code” that exploits the APIs of other applications to link them together.
* Design a single database to store the data of multiple applications, and implement each of the applications against this database. In the software development tools business, these databases are often called “repositories.”
* Implement a central “hub” or “bus” that orchestrates the broader business process by exploiting the APIs described previously.

It is fair to say that although each of those approaches has its adherents and can point to some successes, none of them is wholly satisfactory. The use of Linked Data as an application integration technology has a strong appeal. [http://open-services.net/ OSLC]

=== Library Linked Data ===

The W3C Library Linked Data working group has a number of use cases cited in their Use Case Report. [http://www.w3.org/2005/Incubator/lld/wiki/UseCaseReport LLD-UC] These referenced use cases focus on the need to extract and correlate library data from disparate sources. Variants of these use cases that can provide consistent formats, as well as ways to improve or update the data, would enable simplified methods for both efficiently sharing this data as well as producing incremental updates without the need for repeated full extractions and import of data.

The 'Digital Objects Cluster' contains a number of relevant use-cases:

* Grouping: This should "Allow the end-users to define [[#UC6: Aggregate resources|groups of resources]] on the web that for some reason belong together. The relationship that exists between the resources is often left unspecified. Some of the resources in a group may not be under control of the institution that defines the groups."

* Enrichment: "Enable end-users to [[#UC4: Update existing resource|link resources together]]."

* Browsing: "[[#UC7: Filter resource description|Support end-user browsing through groups]] and resources that belong to the groups."

* Re-use: "Users should have the capability to re-use all or parts of a collection, with all or part of its metadata, elsewhere on the linked Web."

The 'Collections' cluster also contains a number of relevant use-cases:

* Collection-level description: "Provide [[#UC7: Filter resource description|metadata pertaining to a collection as a whole]], in contrast to item-level description."

* Collections discovery: "Enable innovative collection discovery such as identification of nearest location of a physical collection where a specific information resource is found or mobile device applications ... based on collection-level descriptions."

* Community information services: Identify and classify collections of special interest to the community.

=== Municipality Operational Monitoring ===

Across various cities, towns, counties, and various municipalities there is a growing number of services managed and run by municipalities that produce and consume a vast amount of information. This information is used to help monitor services, predict problems, and handle logistics. In order to effectively and efficiently collect, produce, and analyze all this data, a fundamental set of loosely coupled standard data sources are needed. A simple, low-cost way to [[#UC3: Retrieve resource description|expose data]] from the diverse set of monitored services is needed, one that can easily integrate into the municipalities of other systems that inspect and analyze the data. All these services have links and dependencies on other data and services, so having a simple and scalable linking model is key.

=== Healthcare ===

For physicians to analyze, diagnose, and propose treatment for patients requires a vast amount of complex, changing and growing knowledge. This knowledge needs to come from a number of sources, including physicians’ own subject knowledge, consultation with their network of other healthcare professionals, public health sources, food and drug regulators, and other repositories of medical research and recommendations.

To diagnose a patient’s condition requires current data on the patient’s medications and medical history. In addition, recent pharmaceutical advisories about these medications are linked into the patient’s data. If the patient experiences adverse affects from medications, these physicians need to publish information about this to an appropriate regulatory source. Other medical professionals require access to both validated and emerging effects of the medication. Similarly, if there are geographical patterns around outbreaks that allow both the awareness of new symptoms and treatments, this information needs to quickly reach a very distributed and diverse set of medical information systems. Also, reporting back to these regulatory agencies regarding new occurrences of an outbreak, including additional details of symptoms and causes, is critical in producing the most effective treatment for future incidents.

=== Metadata Enrichment in Broadcasting ===

There are many different use cases when broadcasters show interest in metadata [[#UC4: Update existing resource| enrichment]]:

* enrich archive or news metadata by linking facts, events, locations and personalities
* enrich metadata generated by automatic extraction tools such as person identification, etc.
* enrich definitions of terms in classification schemes or enumeration lists

This comes in support of more effective information management and data/content mining (if you can't find your content, it' like if you don't have and must either recreate or acquire it again, which is not financially effective).

However, there is a need for solutions facilitating linkage to other data sources and taking care of the issues such as discovery, automation, disambiguation. Etc. Other important issues that broadcasters would face are the editorial quality of the linked data, its persistence, and usage rights.

=== Aggregation and Mashups of Infrastructure Data ===

For infrastructure management (such as storage systems, virtual machine environments, and similar IaaS and PaaS concepts), it is important to provide an environment in which information from different sources can be [[#UC6: Aggregate resources|aggregated]], [[#UC7: Filter resource description|filtered]], and visualized effectively. Specifically, the following use cases need to be taken into account:

* While some data sources are based on Linked Data, others are not, and aggregation and mashups must work across these different sources.
* Consumers of the data sources and aggregated/filtered data streams are not necessarily implementing Linked Data themselves, they may be off-the-shelf components such as dashboard frameworks for composing visualizations.
* Simple versions of this scenario are pull-based, where the data is requested from data sources. In more advanced settings, without a major change in architecture it should be possible to move to a push-based interaction model, where data sources push notifications to subscribers, and data sources provide different services that consumers can subscribe to (such as "informational messages" or "critical alerts only").

In this scenario, the important factors are to have abstractions that allow easy aggregation and filtering, are independent from the internal data model of the sources that are being combined, and can be used for pull-based interactions as well as for push-based interactions.

=== Sharing payload of RDF data among low-end devices ===

Several projects around the idea of [http://worldwidesemanticweb.wordpress.com/ downscaling the Semantic Web] need to be able to ship payloads of RDF across the nodes member of a given network. The transfers are done in a constrained context in terms of bandwidth, scope of the local semantics employed by the nodes and computing capabilities of the nodes. In a P2P style, every node has the capability to act either as a data consumer or a data provider, serving its own data or acting as a relay to pass other's data along (typically in mesh networks).

The transfer of an arbitrary payload of RDF data could be implemented through the container mechanism, adding and removing sets of RDF triples to it. Currently, one of the project "SemanticXO" uses named graphs and the graph protocol to create/delete/copy graphs across the nodes but this (almost) imposes the usage of a triple store. Unfortunately, triple store are rather demanding piece of software that are not always usable on limited hardware. Some generic ReST like interaction backed up with a lightweight column store would be better approach.

=== Sharing Binary Resources and Metadata ===

When publishing datasets about stars one may want to publish links to the pictures in which those stars appear, and this may well require publishing the pictures themselves. Vice versa: when publishing a picture of space we need to know which telescope took the picture, which part of the sky it was pointing at, what filters were used, which identified stars are visible, who can read it, who can write to it, ...

If LinkedData contains information about resources that are most naturally expressed in non-rdf formats (be they binary such as pictures or videos, or human readable documents in XML formats), those non RDF formats should be just as easy to publish to the LinkedData server as the RDF relations that link those resources up. A LinkedData server should therefore allow publishing of non linked data resources too, and make it easy to publish and edit metadata about those resources.

The resource comes in two parts - the image and information about the image (which may in the image file but better external to it as it's more general). The information about the image is vital. It's a compound item of image data and other data (being application metadata about the image does not distinguish from the platform's point-of-view.

=== Data Catalogs ===

The Asset Description Metadata Schema ([http://joinup.ec.europa.eu/asset/adms/home ADMS]) provides the data model to describe semantic assets repositories contents, but this leaves many open challenges when building a federation of these repositories to serve the need of assets reuse. These include accessing and querying individual repositories and efficiently retrieving [[#UC5: Determine if a resource has changed| updated content]] without having to retrieve the whole content. Hence, we chose to build the integration solution capitalizing on the Data Warehousing integration approach. This allows us to cope with heterogeneity of sources technologies and to benefit from the optimized performance it offers, given that individual repositories do not usually change frequently. With Data Warehousing, the federation requires to:

* understand the data, i.e. understand their semantic descriptions, and other systems.
* seamlessly exchange the semantic assets metadata from different repositories
* keep itself up-to-date.

Repositories owners can maintain de-referenceable URIs for their repository description and contained assets in a Linked Data compatible manner. ADMS provides the necessary data model to enable meaningful exchange of data. However, This leaves the challenge of efficient access to the data not fully addressed.

Related: [http://spec.datacatalogs.org/ Data Catalog Schema and Protocol]

=== Constrained Devices and Networks ===

Information coming from resource constrained devices in the Web of Things ([http://en.wikipedia.org/wiki/Web_of_Things WoT]) has been identified as a major driver in many domains, from smart cities to environmental monitoring to real-time tracking. The amount of information produced by these devices is growing exponentially and needs to be accessed and integrated in a systematic, standardized and cost efficient way. By using the same standards as on the Web, integration with applications will be simplified and higher-level interactions among resource constrained devices, abstracting away heterogeneities, will become possible. Up-coming IoT/WoT standards such as [http://datatracker.ietf.org/wg/6lowpan/ 6LowPAN] - IPv6 for resource constrained devices - and the Constrained Application Protocol ([http://tools.ietf.org/html/draft-ietf-core-coap CoAP]), which provides a downscaled version of HTTP on top of UDP for the use on constrained devices, are already at a mature stage. The next step now is to support RESTful interfaces also on resource constrained devices, adhering to the Linked Data principles. Due to the limited resources available, both on the device and in the network (such as bandwidth, energy, memory) a solution based on SPARQL Update is at the current point in time considered not to be useful and/or feasible. An approach based on the [http://tools.ietf.org/html/draft-castellani-core-http-mapping HTTP-CoAP Mapping] would enable constrained devices to directly participate in a Linked Data-based environment.

=== Services Supporting the Process of Science ===
Many fields of science now include branches with in silico data-intensive methods, e.g. bioinformatics, astronomy. To support these new methods we look to move beyond the established platforms provided by scientific workflow systems to capture, assist, and preserve the complete lifecycle from record of the experiment, through local trusted sharing, analysis, dissemination (including publishing of experimental data "beyond the PDF"), and re-use.

* [[#UC6: Aggregate resources|Aggregations]], specifically ''Research Objects (ROs)'' that are exchanged between services and clients bringing together workflows, data sets, annotations, and provenance. We use an RDF model for this. While some aggregated contents are encoded using RDF and in increasing number are linked data sources, others are not; while some are stored locally "within" the RO, others are remote (in both cases this is often due to size of the resources or access policies).
* Services that are distributed and linked. Some may be centralising for e.g. publication, others may be local, e.g. per lab. We need lightweight services that can be simply and easily integrated into and scale across the wide variety of softwares and data used in science: we have adopted a RESTful approach where possible.
** Foundation services that collect and expose ROs for storage, modification, exploration, and reuse.
** Services that provide added-value to ROs such as seamless import/export from scientific workflow systems, automated stability evaluation, or recommendation (and therefore interact with the foundation services to retrieve/store/modify/ROs).

seeAlso: [http://www.wf4ever-project.org/ Wf4Ever]

=== Project Membership Information : Information Evolution ===

Information about people and projects changes as roles change, as organisations change
and as contact details change. Finding the current state of a project is important
in enabling people to contact the right person in the right role. It can also be
useful to look back and see who was performing what role in the past.

A use of a Linked Data Platform could be to give responsibility for managing
such information with the project team itself, not requiring updates to be
requested of a centralised website administrator.

This could be achieved with:

* Resource descriptions for each person and project
* A container resource to describe roles/membership in the project.

To retain the history of the project, the old version of a resources,
including container resources, should be retained so there is a need to address both specific items
and also have a notion of "current".

Access to information has two aspects:
* Access to the "current" state, regardless of the version of the resource description
* Access to historical state, via access to a specific version of the resource description

=== Cloud Infrastructure Management===

Cloud operators offer API support to provide customers with remote access for infrastructure management. Infrastructure consists of Systems, Computers, Networks, Discs, etc, and the overall structure can be seen as mostly hierarchical, (Cloud contains Systems, Systems contain Machines, etc). This is complemented with crossing links (e.g. Machines connected to a Network). The IaaS scenario also makes requirements for lifecycle management, non-instant changes and history capture. Infrastructure management can be seen as the manipulation of the underlying graph.

== Use Cases ==
The following use-cases are each derived from one or more of the user-stories above. These use-cases are explored in detail through the development of scenarios, each motivated by some key aspect exemplified by a single user-story. The examples they contain are included purely for illustrative purposes, and should not be interpreted normatively.

===UC1: Manage containers===
A number of user-stories introduce the idea of a ''container'' as a mechanism for creating and managing resources within the context of an application. Resources grouped together within the same container would typically belong to the same application. A container is identified by a URI so is a resource in its own right.
The properties of a container may also represent the ''affordances'' of that container, enabling clients to determine what other operations they can do on that container. These operations may include descriptions of application specific services that can be invoked by exchanging RDF documents.

* Provide "access guidance for ... resources" (affordances) (from user-story, [[#Maintaining Social Contact Information|Maintaining Social Contact Information]]).

====Primary scenario: create container====
Create a new container resource within the LDP server.
In [[#Services Supporting the Process of Science|Services supporting the process of science]], [http://wf4ever.github.com/ro-primer/ Research Objects] are semantically rich aggregations of resources that bring together data, methods and people in scientific investigations. A basic workflow research object will be created to aggegate [http://ceur-ws.org/Vol-903/paper-01.pdf scientific workflows] and the artefacts that result from this workflow. The research object begins life as an empty container into which workflows, datasets, results and other data will be added throughout the lifecycle of the project.

<nowiki>
@prefix ro: http://purl.org/wf4ever/ro#
@prefix dct: http://purl.org/dc/terms/
@prefix ore: http://www.openarchives.org/ore/

<> a ro:ResearchObject, ore:Aggregation ;
dct:created "2012-12-01"^^xsd:dateTime .
</nowiki>

====Alternative scenario: create a nested container====
The motivation for nested containers comes from the [[#System and Software Development Tool Integration| System and Software Development Tool Integration]] user-story. The OSLC Change Management vocabulary allows bug reports to have attachments referenced by the membership predicate <nowiki>oslc_cm:attachment</nowiki>. The 'top-level-container' contains issues, and each issue resource has its own container of attachment resources.

<nowiki>
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix oslc_cm: <http://open-services.net/ns/cm#>.
@prefix : <http://example.org/>.

:top-level-container rdfs:member :issue1234 .

:issue1234 a oslc_cm:ChangeRequest;
dcterms:identifier "1234";
dcterms:type "a bug";
dcterms:related :issue1235 ;
oslc_cm:attachments :attachments123.

:issue1235 a oslc_cm:ChangeRequest;
dcterms:title "a related bug".

:attachments a oslc_cm:AttachmentList;
oslc_cm:attachment :attachment324, :attachment251.
</nowiki>

===UC2: Manage resources===
This use-case addresses the managed lifecycle of a resource and is concerned with resource ''ownership''. The responsibility for managing resources belongs with their container.
For example, a container may accept a request from a client to make a new resource.
This use-case focuses on creation and deletion of resources in the context of a container, and the potential for transfer of ownership by moving resources between containers.
The ownership of a resource should always be clear; no resource managed in this way should ever be owned by more than one container.

Once a new resource has been created it should be identified by a URI. Clients may defer responsibility for establishing dereferenceable URIs to the container of their data.
The container is a natural choice for the endpoint for this interface as it will already have some application-specific knowledge about the contained resources.
While the LDP has ultimate control over resource naming, some applications may require more control over naming, perhaps to provide a more human-readable URI. An LDP server could support something like the [http://tools.ietf.org/html/rfc5023 Atom Publishing Protocol] slug header to convey a user defined naming 'hint'.

* Non-duplication of resources: "Eliminate multiple copies", representing resources in a single place (from [[#Maintaining Social Contact Information]]).
* Distribution of resources: Linked aata "may be stored on separate servers" (from [[#Maintaining Social Contact Information]]).
* Consistent, global naming: Resources should be "linked to consistently, ... instead of maintaining various identifiers in different formats" (from [[#Keeping Track of Personal and Business Relationships]]).

====Primary scenario: create resource====
Resources begin life by being created within a container. From user-story, [[#Maintaining Social Contact Information|Maintaining Social Contact Information]], It should be possible to "easily create a new contact and add it to my contacts." This suggests that resource creation is closely linked to the application context. The new resource is created in a container representing "my contacts." The lifecycle of the resource is linked to the lifecycle of it's container. So, for example, if "my contacts" is deleted then a user would also reasonably expect that all contacts within it would also be deleted.

Contact details are captured as an RDF description and it's properties, including "names, email addresses, telephone numbers, instant messenger identities and so on." The description may include non-standard RDF; "data about my contacts that the original design didn’t consider."
The following RDF could be used to describe contact information using the [http://www.foaf-project.org FOAF] vocabulary. A contact is represented here by a <nowiki>foaf:PersonalProfileDocument</nowiki> defining a resource that can be created and updated as a single-unit, even though it may describe ancillary resources, such as a <nowiki>foaf:Person</nowiki>, below.

<nowiki>
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

<> a foaf:PersonalProfileDocument;
foaf:PrimaryTopic [
a foaf:Person;
foaf:name "Timothy Berners-Lee";
foaf:title "Sir";
foaf:firstName "Timothy";
foaf:surname "Berners-Lee";
foaf:nick "TimBL", "timbl";
foaf:homepage <http://www.w3.org/People/Berners-Lee/>;
foaf:weblog <http://dig.csail.mit.edu/breadcrumbs/blog/4>;
foaf:mbox <mailto:timbl@w3.org>;
foaf:workplaceHomepage <http://www.w3.org/>.
]
</nowiki>

====Alternative scenario: delete resource====
Delete a resource and all it's properties. If the resource resides within a container it will be removed from that container, however other links to the deleted resource may be left as dangling references.
In the case where the resource is a container, the server may also delete any or all contained resources.
In normal practice, a deleted resource cannot be reinstated. There are however, edge-cases where limited undelete may be desirable.
Best practice states that "[http://www.w3.org/TR/cooluris/| Cool URIs don't change]", which implies that deleted URIs shouldn't be recycled.

====Alternative scenario: moving contained resources====
Many resources may have value beyond the life of their membership in a container. This implies methods to add references to revise container membership.
Cloning container members for use in other containers results in duplication of information and maintenance problems; web practice is to encourage the creation of one resource, which may be referenced as many places as necessary. A change of ownership may - or may not - imply a change of URI, depending upon the specific LDP naming policy. While assigning a new URI to a resource is discouraged [http://www.w3.org/DesignIssues/Architecture.html#HTTP], it is possible to indicate that a resource has moved with an appropriate HTTP response.

===UC3: Retrieve resource description===
Access the current description of a resource, containing properties of that resource and links to related resources. The representation may include descriptions of related resources that cannot be accessed directly.
Depending upon the application, an LDP may enrich the retrieved RDF with additional triples. Examples include adding incoming links, sameAs closure and type closure.
The HTTP response should also include versioning information (i.e. last update or entity tag) so that subsequent updates can ensure they are being applied to the correct version.

* Use standard vocabularies as appropriate to enable a "common understanding of the resource" (from [[#Maintaining Social Contact Information|Maintaining Social Contact Information]]).
* A "scalable linking model is key" (from [[#Municipality Operational Monitoring]]).

====Primary scenario====
The user-story [[#Project Membership Information : Information Evolution| Project Membership Information]] discusses the representation of information about people and projects. It calls for "Resource descriptions for each person and project" allowing project teams to review information held about these resources. The example below illustrates the kinds of information that might be held about organizational structures based on the [http://www.epimorphics.com Epimorphics] [http://www.epimorphics.com/public/vocabulary/org.html organizational ontology].

Note that the example below defines two resources (shown as separate sections below) that will be hosted on an LDP based at <nowiki>http://example.com/</nowiki>. The representations of these resources may include descriptions of related resources, such as <nowiki>http://www.w3.org/</nowiki>, that that fall under a different authority and therefore can't be served from the LDP at this location.

<nowiki>
@prefix org: <http://www.w3.org/ns/org#> .
@prefix owltime: <http://www.w3.org/2006/time> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@base <http://example.com/> .

<member1> a org:Membership ;
org:member <http://www.w3.org/People/Berners-Lee/card#i> ;
org:organization http://www.w3.org/> ;
org:role <director> ;
org:memberDuring [a owltime:Interval; owltime:hasBeginning [
owltime:inXSDDateTime "1994-10-01T00:00:00Z"^^xsd:dateTime]] .

<http://www.w3.org/> a org:FormalOrganization ;
skos:prefLabel "The World Wide Web Consortium"@en ;
skos:altLabel "W3C" .
</nowiki>

<nowiki>
@prefix org: <http://www.w3.org/ns/org#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@base <http://example.com/> .

<director> a org:Role ;
rdfs:label "Director" .
</nowiki>

====Alternative scenario: retrieve description of a non-document resource====
In many cases, the things that are of interest are not always the things that are resolvable. The example below demonstrates how a foaf profile may be used to distinguish between the person and the profile; the former being the topic of the latter. This begs the question as to what a client should do with such non-document resources. In this case the HTTP protocol requires that the fragment part be stripped off before requesting the URI from the server. The result is a resolvable URI for the profile.

<nowiki>
@base <http://www.w3.org/People/Berners-Lee/card>
@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@prefix dc: <http://purl.org/dc/elements/1.1/>.

<> a foaf:PersonalProfileDocument ;
dc:title "Tim Berners-Lee's FOAF file" ;
foaf:homepage <http://www.w3.org/People/Berners-Lee/> ;
foaf:primaryTopic <#i> .
</nowiki>

===UC4: Update existing resource===
Change the RDF description of a LDP resource, potentially removing or overwriting existing data. This allows applications to ''enrich'' the representation of a resource by addling additional links to other resources.

* Unrestricted vocabulary: It should be possible be "able to add ... application-specific data" to resources (from [[#Maintaining Social Contact Information]]).

====Primary scenario: enrichment====
This relates to user-story [[#Metadata Enrichment in Broadcasting| Metadata Enrichment in Broadcasting]] and is based on the [http://www.bbc.co.uk/ontologies/sport/ BBC Sports Ontology]. The ''resource-centric'' view of linked-data provides a natural granularity for substituting, or overwriting a resource and its data. The simplest kind of update would simply replace what is currently known about a resource with a new representation. There are two distinct resources in the example below; a sporting event and an associated award. The granularity of the LDP would allow a user to replace the information about the award without disturbing the information about the event.

<nowiki>
@prefix sport: <http://www.bbc.co.uk/ontologies/sport/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

:mens_sprint a sport:MultiStageCompetition;
rdfs:label "Men's Sprint";
sport:award <#gold_medal> .

<#gold_medal> a sport:Award .
</nowiki>

We can enrich the description as events unfold, linking to the winner of the gold medal by substituting the above description with the following.

<nowiki>
@prefix sport: <http://www.bbc.co.uk/ontologies/sport/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

:mens_sprint a sport:MultiStageCompetition;
rdfs:label "Men's Sprint";
sport:award <#gold_medal> .
<#gold_medal> a sport:Award;
sport:awarded_to [
a foaf:Agent ;
foaf:name "Chris Hoy" .
] .
</nowiki>

====Alternative scenario: selective update of a resource====
This relates to user-story [[#Data Catalogs|Data Catalogs]], based on the [http://vocab.deri.ie/dcat Data Catalog Vocabulary].
A catalogue is described by the following RDF model.

<nowiki>
@prefix dcat: <http://www.w3.org/ns/dcat#> .
@prefix dcterms: <http://purl.org/dc/terms/> .

:catalog a dcat:Catalog ;
dcat:dataset :dataset/001;
dcterms:issued "2012-12-11"^^xsd:date.
</nowiki>

A catalog may contain multiple datasets, so when linking to new datasets it would be simpler and preferable to selectively add just the new dataset links.
A Talis ''changeset'' [http://docs.api.talis.com/getting-started/changesets][http://www.w3.org/2009/12/rdf-ws/papers/ws07] could be used to add a new <nowiki>dc:title</nowiki> to the dataset. The following update would be directed to the catalogue to add an additional dataset.

<nowiki>
@prefix : <http://example.com/>.
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix cs: <http://purl.org/vocab/changeset/schema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.

<change1>
a cs:ChangeSet ;
cs:subjectOfChange :catalog ;
cs:createdDate "2012-01-01T00:00:00Z" ;
cs:changeReason "Update catalog datasets" ;
cs:addition [
a rdf:Statement ;
rdf:subject :catalog ;
rdf:predicate dcat:dataset ;
rdf:object :dataset/002 .
] .
</nowiki>

===UC5: Determine if a resource has changed===
It should be possible to retrieve versioning information about a resource (e.g. last modified or entity tag) without having to download a representation of the resource.
This information can then be compared with previous information held about that resource to determine if it has changed.
This versioning information can also be used in subsequent ''conditional'' requests to ensure they are only applied if the version is unchanged.

====Primary scenario====
Based on the user-story, [[#Constrained Devices and Networks| Constrained Devices and Networks]], an LDP could be configured to act as a proxy for a [http://tools.ietf.org/html/draft-ietf-core-coap CoAP] based [http://en.wikipedia.org/wiki/Web_of_Things Web of Things]. As an observer of CoAP resources, the LDP registers its interest so that it will be notified whenever the sensor reading changes. Clients of the LDP can interrogate the LDP to determine if the state has changed.

In this example, the information about a sensor and corresponding sensor readings can be represented as RDF resources. The first resource below, represents a sensor described using the [http://www.w3.org/2005/Incubator/ssn/ Semantic Sensor Network] ontology.
<nowiki>
@prefix : <http://example.com/energy-management/>.

<> a :MainsFrequencySensor;
rdfs:comment "Sense grid load based on mains frequency";
ssn:hasMeasurementCapability [
a :FrequencyMeasurementCapability;
ssn:hasMeasurementProperty <#property_1> .
] .
</nowiki>

The value of the sensor changes in real-time as measurements are taken. The LDP client can interrogate the resource below to determine if it has changed, ''without'' necessarily having to download the RDF representation. As different sensor properties are represented disjointly (separate RDF representations) they may change independently.

<nowiki>
@prefix : <http://example.com/energy-management/>.

<http://example.com/energy-management#property_1> :hasMeasurementPropertyValue <> .
<> a :FrequencyValue;
:hasQuantityValue "50"^^xsd:float.
</nowiki>

===UC6: Aggregate resources===
There is a requirement to be able to manage ''collections'' of resources. The concept of a collection overlaps with, but is distinct from that of a container. These collections are (weak) aggregations, unrelated to the lifecycle management of resources, and distinct from the ownership between a resource and its container. However, the composition of a container may be reflected as a collection to support navigation of the container and its contents. There is a need to be able to create collections by adding and deleting individual membership properties. Resources may belong to multiple collections, or to none.

* Resource descriptions are a "mix of simple data and collections" (from [[#Keeping Track of Personal and Business Relationships]]).
* Relative URIs: It should be possible to "ship payloads of RDF" for a collection as a whole without breaking internal links (from [[#Constrained Devices and Networks]]).

====Primary scenario: add a resource to a collection====
This example is from [[#Library Linked Data|Library Linked Data]] and [http://www.w3.org/2005/Incubator/lld/wiki/UseCaseReport LLD-UC], specifically [http://www.w3.org/2005/Incubator/lld/wiki/Use_Case_Subject_Search Subject Search].

There is an existing collection at <nowiki><http://example.com/concept-scheme/subject-heading></nowiki> that defines a collection of subject headings. This collection is defined as a skos:ConceptScheme and
the client wishes to insert a new concept into the scheme. which will be related to the collection via a <nowiki>skos:inScheme</nowiki> link. The new subject-heading, "outer space exploration", is not necessarily owned by a container. The following RDF would be added to the (item-level) description of the collection.

<nowiki>
@prefix scheme : <http://example.com/concept-scheme/>.
@prefix concept : <http://example.com/concept/>.

scheme:subject-heading a skos:ConceptScheme.

concept:Outer+space+Exploration skos:inScheme scheme:subject-heading.
</nowiki>

====Alternative scenario: add a resource to multiple collections====
Logically, a resource should not be owned by more than one container. however, it may be a member of multiple collections which define a weaker form of ''aggregation''. As this is simply a manipulation of the RDF description of a collection, it should be possible to add the same resource to multiple collections.

As a machine-readable collection of medical terms, the [http://www.ihtsdo.org| SNOMED] ontology is of key importance in [[#Healthcare | healthcare]]. SNOMED CT allows concepts with more than one parent that don't fall into a lattice.
In the example below, the same concept may fall under two different parent concepts.
The example uses skos:narrowerTransitive to elide intervening concepts.

<nowiki>
@prefix : <http://example.com/snomed/>.

:_119376003 a skos:Concept ;
skos:prefLabel "Tissue specimen"
skos:narrowerTransitive :TissueSpecimenFromHeart.

:_127462005 a skos:Concept ;
skos:prefLabel "Specimen from heart"
skos:narrowerTransitive :TissueSpecimenFromHeart.

:_128166000 a skos:Concept;
rdfs:label "Tissue specimen from heart".
</nowiki>

===UC7: Filter resource description===
This use-case extends the normal behaviour of retrieving an RDF description of a resource, by dynamically excluding specific (membership) properties.
For containers, it is often desirable to be able to read a collection, or item-level description that excludes the container membership.

====Primary scenario: retrieve collection-level description====
This scenario, based on [[#Library Linked Data| Library Linked Data]], uses the Dublin Core Metadata Initiative [http://dublincore.org/groups/collections/collection-application-profile/| Collection-Level] description.
A collection can refer to any aggregation of physical or digital items.
This scenario covers the case whereby a client can request a collection-level description as typified by the example below, without necessarily having to download a full listing of the items within the collection.

<nowiki>
@prefix rdf: <rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">.
@prefix dc: <http://purl.org/dc/elements/1.1/>.
@prefix : <http://example.org/bookshelf/>.
@prefix dcmitype: <http://purl.org/dc/dcmitype/>.
@prefix cld: <http://purl.org/cld/terms/>.
@prefix dcterms: <http://purl.org/dc/terms/>.

<> dc:type dcmitype:Collection ;
dc:title "Directory of organizations working with Linked Data" ;
dcterms:abstract "This is a directory of organisations specializing in Linked Data."
cld:isLocatedAt <http://dir.w3.org>
cld:isAccessedVia <http://dir.w3.org/rdf/2012/directory/directory-list.xhtml?construct>
</nowiki>

====Alternative scenario: retrieve item-level description of a collection====
This use-case scenario, also based on [[#Library Linked Data| Library Linked Data]], focuses on obtaining an item-level description of the resources aggregated by a collection.
The simplest scenario is where the members of a collection are returned within a single representation, so that a client can explore the data by following these links. Different applications may use different membership predicates to capture this aggregation. The example below uses <nowiki>rdfs:member</nowiki>, but many different membership predicates are in common use, including RDF Lists.
Item-level descriptions can be captured using the Functional Requirements for Bibliographic Records ([http://www.ifla.org/publications/functional-requirements-for-bibliographic-records FRBR]) [http://vocab.org/frbr/core.html ontology].

<nowiki>
@prefix frbr: <http://purl.org/vocab/frbr/core#>.

<> rdfs:member <#ebooks97>, <#ebooks21279>.

<#work97> a frbr:LiteraryWork;
dc:title "Flatland: a romance of many dimensions" ;
frbr:creator <#Abbott_Edwin>;
frbr:manifestation <ebook97>.

<#work21279> a frbr:LiteraryWork;
dc:title "2 B R 0 2 B" ;
frbr:creator <#Vonnegut_Kurt>;
frbr:manifestation <ebook21279>.
</nowiki>

Collections are potentially very large, so some means may be required to limit the size of RDF representation returned by the LDP (e.g. pagination).

===UC8: Manage media resources===
It should be possible to easily add non-RDF media resources to containers that accept them. Media resources may be updated and removed during the lifecycle of the container.

====Primary scenario: access media resources====
From the User Story [[#Sharing Binary Resources and Metadata| Sharing Binary Resources and Metadata]] it should be possible to easily add non RDF resources to a containers that accept them. Clients submit a non-RDF representation to a container in a media type accepted by that container. The container creates a URI to represent this media resource, and creates a link from the container to the new URI.The media resource may have an explicit representation of the media type. It should be possible to find the metadata about such a resource and to access and edit it in the usual ways.

This example uses the [http://www.w3.org/TR/mediaont-10/#ont-ttl Ontology for Media Resources] to describe a media resource added to a collection.
<nowiki>
@prefix ma: <http://www.w3.org/ns/ma-ont#> .

<dataset> a ma:Collection ;
:hasMember <dataset/image1.jpg>

<dataset/image1.jpg> a ma:MediaResource ;
ma:hasFormat "image/jpeg" .
</nowiki>

====Alternative scenario: media-resource attachments====
A resource may have multiple ''renditions''; the idea that you can have a PDF and a JPEG representing the same thing. A user is trying to create a work order along with an attached image showing a faulty machine part. To the user and to the work order system, these two artifacts are managed as a set. A single request may create the work order, the attachment, and the relationship between them, atomically.
When the user retrieves the work order later, they expect a single request by default to retrieve the work order plus all attachments.
When the user updates the work order, e.g. to mark it completed, they only want to update the work order proper, not its attachments.
Users may add/remove/replace attachments to the work order during its lifetime.

== Requirements ==

'''TODO: Refine these based on use case and scenario updates'''

===Functional Requirements===
# Create Containers, from [[#UC1: Manage containers]]
# Creation of nested containers, from [[#UC1: Manage containers]]
# Creation of resources (within a container), from [[#UC2: Manage resources]]
# Deletion of resources, from [[#UC2: Manage resources]]
# Moving contained resources, from [[#UC2: Manage resources]]
# Retrieve resource description, from [[#UC3: Retrieve resource description]]
# Retrieve description of a non-document resource, from [[#UC3: Retrieve resource description]]
# Enrichment (substituting update of existing resource), from [[#UC4: Update existing resource]]
# Selective update of a resource, from [[#UC4: Update existing resource]]
# Determine if a resource has changed, from [[#UC5: Determine if a resource has changed]]
# Add a resource to a collection, from [[#UC6: Aggregate resources]]
# Add a resource to multiple collections, from [[#UC6: Aggregate resources]]
# Retrieve collection-level description, from [[#UC7: Filter resource description]]
# Retrieve item-level description of a collection, from [[#UC7: Filter resource description]]
# Access media resources, from [[#UC8: Manage media resources]]
# Media-resource attachments, from [[#UC8: Manage media resources]]

===Non-Functional Requirements===

# Provide access guidance to resources, from [[#UC1: Manage containers]]
# Non-duplication of resources, from [[#UC2: Manage resources]]
# Distribution of resources, from [[#UC2: Manage resources]]
# Consistent, global naming, from [[#UC2: Manage resources]]
# Use standard vocabularies as appropriate, from [[#UC3: Retrieve resource description]]
# Scalable linking model, from [[#UC3: Retrieve resource description]]
# Unrestricted vocabulary, from [[#UC4: Update existing resource]]
# Resource descriptions are a "mix of simple data and collections", from [[#UC6: Aggregate resources]]
# Relative URIs enabling sharing of collections, from [[#UC6: Aggregate resources]]

== Acknowledgements ==
We would like to acknowledge the contributions of user-story authors; Christophe Guéret, Roger Menday, Eric Prud'hommeaux.

== References ==

Use Cases And Requirements

Sbattle2 — Mon, 10 Dec 2012 11:19:38 GMT

Sbattle2: /* UC8: Manage media resources */

= Linked Data Platform Use Cases And Requirements =

This is a working document used to collect use cases and requirements for consideration by the WG.
The starting point comes from [http://www.w3.org/Submission/2012/SUBM-ldbpucr-20120326/ Linked Data Basic Profile Use Cases and Requirements].

== Steps to Complete ==

* <strike>Nov 26? WG to confirm User Story content: add, remove, refine (see process below). Note: this is ONLY User Stories (not Use Cases, Use Case Scenarios or Requirements)</strike>
** Issues before Nov 26th? will be included into FPWD
* Editors to:
** <strike>Dec 3 refine User Stories based on feedback</strike>
** <strike>Dec 5 elaborate on Use Cases in support of User Stories</strike>
* Dec 10 - WG to review prior to FPWD
** Review period ends Dec 15th
** insert open issues into draft for FPWD
* Dec 17 - Publish FPWD
** convert wiki page to ReSpec for FPWD
* Dec ?? Deadline for publications by year end 2012

===To Be Done===
* <strike>Move [[#LDP_and_Authentication.2FAuthorization| LDP and Authentication]] to [http://www.w3.org/2012/ldp/wiki/AccessControl AccessControl]</strike>
* <strike>Complete [[#Alternative_scenario:_moving_contained_resources| moving contained resources]] scenario with content from ericP on issue-30.</strike>
* Augment [[#Cloud_Infrastructure_Management| Cloud Infrastructure Management]] scenario with content from Roger Menday.
* <strike>Ensure issue-40/41 are fully covered in [[#UC8:_Managing_non-RDF_Resources| UC8: Managing non-RDF Resources]]. 2 scenarios (single v multiple attachments) ?</strike>
* <strike>Contact owner of [[#Data_Sharing| Data Sharing]] user-story to determine if we keep or not.</strike>
* Review [[#Requirements| Requirements]] section for functional/non-functional requirements arising in UCs.
* <strike>Propose resolutions to open issues against UC&R where possible.</strike>
* <strike>Identify and acknowledge user-story contributors.</strike>
* Check hyperlinks
* Convert to ReSpec
* Annotate document with open issues against UC&R
** [http://www.w3.org/2012/ldp/track/issues/30 ISSUE-30] (OPEN)
** [http://www.w3.org/2012/ldp/track/issues/40 ISSUE-40] (RAISED)
** [http://www.w3.org/2012/ldp/track/issues/41 ISSUE-41] (RAISED)

=== Process to introduce new User Stories & Use Cases ===

Open an Issue in the tracker against the UC&R product. The WG will review these and decide whether they are valid.

== Scope and Motivation ==

Linked Data was defined by Tim Berners-Lee with the following guidelines [http://www.w3.org/DesignIssues/LinkedData.html]:

# Use URIs as names for things
# Use HTTP URIs so that people can look up those names
# When someone looks up a URI, provide useful information, using the standards (RDF*, SPARQL)
# Include links to other URIs. so that they can discover more things

These four rules have proven very effective in guiding and inspiring people to publish Linked Data on the web. The amount of data, especially public data, available on the web has grown rapidly, and an impressive number of extremely creative and useful “mashups” have been created using this data as result.

There has been much less focus on the potential of Linked Data as a model for managing data on the web - the majority of the Application Programming Interfaces (APIs) available on the Internet for creating and updating data follow a Remote Procedure Call (RPC) model rather than a Linked Data model.

If Linked Data were just another model for doing something that RPC models can already do, it would be of only marginal interest. Interest in Linked Data arises from the fact that applications with an interface defined using Linked Data can be much more easily and seamlessly integrated with each other than applications that offer an RPC interface. In many problem domains, the most important problems and the greatest value are found not in the implementation of new applications, but in the successful integration of multiple applications into larger systems.

Some of the features that make Linked Data exceptionally well suited for integration include:

* A single interface – defined by a common set of HTTP methods – that is universally understood and is constant across all applications. This is in contrast with the RPC architecture where each application has a unique interface that has to be learned and coded to.
* A universal addressing scheme – provided by HTTP URLs – for both identifying and accessing all “entities”. This is in contrast with the RPC architecture where there is no uniform way to either identify or access data.
* A simple yet extensible data model – provided by RDF – for describing data about a resource in a way which doesn’t require prior knowledge of vocabulary being used.

Experience implementing applications and integrating them using Linked Data has shown very promising results, but has also demonstrated that the original four rules defined by Tim Berners-Lee for Linked Data are not sufficient to guide and constrain a writable Linked Data API. As was the case with the original four rules, the need generally is not for the invention of fundamental new technologies, but rather for a series of additional rules and patterns that guide and constrain the use of existing technologies in the construction of a Basic Profile for Linked Data to achieve interoperability.

The following list illustrates a few of the issues that require additional rules and patterns:
* What URLs do I post to in order to create new resources?
* How do I get lists of existing resources, and how do I get basic information about them without having to access each one?
* How should I detect and deal with race conditions on write?
* What media-types/representations should I use?
* What standard vocabularies should I use?
* What primitive data types should I use?

A good goal for the Basic Profile for Linked Data would be to define a specification required to allow the definition of a writable Linked Data API equivalent to the simple application APIs that are often written on the web today using the Atom Publishing Protocol (APP). APP shares some characteristics with Linked Data, such as the use of HTTP and URLs. One difference is that Linked Data relies on a flexible data model with RDF, which allows for multiple representations.

== Organization of this Document ==

This document is organized as follows:

* '''[[#User Stories| User Stories]]''' capture statements about system requirements written from a user or application perspective. They are typically lightweight and informal and can run from one line to a paragraph or two (sometimes described as an 'epic') [http://www.agilemodeling.com/artifacts/userStory.htm]. Analysis of each user story will reveal a number of (functional) use-cases and other non-functional requirements. See [http://www.w3.org/TR/dap-policy-reqs/| Device API Access Control Use Cases and Requirements] for a good example of user stories and their analysis.

* '''[[#Use Cases| Use Cases]]''' are used to capture and model functional requirements. Use cases describe the system’s behavior under various conditions [http://alistair.cockburn.us/get/2465], cataloguing who does what with the system, for what purpose, but without concern for system design or implementation [http://www.bredemeyer.com/pdf_files/functreq.pdf]. Each use case is identified by a reference number to aid cross-reference from other documentation; use-case indexing in this document is based on [http://www.w3.org/TR/rdb2rdf-ucr/ rdb2rdf use-cases]. A variety of styles may be used to capture use-cases, from a simple narrative to a structured description with actors, pre/post conditions, and step-by-step behaviours as in [http://www.w3.org/TR/powder-use-cases/ POWDER: Use Cases and Requirements], and non-functional requirements raised by the use-case. Use cases act like the hub of a wheel, with spokes supporting requirements analysis, scenario-based evaluation, testing, and integration with non-functional, or quality requirements.

* '''Scenarios''' are more focused still, representing a single instance of a use case in action. Scenarios may range from lightweight narratives as seen in [http://www.w3.org/TR/media-frags-reqs/ Use cases and requirements for Media Fragments], to being formally modeled as interaction diagrams. Each use-case should include at least a primary scenario, and possibly other alternative scenarios.

* '''[[#Requirements| Requirements]]''' list non-functional or quality requirements, and the use cases they may be derived from. This approach is exemplified in the [http://dvcs.w3.org/hg/gld/raw-file/default/dcat-ucr/index.html Use Cases and Requirements for the Data Catalog Vocabulary].

== User Stories ==

=== Maintaining Social Contact Information ===

Many of us have multiple email accounts that include information about the people and organizations we interact with – names, email addresses, telephone numbers, instant messenger identities and so on. When someone’s email address or telephone number changes (or they acquire a new one), our lives would be much simpler if we could update that information in one spot and all copies of it would automatically be updated. In other words, those copies would all be linked to some definition of “the contact.” There might also be good reasons (like off-line email addressing) to maintain a local copy of the contact, but ideally any copies would still be linked to some central “master.”

Agreeing on a format for “the contact” is not enough, however. Even if all our email providers agreed on the format of a contact, we would still need to use each provider’s custom interface to update or replace the provider’s copy, or we would have to agree on a way for each email provider to link to the “master”. If we look outside our own personal interests, it would be even more useful if the person or organization exposed their own contact information so we could link to it.

What would work in either case is a common understanding of the resource, a few formats needed, and access guidance for these resources. This would support how to acquire a link to a contact, and how to use those links to interact with a contact (including [[#UC3: Retrieve resource description|reading]], [[#UC4: Update existing resource|updating]], and [[#Alternative scenario: delete resource|deleting]] it), as well as how to easily [[#Primary scenario: create resource|create a new contact]] and add it to my contacts and when deleting a contact, how it would be removed from my list of contacts. It would also be good to be able to add some application-specific data about my contacts that the original design didn’t consider. Ideally we’d like to eliminate multiple copies of contacts, there would be additional valuable information about my contacts that may be stored on separate servers and need a simple way to link this information back to the contacts. Regardless of whether a contact collection is my own, shared by an organization, or all contacts known to an email provider (or to a single email account at an email provider), it would be nice if they all worked pretty much the same way.

=== Keeping Track of Personal and Business Relationships ===

In our daily lives, we deal with many different organizations in many different relationships, and they each have data about us. However, it is unlikely that any one organization has all the information about us. Each of them typically gives us access to the information (at least some of it), many through websites where we are uniquely identified by some string – an account number, user ID, and so on. We have to use their applications to interact with the data about us, however, and we have to use their identifier(s) for us. If we want to build any semblance of a holistic picture of ourselves (more accurately, collect all the data about us that they externalize), we as humans must use their custom applications to find the data, copy it, and organize it to suit our needs.

Would it not be simpler if at least the Web-addressable portion of that data could be linked to consistently, so that instead of maintaining various identifiers in different formats and instead of having to manually supply those identifiers to each one’s corresponding custom application, we could essentially build a set of bookmarks to it all? When we want to [[#UC3: Retrieve resource description|examine]] or [[#UC4: Update existing resource|change]] their contents, would it not be simpler if there were a single consistent application interface that they all supported? Of course it would.

Our set of links would probably be a [[#UC6: Aggregate resources|simple collection]]. The information held by any single organization might be a mix of simple data and [[#UC6: Aggregate resources|collections of other data]], for example, a bank account balance and a collection of historical transactions. Our bank might easily have [[#Alternative scenario: create a nested container|a collection of accounts for each of its collection of customers]].

=== System and Software Development Tool Integration ===

System and software development tools typically come from a diverse set of vendors and are built on various architectures and technologies. These tools are purpose built to meet the needs for a specific domain scenario (modeling, design, requirements and so on.) Often tool vendors view integrations with other tools as a necessary evil rather than providing additional value to their end-users. Even more of an afterthought is how these tools’ data -- such as people, projects, customer-reported problems and needs -- integrate and relate to corporate and external applications that manage data such as customers, business priorities and market trends. The problem can be isolated by standardizing on a small set of tools or a set of tools from a single vendor, but this rarely occurs and if does it usually does so only within small organizations. As these organizations grow both in size and complexity, they have needs to work with outsourced development and diverse internal other organizations with their own set of tools and processes. There is a need for better support of more complete business processes (system and software development processes) that span the roles, tasks, and data addressed by multiple tools. This demand has existed for many years, and the tools vendor industry has tried several different architectural approaches to address the problem. Here are a few:

* Implement an API for each application, and then, in each application, implement “glue code” that exploits the APIs of other applications to link them together.
* Design a single database to store the data of multiple applications, and implement each of the applications against this database. In the software development tools business, these databases are often called “repositories.”
* Implement a central “hub” or “bus” that orchestrates the broader business process by exploiting the APIs described previously.

It is fair to say that although each of those approaches has its adherents and can point to some successes, none of them is wholly satisfactory. The use of Linked Data as an application integration technology has a strong appeal. [http://open-services.net/ OSLC]

=== Library Linked Data ===

The W3C Library Linked Data working group has a number of use cases cited in their Use Case Report. [http://www.w3.org/2005/Incubator/lld/wiki/UseCaseReport LLD-UC] These referenced use cases focus on the need to extract and correlate library data from disparate sources. Variants of these use cases that can provide consistent formats, as well as ways to improve or update the data, would enable simplified methods for both efficiently sharing this data as well as producing incremental updates without the need for repeated full extractions and import of data.

The 'Digital Objects Cluster' contains a number of relevant use-cases:

* Grouping: This should "Allow the end-users to define [[#UC6: Aggregate resources|groups of resources]] on the web that for some reason belong together. The relationship that exists between the resources is often left unspecified. Some of the resources in a group may not be under control of the institution that defines the groups."

* Enrichment: "Enable end-users to [[#UC4: Update existing resource|link resources together]]."

* Browsing: "[[#UC7: Filter resource description|Support end-user browsing through groups]] and resources that belong to the groups."

* Re-use: "Users should have the capability to re-use all or parts of a collection, with all or part of its metadata, elsewhere on the linked Web."

The 'Collections' cluster also contains a number of relevant use-cases:

* Collection-level description: "Provide [[#UC7: Filter resource description|metadata pertaining to a collection as a whole]], in contrast to item-level description."

* Collections discovery: "Enable innovative collection discovery such as identification of nearest location of a physical collection where a specific information resource is found or mobile device applications ... based on collection-level descriptions."

* Community information services: Identify and classify collections of special interest to the community.

=== Municipality Operational Monitoring ===

Across various cities, towns, counties, and various municipalities there is a growing number of services managed and run by municipalities that produce and consume a vast amount of information. This information is used to help monitor services, predict problems, and handle logistics. In order to effectively and efficiently collect, produce, and analyze all this data, a fundamental set of loosely coupled standard data sources are needed. A simple, low-cost way to [[#UC3: Retrieve resource description|expose data]] from the diverse set of monitored services is needed, one that can easily integrate into the municipalities of other systems that inspect and analyze the data. All these services have links and dependencies on other data and services, so having a simple and scalable linking model is key.

=== Healthcare ===

For physicians to analyze, diagnose, and propose treatment for patients requires a vast amount of complex, changing and growing knowledge. This knowledge needs to come from a number of sources, including physicians’ own subject knowledge, consultation with their network of other healthcare professionals, public health sources, food and drug regulators, and other repositories of medical research and recommendations.

To diagnose a patient’s condition requires current data on the patient’s medications and medical history. In addition, recent pharmaceutical advisories about these medications are linked into the patient’s data. If the patient experiences adverse affects from medications, these physicians need to publish information about this to an appropriate regulatory source. Other medical professionals require access to both validated and emerging effects of the medication. Similarly, if there are geographical patterns around outbreaks that allow both the awareness of new symptoms and treatments, this information needs to quickly reach a very distributed and diverse set of medical information systems. Also, reporting back to these regulatory agencies regarding new occurrences of an outbreak, including additional details of symptoms and causes, is critical in producing the most effective treatment for future incidents.

=== Metadata Enrichment in Broadcasting ===

There are many different use cases when broadcasters show interest in metadata [[#UC4: Update existing resource| enrichment]]:

* enrich archive or news metadata by linking facts, events, locations and personalities
* enrich metadata generated by automatic extraction tools such as person identification, etc.
* enrich definitions of terms in classification schemes or enumeration lists

This comes in support of more effective information management and data/content mining (if you can't find your content, it' like if you don't have and must either recreate or acquire it again, which is not financially effective).

However, there is a need for solutions facilitating linkage to other data sources and taking care of the issues such as discovery, automation, disambiguation. Etc. Other important issues that broadcasters would face are the editorial quality of the linked data, its persistence, and usage rights.

=== Aggregation and Mashups of Infrastructure Data ===

For infrastructure management (such as storage systems, virtual machine environments, and similar IaaS and PaaS concepts), it is important to provide an environment in which information from different sources can be [[#UC6: Aggregate resources|aggregated]], [[#UC7: Filter resource description|filtered]], and visualized effectively. Specifically, the following use cases need to be taken into account:

* While some data sources are based on Linked Data, others are not, and aggregation and mashups must work across these different sources.
* Consumers of the data sources and aggregated/filtered data streams are not necessarily implementing Linked Data themselves, they may be off-the-shelf components such as dashboard frameworks for composing visualizations.
* Simple versions of this scenario are pull-based, where the data is requested from data sources. In more advanced settings, without a major change in architecture it should be possible to move to a push-based interaction model, where data sources push notifications to subscribers, and data sources provide different services that consumers can subscribe to (such as "informational messages" or "critical alerts only").

In this scenario, the important factors are to have abstractions that allow easy aggregation and filtering, are independent from the internal data model of the sources that are being combined, and can be used for pull-based interactions as well as for push-based interactions.

=== Sharing payload of RDF data among low-end devices ===

Several projects around the idea of [http://worldwidesemanticweb.wordpress.com/ downscaling the Semantic Web] need to be able to ship payloads of RDF across the nodes member of a given network. The transfers are done in a constrained context in terms of bandwidth, scope of the local semantics employed by the nodes and computing capabilities of the nodes. In a P2P style, every node has the capability to act either as a data consumer or a data provider, serving its own data or acting as a relay to pass other's data along (typically in mesh networks).

The transfer of an arbitrary payload of RDF data could be implemented through the container mechanism, adding and removing sets of RDF triples to it. Currently, one of the project "SemanticXO" uses named graphs and the graph protocol to create/delete/copy graphs across the nodes but this (almost) imposes the usage of a triple store. Unfortunately, triple store are rather demanding piece of software that are not always usable on limited hardware. Some generic ReST like interaction backed up with a lightweight column store would be better approach.

=== Sharing Binary Resources and Metadata ===

When publishing datasets about stars one may want to publish links to the pictures in which those stars appear, and this may well require publishing the pictures themselves. Vice versa: when publishing a picture of space we need to know which telescope took the picture, which part of the sky it was pointing at, what filters were used, which identified stars are visible, who can read it, who can write to it, ...

If LinkedData contains information about resources that are most naturally expressed in non-rdf formats (be they binary such as pictures or videos, or human readable documents in XML formats), those non RDF formats should be just as easy to publish to the LinkedData server as the RDF relations that link those resources up. A LinkedData server should therefore allow publishing of non linked data resources too, and make it easy to publish and edit metadata about those resources.

The resource comes in two parts - the image and information about the image (which may in the image file but better external to it as it's more general). The information about the image is vital. It's a compound item of image data and other data (being application metadata about the image does not distinguish from the platform's point-of-view.

=== Data Catalogs ===

The Asset Description Metadata Schema ([http://joinup.ec.europa.eu/asset/adms/home ADMS]) provides the data model to describe semantic assets repositories contents, but this leaves many open challenges when building a federation of these repositories to serve the need of assets reuse. These include accessing and querying individual repositories and efficiently retrieving [[#UC5: Determine if a resource has changed| updated content]] without having to retrieve the whole content. Hence, we chose to build the integration solution capitalizing on the Data Warehousing integration approach. This allows us to cope with heterogeneity of sources technologies and to benefit from the optimized performance it offers, given that individual repositories do not usually change frequently. With Data Warehousing, the federation requires to:

* understand the data, i.e. understand their semantic descriptions, and other systems.
* seamlessly exchange the semantic assets metadata from different repositories
* keep itself up-to-date.

Repositories owners can maintain de-referenceable URIs for their repository description and contained assets in a Linked Data compatible manner. ADMS provides the necessary data model to enable meaningful exchange of data. However, This leaves the challenge of efficient access to the data not fully addressed.

Related: [http://spec.datacatalogs.org/ Data Catalog Schema and Protocol]

=== Constrained Devices and Networks ===

Information coming from resource constrained devices in the Web of Things ([http://en.wikipedia.org/wiki/Web_of_Things WoT]) has been identified as a major driver in many domains, from smart cities to environmental monitoring to real-time tracking. The amount of information produced by these devices is growing exponentially and needs to be accessed and integrated in a systematic, standardized and cost efficient way. By using the same standards as on the Web, integration with applications will be simplified and higher-level interactions among resource constrained devices, abstracting away heterogeneities, will become possible. Up-coming IoT/WoT standards such as [http://datatracker.ietf.org/wg/6lowpan/ 6LowPAN] - IPv6 for resource constrained devices - and the Constrained Application Protocol ([http://tools.ietf.org/html/draft-ietf-core-coap CoAP]), which provides a downscaled version of HTTP on top of UDP for the use on constrained devices, are already at a mature stage. The next step now is to support RESTful interfaces also on resource constrained devices, adhering to the Linked Data principles. Due to the limited resources available, both on the device and in the network (such as bandwidth, energy, memory) a solution based on SPARQL Update is at the current point in time considered not to be useful and/or feasible. An approach based on the [http://tools.ietf.org/html/draft-castellani-core-http-mapping HTTP-CoAP Mapping] would enable constrained devices to directly participate in a Linked Data-based environment.

=== Services Supporting the Process of Science ===
Many fields of science now include branches with in silico data-intensive methods, e.g. bioinformatics, astronomy. To support these new methods we look to move beyond the established platforms provided by scientific workflow systems to capture, assist, and preserve the complete lifecycle from record of the experiment, through local trusted sharing, analysis, dissemination (including publishing of experimental data "beyond the PDF"), and re-use.

* [[#UC6: Aggregate resources|Aggregations]], specifically ''Research Objects (ROs)'' that are exchanged between services and clients bringing together workflows, data sets, annotations, and provenance. We use an RDF model for this. While some aggregated contents are encoded using RDF and in increasing number are linked data sources, others are not; while some are stored locally "within" the RO, others are remote (in both cases this is often due to size of the resources or access policies).
* Services that are distributed and linked. Some may be centralising for e.g. publication, others may be local, e.g. per lab. We need lightweight services that can be simply and easily integrated into and scale across the wide variety of softwares and data used in science: we have adopted a RESTful approach where possible.
** Foundation services that collect and expose ROs for storage, modification, exploration, and reuse.
** Services that provide added-value to ROs such as seamless import/export from scientific workflow systems, automated stability evaluation, or recommendation (and therefore interact with the foundation services to retrieve/store/modify/ROs).

seeAlso: [http://www.wf4ever-project.org/ Wf4Ever]

=== Project Membership Information : Information Evolution ===

Information about people and projects changes as roles change, as organisations change
and as contact details change. Finding the current state of a project is important
in enabling people to contact the right person in the right role. It can also be
useful to look back and see who was performing what role in the past.

A use of a Linked Data Platform could be to give responsibility for managing
such information with the project team itself, not requiring updates to be
requested of a centralised website administrator.

This could be achieved with:

* Resource descriptions for each person and project
* A container resource to describe roles/membership in the project.

To retain the history of the project, the old version of a resources,
including container resources, should be retained so there is a need to address both specific items
and also have a notion of "current".

Access to information has two aspects:
* Access to the "current" state, regardless of the version of the resource description
* Access to historical state, via access to a specific version of the resource description

=== Cloud Infrastructure Management===

Cloud operators offer API support to provide customers with remote access for infrastructure management. Infrastructure consists of Systems, Computers, Networks, Discs, etc, and the overall structure can be seen as mostly hierarchical, (Cloud contains Systems, Systems contain Machines, etc). This is complemented with crossing links (e.g. Machines connected to a Network). The IaaS scenario also makes requirements for lifecycle management, non-instant changes and history capture. Infrastructure management can be seen as the manipulation of the underlying graph.

== Use Cases ==
The following use-cases are each derived from one or more of the user-stories above. These use-cases are explored in detail through the development of scenarios, each motivated by some key aspect exemplified by a single user-story. The examples they contain are included purely for illustrative purposes, and should not be interpreted normatively.

===UC1: Manage containers===
A number of user-stories introduce the idea of a ''container'' as a mechanism for creating and managing resources within the context of an application. Resources grouped together within the same container would typically belong to the same application. A container is identified by a URI so is a resource in its own right.
The properties of a container may also represent the ''affordances'' of that container, enabling clients to determine what other operations they can do on that container. These operations may include descriptions of application specific services that can be invoked by exchanging RDF documents.

* Provide "access guidance for ... resources" (affordances) (from user-story, [[#Maintaining Social Contact Information|Maintaining Social Contact Information]]).

====Primary scenario: create container====
Create a new container resource within the LDP server.
In [[#Services Supporting the Process of Science|Services supporting the process of science]], [http://wf4ever.github.com/ro-primer/ Research Objects] are semantically rich aggregations of resources that bring together data, methods and people in scientific investigations. A basic workflow research object will be created to aggegate [http://ceur-ws.org/Vol-903/paper-01.pdf scientific workflows] and the artefacts that result from this workflow. The research object begins life as an empty container into which workflows, datasets, results and other data will be added throughout the lifecycle of the project.

<nowiki>
@prefix ro: http://purl.org/wf4ever/ro#
@prefix dct: http://purl.org/dc/terms/
@prefix ore: http://www.openarchives.org/ore/

<> a ro:ResearchObject, ore:Aggregation ;
dct:created "2012-12-01"^^xsd:dateTime .
</nowiki>

====Alternative scenario: create a nested container====
The motivation for nested containers comes from the [[#System and Software Development Tool Integration| System and Software Development Tool Integration]] user-story. The OSLC Change Management vocabulary allows bug reports to have attachments referenced by the membership predicate <nowiki>oslc_cm:attachment</nowiki>. The 'top-level-container' contains issues, and each issue resource has its own container of attachment resources.

<nowiki>
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix oslc_cm: <http://open-services.net/ns/cm#>.
@prefix : <http://example.org/>.

:top-level-container rdfs:member :issue1234 .

:issue1234 a oslc_cm:ChangeRequest;
dcterms:identifier "1234";
dcterms:type "a bug";
dcterms:related :issue1235 ;
oslc_cm:attachments :attachments123.

:issue1235 a oslc_cm:ChangeRequest;
dcterms:title "a related bug".

:attachments a oslc_cm:AttachmentList;
oslc_cm:attachment :attachment324, :attachment251.
</nowiki>

===UC2: Manage resources===
This use-case addresses the managed lifecycle of a resource and is concerned with resource ''ownership''. The responsibility for managing resources belongs with their container.
For example, a container may accept a request from a client to make a new resource.
This use-case focuses on creation and deletion of resources in the context of a container, and the potential for transfer of ownership by moving resources between containers.
The ownership of a resource should always be clear; no resource managed in this way should ever be owned by more than one container.

Once a new resource has been created it should be identified by a URI. Clients may defer responsibility for establishing dereferenceable URIs to the container of their data.
The container is a natural choice for the endpoint for this interface as it will already have some application-specific knowledge about the contained resources.
While the LDP has ultimate control over resource naming, some applications may require more control over naming, perhaps to provide a more human-readable URI. An LDP server could support something like the [http://tools.ietf.org/html/rfc5023 Atom Publishing Protocol] slug header to convey a user defined naming 'hint'.

* Non-duplication of resources: "Eliminate multiple copies", representing resources in a single place (from [[#Maintaining Social Contact Information]]).
* Distribution of resources: Linked aata "may be stored on separate servers" (from [[#Maintaining Social Contact Information]]).
* Consistent, global naming: Resources should be "linked to consistently, ... instead of maintaining various identifiers in different formats" (from [[#Keeping Track of Personal and Business Relationships]]).

====Primary scenario: create resource====
Resources begin life by being created within a container. From user-story, [[#Maintaining Social Contact Information|Maintaining Social Contact Information]], It should be possible to "easily create a new contact and add it to my contacts." This suggests that resource creation is closely linked to the application context. The new resource is created in a container representing "my contacts." The lifecycle of the resource is linked to the lifecycle of it's container. So, for example, if "my contacts" is deleted then a user would also reasonably expect that all contacts within it would also be deleted.

Contact details are captured as an RDF description and it's properties, including "names, email addresses, telephone numbers, instant messenger identities and so on." The description may include non-standard RDF; "data about my contacts that the original design didn’t consider."
The following RDF could be used to describe contact information using the [http://www.foaf-project.org FOAF] vocabulary. A contact is represented here by a <nowiki>foaf:PersonalProfileDocument</nowiki> defining a resource that can be created and updated as a single-unit, even though it may describe ancillary resources, such as a <nowiki>foaf:Person</nowiki>, below.

<nowiki>
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

<> a foaf:PersonalProfileDocument;
foaf:PrimaryTopic [
a foaf:Person;
foaf:name "Timothy Berners-Lee";
foaf:title "Sir";
foaf:firstName "Timothy";
foaf:surname "Berners-Lee";
foaf:nick "TimBL", "timbl";
foaf:homepage <http://www.w3.org/People/Berners-Lee/>;
foaf:weblog <http://dig.csail.mit.edu/breadcrumbs/blog/4>;
foaf:mbox <mailto:timbl@w3.org>;
foaf:workplaceHomepage <http://www.w3.org/>.
]
</nowiki>

====Alternative scenario: delete resource====
Delete a resource and all it's properties. If the resource resides within a container it will be removed from that container, however other links to the deleted resource may be left as dangling references.
In the case where the resource is a container, the server may also delete any or all contained resources.
In normal practice, a deleted resource cannot be reinstated. There are however, edge-cases where limited undelete may be desirable.
Best practice states that "[http://www.w3.org/TR/cooluris/| Cool URIs don't change]", which implies that deleted URIs shouldn't be recycled.

====Alternative scenario: moving contained resources====
Many resources may have value beyond the life of their membership in a container. This implies methods to add references to revise container membership.
Cloning container members for use in other containers results in duplication of information and maintenance problems; web practice is to encourage the creation of one resource, which may be referenced as many places as necessary. A change of ownership may - or may not - imply a change of URI, depending upon the specific LDP naming policy. While assigning a new URI to a resource is discouraged [http://www.w3.org/DesignIssues/Architecture.html#HTTP], it is possible to indicate that a resource has moved with an appropriate HTTP response.

===UC3: Retrieve resource description===
Access the current description of a resource, containing properties of that resource and links to related resources. The representation may include descriptions of related resources that cannot be accessed directly.
Depending upon the application, an LDP may enrich the retrieved RDF with additional triples. Examples include adding incoming links, sameAs closure and type closure.
The HTTP response should also include versioning information (i.e. last update or entity tag) so that subsequent updates can ensure they are being applied to the correct version.

* Use standard vocabularies as appropriate to enable a "common understanding of the resource" (from [[#Maintaining Social Contact Information|Maintaining Social Contact Information]]).
* A "scalable linking model is key" (from [[#Municipality Operational Monitoring]]).

====Primary scenario====
The user-story [[#Project Membership Information : Information Evolution| Project Membership Information]] discusses the representation of information about people and projects. It calls for "Resource descriptions for each person and project" allowing project teams to review information held about these resources. The example below illustrates the kinds of information that might be held about organizational structures based on the [http://www.epimorphics.com Epimorphics] [http://www.epimorphics.com/public/vocabulary/org.html organizational ontology].

Note that the example below defines two resources (shown as separate sections below) that will be hosted on an LDP based at <nowiki>http://example.com/</nowiki>. The representations of these resources may include descriptions of related resources, such as <nowiki>http://www.w3.org/</nowiki>, that that fall under a different authority and therefore can't be served from the LDP at this location.

<nowiki>
@prefix org: <http://www.w3.org/ns/org#> .
@prefix owltime: <http://www.w3.org/2006/time> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@base <http://example.com/> .

<member1> a org:Membership ;
org:member <http://www.w3.org/People/Berners-Lee/card#i> ;
org:organization http://www.w3.org/> ;
org:role <director> ;
org:memberDuring [a owltime:Interval; owltime:hasBeginning [
owltime:inXSDDateTime "1994-10-01T00:00:00Z"^^xsd:dateTime]] .

<http://www.w3.org/> a org:FormalOrganization ;
skos:prefLabel "The World Wide Web Consortium"@en ;
skos:altLabel "W3C" .
</nowiki>

<nowiki>
@prefix org: <http://www.w3.org/ns/org#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@base <http://example.com/> .

<director> a org:Role ;
rdfs:label "Director" .
</nowiki>

====Alternative scenario: retrieve description of a non-document resource====
In many cases, the things that are of interest are not always the things that are resolvable. The example below demonstrates how a foaf profile may be used to distinguish between the person and the profile; the former being the topic of the latter. This begs the question as to what a client should do with such non-document resources. In this case the HTTP protocol requires that the fragment part be stripped off before requesting the URI from the server. The result is a resolvable URI for the profile.

<nowiki>
@base <http://www.w3.org/People/Berners-Lee/card>
@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@prefix dc: <http://purl.org/dc/elements/1.1/>.

<> a foaf:PersonalProfileDocument ;
dc:title "Tim Berners-Lee's FOAF file" ;
foaf:homepage <http://www.w3.org/People/Berners-Lee/> ;
foaf:primaryTopic <#i> .
</nowiki>

===UC4: Update existing resource===
Change the RDF description of a LDP resource, potentially removing or overwriting existing data. This allows applications to ''enrich'' the representation of a resource by addling additional links to other resources.

* Unrestricted vocabulary: It should be possible be "able to add ... application-specific data" to resources (from [[#Maintaining Social Contact Information]]).

====Primary scenario: enrichment====
This relates to user-story [[#Metadata Enrichment in Broadcasting| Metadata Enrichment in Broadcasting]] and is based on the [http://www.bbc.co.uk/ontologies/sport/ BBC Sports Ontology]. The ''resource-centric'' view of linked-data provides a natural granularity for substituting, or overwriting a resource and its data. The simplest kind of update would simply replace what is currently known about a resource with a new representation. There are two distinct resources in the example below; a sporting event and an associated award. The granularity of the LDP would allow a user to replace the information about the award without disturbing the information about the event.

<nowiki>
@prefix sport: <http://www.bbc.co.uk/ontologies/sport/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

:mens_sprint a sport:MultiStageCompetition;
rdfs:label "Men's Sprint";
sport:award <#gold_medal> .

<#gold_medal> a sport:Award .
</nowiki>

We can enrich the description as events unfold, linking to the winner of the gold medal by substituting the above description with the following.

<nowiki>
@prefix sport: <http://www.bbc.co.uk/ontologies/sport/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

:mens_sprint a sport:MultiStageCompetition;
rdfs:label "Men's Sprint";
sport:award <#gold_medal> .
<#gold_medal> a sport:Award;
sport:awarded_to [
a foaf:Agent ;
foaf:name "Chris Hoy" .
] .
</nowiki>

====Alternative scenario: selective update of a resource====
This relates to user-story [[#Data Catalogs|Data Catalogs]], based on the [http://vocab.deri.ie/dcat Data Catalog Vocabulary].
A catalogue is described by the following RDF model.

<nowiki>
@prefix dcat: <http://www.w3.org/ns/dcat#> .
@prefix dcterms: <http://purl.org/dc/terms/> .

:catalog a dcat:Catalog ;
dcat:dataset :dataset/001;
dcterms:issued "2012-12-11"^^xsd:date.
</nowiki>

A catalog may contain multiple datasets, so when linking to new datasets it would be simpler and preferable to selectively add just the new dataset links.
A Talis ''changeset'' [http://docs.api.talis.com/getting-started/changesets][http://www.w3.org/2009/12/rdf-ws/papers/ws07] could be used to add a new <nowiki>dc:title</nowiki> to the dataset. The following update would be directed to the catalogue to add an additional dataset.

<nowiki>
@prefix : <http://example.com/>.
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix cs: <http://purl.org/vocab/changeset/schema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.

<change1>
a cs:ChangeSet ;
cs:subjectOfChange :catalog ;
cs:createdDate "2012-01-01T00:00:00Z" ;
cs:changeReason "Update catalog datasets" ;
cs:addition [
a rdf:Statement ;
rdf:subject :catalog ;
rdf:predicate dcat:dataset ;
rdf:object :dataset/002 .
] .
</nowiki>

===UC5: Determine if a resource has changed===
It should be possible to retrieve versioning information about a resource (e.g. last modified or entity tag) without having to download a representation of the resource.
This information can then be compared with previous information held about that resource to determine if it has changed.
This versioning information can also be used in subsequent ''conditional'' requests to ensure they are only applied if the version is unchanged.

====Primary scenario====
Based on the user-story, [[#Constrained Devices and Networks| Constrained Devices and Networks]], an LDP could be configured to act as a proxy for a [http://tools.ietf.org/html/draft-ietf-core-coap CoAP] based [http://en.wikipedia.org/wiki/Web_of_Things Web of Things]. As an observer of CoAP resources, the LDP registers its interest so that it will be notified whenever the sensor reading changes. Clients of the LDP can interrogate the LDP to determine if the state has changed.

In this example, the information about a sensor and corresponding sensor readings can be represented as RDF resources. The first resource below, represents a sensor described using the [http://www.w3.org/2005/Incubator/ssn/ Semantic Sensor Network] ontology.
<nowiki>
@prefix : <http://example.com/energy-management/>.

<> a :MainsFrequencySensor;
rdfs:comment "Sense grid load based on mains frequency";
ssn:hasMeasurementCapability [
a :FrequencyMeasurementCapability;
ssn:hasMeasurementProperty <#property_1> .
] .
</nowiki>

The value of the sensor changes in real-time as measurements are taken. The LDP client can interrogate the resource below to determine if it has changed, ''without'' necessarily having to download the RDF representation. As different sensor properties are represented disjointly (separate RDF representations) they may change independently.

<nowiki>
@prefix : <http://example.com/energy-management/>.

<http://example.com/energy-management#property_1> :hasMeasurementPropertyValue <> .
<> a :FrequencyValue;
:hasQuantityValue "50"^^xsd:float.
</nowiki>

===UC6: Aggregate resources===
There is a requirement to be able to manage ''collections'' of resources. The concept of a collection overlaps with, but is distinct from that of a container. These collections are (weak) aggregations, unrelated to the lifecycle management of resources, and distinct from the ownership between a resource and its container. However, the composition of a container may be reflected as a collection to support navigation of the container and its contents. There is a need to be able to create collections by adding and deleting individual membership properties. Resources may belong to multiple collections, or to none.

* Resource descriptions are a "mix of simple data and collections" (from [[#Keeping Track of Personal and Business Relationships]]).
* Relative URIs: It should be possible to "ship payloads of RDF" for a collection as a whole without breaking internal links (from [[#Constrained Devices and Networks]]).

====Primary scenario: add a resource to a collection====
This example is from [[#Library Linked Data|Library Linked Data]] and [http://www.w3.org/2005/Incubator/lld/wiki/UseCaseReport LLD-UC], specifically [http://www.w3.org/2005/Incubator/lld/wiki/Use_Case_Subject_Search Subject Search].

There is an existing collection at <nowiki><http://example.com/concept-scheme/subject-heading></nowiki> that defines a collection of subject headings. This collection is defined as a skos:ConceptScheme and
the client wishes to insert a new concept into the scheme. which will be related to the collection via a <nowiki>skos:inScheme</nowiki> link. The new subject-heading, "outer space exploration", is not necessarily owned by a container. The following RDF would be added to the (item-level) description of the collection.

<nowiki>
@prefix scheme : <http://example.com/concept-scheme/>.
@prefix concept : <http://example.com/concept/>.

scheme:subject-heading a skos:ConceptScheme.

concept:Outer+space+Exploration skos:inScheme scheme:subject-heading.
</nowiki>

====Alternative scenario: add a resource to multiple collections====
Logically, a resource should not be owned by more than one container. however, it may be a member of multiple collections which define a weaker form of ''aggregation''. As this is simply a manipulation of the RDF description of a collection, it should be possible to add the same resource to multiple collections.

As a machine-readable collection of medical terms, the [http://www.ihtsdo.org| SNOMED] ontology is of key importance in [[#Healthcare | healthcare]]. SNOMED CT allows concepts with more than one parent that don't fall into a lattice.
In the example below, the same concept may fall under two different parent concepts.
The example uses skos:narrowerTransitive to elide intervening concepts.

<nowiki>
@prefix : <http://example.com/snomed/>.

:_119376003 a skos:Concept ;
skos:prefLabel "Tissue specimen"
skos:narrowerTransitive :TissueSpecimenFromHeart.

:_127462005 a skos:Concept ;
skos:prefLabel "Specimen from heart"
skos:narrowerTransitive :TissueSpecimenFromHeart.

:_128166000 a skos:Concept;
rdfs:label "Tissue specimen from heart".
</nowiki>

===UC7: Filter resource description===
This use-case extends the normal behaviour of retrieving an RDF description of a resource, by dynamically excluding specific (membership) properties.
For containers, it is often desirable to be able to read a collection, or item-level description that excludes the container membership.

====Primary scenario: retrieve collection-level description====
This scenario, based on [[#Library Linked Data| Library Linked Data]], uses the Dublin Core Metadata Initiative [http://dublincore.org/groups/collections/collection-application-profile/| Collection-Level] description.
A collection can refer to any aggregation of physical or digital items.
This scenario covers the case whereby a client can request a collection-level description as typified by the example below, without necessarily having to download a full listing of the items within the collection.

<nowiki>
@prefix rdf: <rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">.
@prefix dc: <http://purl.org/dc/elements/1.1/>.
@prefix : <http://example.org/bookshelf/>.
@prefix dcmitype: <http://purl.org/dc/dcmitype/>.
@prefix cld: <http://purl.org/cld/terms/>.
@prefix dcterms: <http://purl.org/dc/terms/>.

<> dc:type dcmitype:Collection ;
dc:title "Directory of organizations working with Linked Data" ;
dcterms:abstract "This is a directory of organisations specializing in Linked Data."
cld:isLocatedAt <http://dir.w3.org>
cld:isAccessedVia <http://dir.w3.org/rdf/2012/directory/directory-list.xhtml?construct>
</nowiki>

====Alternative scenario: retrieve item-level description of a collection====
This use-case scenario, also based on [[#Library Linked Data| Library Linked Data]], focuses on obtaining an item-level description of the resources aggregated by a collection.
The simplest scenario is where the members of a collection are returned within a single representation, so that a client can explore the data by following these links. Different applications may use different membership predicates to capture this aggregation. The example below uses <nowiki>rdfs:member</nowiki>, but many different membership predicates are in common use, including RDF Lists.
Item-level descriptions can be captured using the Functional Requirements for Bibliographic Records ([http://www.ifla.org/publications/functional-requirements-for-bibliographic-records FRBR]) [http://vocab.org/frbr/core.html ontology].

<nowiki>
@prefix frbr: <http://purl.org/vocab/frbr/core#>.

<> rdfs:member <#ebooks97>, <#ebooks21279>.

<#work97> a frbr:LiteraryWork;
dc:title "Flatland: a romance of many dimensions" ;
frbr:creator <#Abbott_Edwin>;
frbr:manifestation <ebook97>.

<#work21279> a frbr:LiteraryWork;
dc:title "2 B R 0 2 B" ;
frbr:creator <#Vonnegut_Kurt>;
frbr:manifestation <ebook21279>.
</nowiki>

Collections are potentially very large, so some means may be required to limit the size of RDF representation returned by the LDP (e.g. pagination).

===UC8: Manage media resources===
It should be possible to easily add non-RDF media resources to containers that accept them. Media resources may be updated and removed during the lifecycle of the container.

====Primary scenario: access media resources====
From the User Story [[#Sharing Binary Resources and Metadata| Sharing Binary Resources and Metadata]] it should be possible to easily add non RDF resources to a containers that accept them. Clients submit a non-RDF representation to a container in a media type accepted by that container. The container creates a URI to represent this media resource, and creates a link from the container to the new URI.The media resource may have an explicit representation of the media type. It should be possible to find the metadata about such a resource and to access and edit it in the usual ways.

This example uses the [http://www.w3.org/TR/mediaont-10/#ont-ttl Ontology for Media Resources] to describe a media resource added to a collection.
<nowiki>
@prefix ma: <http://www.w3.org/ns/ma-ont#> .

<dataset> a ma:Collection ;
:hasMember <dataset/image1.jpg>

<dataset/image1.jpg> a ma:MediaResource ;
ma:hasFormat "image/jpeg" .
</nowiki>

====Alternative scenario: media-resource attachments====
A resource may have multiple ''renditions''; the idea that you can have a PDF and a JPEG representing the same thing. A user is trying to create a work order along with an attached image showing a faulty machine part. To the user and to the work order system, these two artifacts are managed as a set. A single request may create the work order, the attachment, and the relationship between them, atomically.
When the user retrieves the work order later, they expect a single request by default to retrieve the work order plus all attachments.
When the user updates the work order, e.g. to mark it completed, they only want to update the work order proper, not its attachments.
Users may add/remove/replace attachments to the work order during its lifetime.

== Requirements ==

'''TODO: Refine these based on use case and scenario updates'''

===Functional Requirements===
# Create Containers, from [[#UC1: Manage containers]]
# Creation of nested containers, from [[#UC1: Manage containers]]
# Creation of resources (within a container), from [[#UC2: Manage resources]]
# Deletion of resources, from [[#UC2: Manage resources]]
# Moving contained resources, from [[#UC2: Manage resources]]
# Retrieve resource description, from [[#UC3: Retrieve resource description]]
# Retrieve description of a non-document resource, from [[#UC3: Retrieve resource description]]
# Enrichment (substituting update of existing resource), from [[#UC4: Update existing resource]]
# Selective update of a resource, from [[#UC4: Update existing resource]]
# Determine if a resource has changed, from [[#UC5: Determine if a resource has changed]]
# Add a resource to a collection, from [[#UC6: Aggregate resources]]
# Add a resource to multiple collections, from [[#UC6: Aggregate resources]]
# Retrieve collection-level description, from [[#UC7: Filter resource description]]
# Retrieve item-level description of a collection, from [[#UC7: Filter resource description]]
# Add non-RDF resources, from [[#UC8: Manage non-RDF Resources]]
# Add multiple non-RDF resources, from [[#UC8: Manage non-RDF Resources]]

===Non-Functional Requirements===

# Provide access guidance to resources, from [[#UC1: Manage containers]]
# Non-duplication of resources, from [[#UC2: Manage resources]]
# Distribution of resources, from [[#UC2: Manage resources]]
# Consistent, global naming, from [[#UC2: Manage resources]]
# Use standard vocabularies as appropriate, from [[#UC3: Retrieve resource description]]
# Scalable linking model, from [[#UC3: Retrieve resource description]]
# Unrestricted vocabulary, from [[#UC4: Update existing resource]]
# Resource descriptions are a "mix of simple data and collections", from [[#UC6: Aggregate resources]]
# Relative URIs enabling sharing of collections, from [[#UC6: Aggregate resources]]

== Acknowledgements ==
We would like to acknowledge the contributions of user-story authors; Christophe Guéret, Roger Menday, Eric Prud'hommeaux.

== References ==

Examples

Sbattle2 — Mon, 10 Dec 2012 11:15:57 GMT

Sbattle2: /* Hosting POSTed Resources */

= Other User Stories =

=== RESTful Interactions ===

REST's main focus is on building interactions around the exchange transfer between clients and servers. For this to work, it must be possible to define and communicate expectations for certain state transfers. [https://gist.github.com/2927644 In this gist] the discussion centers around book orders, but pretty much any interaction in a SOA context could be used: some interaction requires a specific state transfer between client and server, and there must be a way how this state transfer is

* captured in the context of a bigger interaction flow (what a media type defines on the web), and
* expressed by means of expectations/constraints that apply to a specific representations, so that a server can validate against those expectations/constraints, and only accept those representations which satisfy the expectations/constraints (what often is done with a combination of schemas and prose in the context of a media type's conversation).

"[http://dret.typepad.com/dretblog/2012/07/what-are-linked-data-services.html What Are Linked Data Services?]" describes these requirements as the "service surface" that needs to be defined by any platform that is providing some sort of services. This becomes particularly important in any kind of loosely coupled scenario, where servers/services cannot trust clients to always do the "right thing" or "behave cooperatively". instead, the platform must provide support so that misbehaving and adversarial clients can be dealt with effectively, and that means that the "service contract" needs to define the service surface based on the state representations that are acceptable in the context of the use case that is addressed by the service, so that anything else can be easily rejected.

=== Hosting POSTed Resources ===

<http://dev.example/bugs> is a factory resource for creating new bugs (well, documenting existing bugs). It accepts <Bug>s of the form:

_:newBug a <Bug> ;
<product> <http://products.example.com/gun> ;
<issueText> "kills people" ;
dc:author "Bob" ;
dc:date "2012-07-04T23:54"^^xsd:dateTime

By this definition "hosting" means changing '''_:newBug''' to '''<http://dev.example/bug/7>'''. LDP doesn't provide any guidance around that.

===Constrained Devices===

For a detailed description of [http://www.w3.org/2012/ldp/wiki/images/2/2e/Application-scenarios-constrained-devices.pdf application scenarios for constrained devices] see a separate document kindly compiled by [http://www.deri.ie/about/team/member/myriam_leggieri/ Myriam Leggieri].

= Linked Data Platform Examples =

In the scenarios that follow, there are a number of commonly used namespace prefixes:

<nowiki>
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix bp: <http://example.com/ns/basicProfile#>.
@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@prefix wdrs: <http://www.w3.org/2007/05/powder-s#>.
@prefix skos <http://www.w3.org/2004/02/skos/core#>.
@prefix dcat: <http://www.w3.org/ns/dcat#>.
@prefix dc: <http://purl.org/dc/elements/1.1/#>.
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix cs: <http://purl.org/vocab/changeset/schema#>.
@prefix eg: <http://example.com/>.
</nowiki>

=== '''Create a resource within a container using POST/PUT''' ===
An HTTP POST to the target container creates a new resource within that container, returning the URI of the new resource. A subsequent PUT to this URI adds content. This approach is useful for clients that cannot use the null relative URI form.

# The client requests an HTTP POST on a URI identifying an LDP Container.
# The server creates a new resource.
# If the creation succeeded, the server answers with 201 Created and the location of the created resource.
# The client requests an HTTP PUT on the new resource URI including the RDF content and appropriate Content-Type.
# The server answers 204 No Content to confirm the PUT.

==Get RDF representation of an information resource (UC-LDPR1-S1)==
In the basic case, the requested resource is an information resource:

# The client requests an HTTP GET on a URI identifying an LDP resource, with an accept header requesting information in the required RDF format.
# The server answers with 200 OK and returns an RDF representation of the resource in the requested format.

Based on [[#Maintaining Social Contact Information|Maintaining Social Contact Information]], a user should be able to read contact details so that they are able to interact with a contact. An LDP holds social contact information about Alice. In this example the contact details make no distinction between resources and the people they describe.
Resource <nowiki>http://example.com/people/Alice</nowiki> delineates the following RDF model. A Request for this resource returns an RDF representation in the desired format which could be Turtle or another RDF serialisation.

<nowiki>
@prefix : <http://example.com/people/>.

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

A data source holds social contact information about Alice and Bob, and the client requests contact details for Alice. In this example the contact details make no distinction between the information resources and the people they describe.

<nowiki>
@prefix : <http://example.com/people/>.

: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>.
</nowiki>

The resource identified by <http://example.com/people/alice> is requested below:

<nowiki>
GET http://example.com/people/alice HTTP/1.1
Host: example.com
Accept: text/turtle
</nowiki>

The response describes Alice, but not Bob :

<nowiki>
HTTP/1.1 200 OK
Content-Type: text/turtle
ETag: W/"123456789"

@prefix : <http://example.com/people/>.

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

==Get RDF description of a non-information resource==

In the case that the URI is unresolvable, the LDP server may redirect the URI to a resolvable LDPR.

# The client requests an HTTP GET on a URI identifying a non-information resource.
# The server answers with 303 See Other, redirecting the client to an LDPR.
# The client requests an HTTP GET on the LDPR, with an accept header requesting information in the required RDF format.
# The server answers with 200 OK and the requested RDF representation.

The data source holds social contact information about Alice and Bob, and the client requests contact details for Alice. The <nowiki>wdrs:describedby</nowiki> relationship introduces a distinction between things and their descriptions.

<nowiki>
@prefix : <http://example.com/people/>.

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

:bob a foaf:Person;
rdfs:label "Bob";
foaf:mbox <mailto:bob@example.com>;
wdrs:describedby :bob.rdf.
</nowiki>

In this case, the <http://example.com/people/alice> resource is redirected to it's descriptive URI, <http://example.com/people/alice.rdf>.

<nowiki>
GET http://example.com/people/alice HTTP/1.1
Host: example.com
Accept: text/turtle
</nowiki>

The first response is the redirection to <http://example.com/people/alice.rdf>.

<nowiki>
HTTP/1.1 303 See Other
Location: http://example.com/people/alice.rdf
</nowiki>

The client requests a GET of the returned location:

<nowiki>
GET http://example.com/people/alice.rdf HTTP/1.1
Host: example.com
Accept: text/turtle
</nowiki>

The response includes information about <http://example.com/people/alice.rdf> ''and anything it describes''.

<nowiki>
HTTP/1.1 200 OK
Content-Type: text/turtle
ETag: W/"123456789"

@prefix : <http://example.com/people/>.

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

== Replace the current resource in full using PUT (UC-LDPR2-S1) ==
A data source holds social contact information about Alice, and the client wishes to update the email contact details for her.

Replace the entire persistent state of the identified resource with the entity representation in the body of the request. The scenario covers a typical sequence of events where the client first GETs the current state prior to the update.

# The client requests an HTTP GET on a URI identifying an LDP Resource, with an accept header requesting information in the required RDF format.
# The server answers with 200 OK and returns the requested representation, describing the resource in the requested format, including the current entity tag.
# The client requests an HTTP PUT on the same URI with RDF representing the updated resource, including an If-Match header with the last known entity tag, and the appropriate Content-Type.
# If no entity tag is supplied in the request, the server should respond with 409 Conflict.
# If the update succeeds, the server responds with 204 No Content.
# Otherwise, the server responds with 412 Precondition Failed.

<nowiki>
@prefix : <http://example.com/people/>.

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

The client performs an initial HTTP GET to establish the current state of the resource.

<nowiki>
GET http://example.com/people/alice HTTP/1.1
Host: example.com
Accept: text/turtle
</nowiki>

As well as the RDF state, the client saves the entity tag.

<nowiki>
HTTP/1.1 200 OK
Content-Type: text/turtle
ETag: W/"123456789"

@prefix : <http://example.com/people/>.

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

The resource identified by <http://example.com/people/alice> is updated below, including the current entity tag:

<nowiki>
PUT http://example.com/people/alice HTTP/1.1
Host: example.com
Content-Type: text/turtle
If-Match: W/"123456789"

@prefix : <http://example.com/people/>.

:alice a foaf:Person;
rdfs:label "Alice";
foaf:mbox <mailto:alice@example.org>.
</nowiki>

The response confirms the update:

<nowiki>
HTTP/1.1 204 No Content
ETag: W/"123456790"
</nowiki>

== Selective update of the resource using PATCH (UC-LDPR2-S2) ==
A data source holds social contact information about Alice, and the client wishes to update the email contact details for her.
The client may perform an HTTP GET to get the current state.

<nowiki>
GET http://example.com/people/alice HTTP/1.1
Host: example.com
</nowiki>

The response describes social contact information about Alice.

<nowiki>
HTTP/1.1 200 OK
ETag: W/"123456789"

@prefix : <http://example.com/people/>.

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

The resource identified by <http://example.com/people/alice> is updated below, including the current entity tag. The PATCH is defined here using a ''changeset''. see <http://docs.api.talis.com/getting-started/changesets>.

<nowiki>
PATCH http://example.com/people/alice HTTP/1.1
Host: example.com
Content-Type: text/turtle
If-Match: W/"123456789"

@prefix : <http://example.com/people/>.

<change1>
a cs:ChangeSet ;
cs:subjectOfChange :alice ;
cs:createdDate "2012-01-01T00:00:00Z" ;
cs:changeReason "Update mbox" ;
cs:removal [
a rdf:Statement ;
rdf:subject :alice ;
rdf:predicate foaf:mbox ;
rdf:object <mailto:alice@example.com> .
] ;
cs:addition [
a rdf:Statement ;
rdf:subject :alice ;
rdf:predicate foaf:mbox ;
rdf:object <mailto:alice@example.org> .
] .
</nowiki>

The response confirms the update, returning the modified resource description.

<nowiki>
HTTP/1.1 204 No Content
ETag: W/"123456790"
</nowiki>
== Retrieve resource entity tag using HEAD (UC-LDPR3-S1) ==
The client requests an HTTP HEAD to establish the current state of the resource.

# The client requests an HTTP HEAD of a URI identifying an LDP Resource.
# The server answers with the current entity tag for the resource, and allowed operations.

<nowiki>
@prefix : <http://example.com/people/>.

:alice a foaf:Person.
</nowiki>

The client requests an HTTP HEAD to establish the current state of the resource.

<nowiki>
HEAD http://example.com/people/alice HTTP/1.1
Host: example.com
</nowiki>

The response includes the entity tag and allowed operations.

<nowiki>
HTTP/1.1 204 No Content
Allow: GET, PUT, POST, HEAD, PATCH, DELETE
ETag: W/"123456789"
</nowiki>

== Conditional GET request (UC-LDPR3-S2)==
The client performs a conditional HTTP GET on a resource using 'If-none-Match'. If the RDF representation hasn't changed the response is a 304 'Not Modified' with no entity body.

# The client requests an HTTP HEAD on a URI identifying an LDP Resource.
# If the resource hasn't changed, the server answers with HTTP response code 304 'Not Modified' and returns the current entity tag for the resource.
# Otherwise, the server returns 200 OK, the RDF representation and current entity tag.

Determine if the contact for Alice has changed.

<nowiki>
@prefix : <http://example.com/people/>.

:alice a foaf:Person.
</nowiki>

The client requests an HTTP GET to determine if it has changed.

<nowiki>
GET http://example.com/people/alice HTTP/1.1
Host: example.com
Accept: text/turtle
If-none-Match: W/"123456789"
</nowiki>

Assuming the resource is unchanged, the response includes the entity tag.

<nowiki>
HTTP/1.1 304 Not Modified
ETag: W/"123456789"
</nowiki>

==Delete resource (UC-LDPR4-S1) ==
The client requests an HTTP DELETE of a resource.

In practice, sensitive data will be subject to access control as described in user-story [[#LDP and Authentication/Authorization| LDP and Authentication/Authorization]]. In this scenario authentication is based on [http://www.w3.org/wiki/WebAccessControl Web Access Control]. The user authenticates to the LDP server using [http://www.w3.org/wiki/Foaf%2Bssl FOAF+SSL], returning a [http://www.w3.org/wiki/WebID WebID] - a URI identifying the user. We assume the LDP holds an RDF Access Control List (ACL) expressed in the [http://www.w3.org/ns/auth/acl Basic Access Control ontology]. This is used to determine whether or not the user is authorized to perform the operation, in this case a deletion (a write operation). In the ACL fragment below the agent identified as <nowiki><http://example.com/card#i></nowiki> is permitted access to delete <nowiki><resourceX></nowiki>.

<nowiki>
@prefix acl: <http://www.w3.org/ns/auth/acl#> .

[acl:accessTo <resourceX>; acl:mode acl:Read, acl:Write; acl:agent <http://example.com/card#i>].
</nowiki>

# The client requests an HTTP DELETE on a URI identifying an LDP Resource.
# If the request includes an 'If-Match' header then compare this entity tag with the current entity tag.
# If the resource is successfully deleted, the server answers 204 No Content, confirming deletion.
# Otherwise answer with 412 Precondition Failed.

As HTTP DELETE is idempotent it is not an error to delete a resource that has already been deleted.

Delete the contact for Alice.

<nowiki>
@prefix : <http://example.com/people/>.

:alice a foaf:Person.
</nowiki>

The client requests an HTTP DELETE.

<nowiki>
DELETE http://example.com/people/alice HTTP/1.1
Host: example.com
</nowiki>

Assuming the resource is successfully deleted, the response includes the entity tag.

<nowiki>
HTTP/1.1 204 No Content
ETag: W/"123456790"
</nowiki>

== Create a new resource using PUT (UC-LDPR5-S1) ==
Create a new resource based on the RDF in the request body using PUT.

# The client requests an HTTP PUT at the target URI with RDF representing the new resource, with the appropriate Content-Type.
# If the creation succeeds, the server responds with 201 Created and the entity tag.
# Otherwise, the server responds with 409 Conflict.

The client wishes to create a new contact for Carol.

The client performs an initial HTTP GET to establish the current state of the resource. We assume that there is no pre-existing resource at the address.

<nowiki>
PUT http://example.com/people/carol HTTP/1.1
Host: example.com
Content-Type: text/turtle

<> a foaf:Person;
rdfs:label "Carol";
foaf:mbox <mailto:carol@example.com>.
</nowiki>

The confirmation includes the entity tag.

<nowiki>
HTTP/1.1 201 Created
ETag: W/"987654321"
</nowiki>

== Create a new resource using PATCH (UC-LDPR5-S2) ==
Create a new resource using PATCH to insert the relevant triples.

# The client requests an HTTP PATCH on the target URI with RDF representing the new resource, and the appropriate Content-Type.
# If the creation succeeds, the server responds with 201 Created and the entity tag.
# Otherwise, the server responds with 409 Conflict.

== List contained resources but not their properties (UC-LDPC1-S1) ==
In this scenario, the server returns references to the full membership of the container in a single request. It is implementation specific whether or not the server returns any additional information about each member.

# The client requests an HTTP GET on a URI identifying an LDP Container. The accept header specifies the required media type for the returned RDF serialization.
# If the size of the container is too large, the LDP may redirect the request to the paginated collection, answering 307 Moved temporarily with the Location header set.
# Otherwise, the server answers with 200 OK and returns the RDF representation in the requested format.

This scenario is based on the user-story [[#Maintaining Social Contact Information]]. The data source holds social contact information in a container called /mycontacts (an information resource).

<nowiki>
@prefix : <http://example.com/people/>.

eg:mycontacts a bp:Container;
rdfs:member
:alice,
:bob.

: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>.
</nowiki>

The user requests information about the container resource.

<nowiki>
GET http://example.com/mycontacts HTTP/1.1
Host: example.com
Accept: text/turtle
</nowiki>

The response should include information about the container and references to contained resources, but not information about them.

<nowiki>
HTTP/1.1 200 OK
Content-Type: text/turtle
ETag: W/"123456790"

@prefix : <http://example.com/people/>.

eg:mycontacts a bp:Container;
rdfs:member
:alice,
:bob.
</nowiki>

==Paginated list of contained resources and their properties (UC-LDPC1-S2)==
In many applications, it is desirable for the client to be able to get full descriptions about multiple members of a container, in a single request. However, if the membership is large, a single representation containing descriptions of all members may be onerously large. Paging allows different subsets of the membership to returned in a sequence of requests.

# The client requests an HTTP GET on a URI identifying an LDP Container, qualified with the requested page (eg. ?firstpage). The accept header specifies the required media type for the returned RDF serialization.
# If an 'If-Match' header is supplied, the entity tag should be compared with the curent container entity tag.
# The members are sorted according to some criteria, and the relevant subset of properties are listed.
# The server answers with 200 OK and returns the RDF representation of the subset in the requested format.
# An opaque URI in the returned representation identifies the next page.

'''Example''': The data source holds social contact information in a container resource called /mycontacts.

<nowiki>
@prefix : <http://example.com/people/>.

eg:mycontacts a bp:Container;
rdfs:member
:alice,
:bob,
:carol.

: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>.

:carol a foaf:Person;
rdfs:label "Carol";
foaf:mbox <mailto:carol@example.com>.
</nowiki>

The user requests the first page of information about the container membership. In this example the page size is 2.

<nowiki>
GET http://example.com/mycontacts?firstPage HTTP/1.1
Host: example.com
Accept: text/turtle
</nowiki>

The response should include information about the container and the relevant subset of the membership and their properties.

<nowiki>
HTTP/1.1 200 OK
Content-Type: text/turtle
ETag: W/"123456790"

@prefix : <http://example.com/people/>.

eg:mycontacts a bp:Container;
rdfs:member
:alice,
:bob.

<> a bp:Page;
bp:pageOf eg:mycontacts;
bp:nextPage eg:mycontacts?p=2.

: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>.
</nowiki>

The follow-up request for the next page may include the container entity tag to ensure consistent pagination.

<nowiki>
GET http://example.com/mycontacts?p=2 HTTP/1.1
Host: example.com
Accept: text/turtle
If-Match: W/"123456790"
</nowiki>

The response includes the remaining contact.

<nowiki>
HTTP/1.1 200 OK
Content-Type: text/turtle
ETag: W/"123456790"

@prefix : <http://example.com/people/>.

eg:mycontacts a bp:Container;
rdfs:member
:carol.

<> a bp:Page;
bp:pageOf eg:mycontacts;
bp:nextPage rdf:nil.

:carol a foaf:Person;
rdfs:label "Carol";
foaf:mbox <mailto:carol@example.com>.
</nowiki>

==Create a resource within a container==
An HTTP POST to the target container, including a representation of the new resource, creates a new resource within that container.

'''Assumptions'''

* The document base URI is the URI of the created resource.

# The client requests an HTTP POST on a URI identifying an LDP Container, including the RDF content with appropriate Content-Type.
# The server creates a new resource with the defined properties and relationships. The resource URI defines the document base of the posted RDF representation.
# If the creation succeeded, the server answers with 201 Created and the location of the created resource.

Assume we have an existing container resource with a defined membership predicate.
<nowiki>
<http://example.com/contacts/> a bp:Container;
bp:membershipPredicate rdfs:member .
</nowiki>

<nowiki>
POST http://example.com/contacts/ HTTP/1.1
Host: example.com
Content-Type: text/turtle

<> a foaf:PersonalProfileDocument;
foaf:primaryTopic <#me> .

<#me> a foaf:Person;
foaf:name "Henry" .
</nowiki>

The response confirms creation of the new resource at the indicated location.

<nowiki>
HTTP/1.1 201 Created
Location: http://example.com/contacts/a0001
ETag: W/"1234567890"
</nowiki>

==Create a container under another container (UC-LDPC2-S2) ==

Helios bugs allow bugs to have sub-issues using the membership predicate <helios_bt:hasSubIssue>. The new member can be identified as a Container.

<nowiki>
POST http://example.com/bugtracker HTTP/1.1
Host: example.com
Content-Type: text/turtle

@prefix helios_bt: <http://heliosplatform.sourceforge.net/ontologies/2010/05/helios_bt.owl#>.

<> rdfs:member [
a helios_bt:BugtrackerIssue, bp:Container;
dc:identifier "58366";
dc:type "bug";
helios_bt:isInBugtracker eg:bugtracker ;

bp:membershipPredicate helios_bt:hasSubIssue .
]
</nowiki>

The response confirms creation of the new resource at the indicated location.

<nowiki>
HTTP/1.1 201 Created
Location: http://example.com/bugtracker/a0002
ETag: W/"1234567891"
</nowiki>

==Retrieve non-member properties of a container (UC-LDPC3-S1)==
In this scenario, the server returns references to the full membership of the container in a single request. It is implementation specific whether or not the server returns any additional information about each member.

# The client requests an HTTP GET on a URI identifying an LDP Container qualified with ?non-member-properties. The accept header specifies the required media type for the returned RDF serialization.
# The server answers with 200 OK and returns the RDF representation in the requested format.

This scenario is based on the user-story [[#Data_catalogs]] and [http://www.w3.org/TR/vocab-dcat/ Data Catalog Vocabulary (DCAT)]. The data source holds catalog information in a container called /mycatalog (a container resource).

<nowiki>
@prefix : <http://example.com/>.

:mycatalog a bp:Container;
bp:membershipSubject :catalog;
bp:membershipPredicate dcat:record.

:catalog a dcat:Catalog ;
dcterms:title "Example catalog" ;
dcat:record :record-001.

:record-001 a dcat:CatalogRecord ;
foaf:primaryTopic :dataset-001 ;
dcterms:issued "2011-12-11"^^xsd:date.

:dataset-001 a dcat:Dataset ;
dcterms:title "Example dataset" .
</nowiki>

The user requests information about the container resource /mycatalog.

<nowiki>
GET http://example.com/mycatalog?non-member-properties HTTP/1.1
Host: example.com
Accept: text/turtle
</nowiki>

The response should include information about the container.

<nowiki>
HTTP/1.1 200 OK
Content-Type: text/turtle
ETag: W/"9999999999"

@prefix : <http://example.com/dcat/>.

:mycatalog a bp:Container;
bp:membershipSubject :catalog;
bp:membershipPredicate dcat:record.

:catalog a dcat:Catalog ;
dcterms:title "Example catalog" .
</nowiki>

==Place an existing resource in a container (UC-LDPC4-S1)==
Add a named resource to a container using HTTP PATCH. There are many reasons why we might wish to add a named resource to a container. The same resource may be added to multiple containers, or we may simply want to create ''sensible'' names for things that people can understand intuitively (rather than a machine generated name) (see [http://www.w3.org/2005/Incubator/lld/wiki/Use_Case_Subject_Search]).

# The client requests an HTTP PATCH on the container (or the resource) including the insertion of an explicit membership relationship between a container membership subject and an existing resource. The request should indicate the appropriate Content-Type.
# The server answers 204 No Content to confirm the patch.

Example: This example is based on [[#Library Linked Data]] use-cases [http://www.w3.org/2005/Incubator/lld/wiki/UseCaseReport LLD-UC], specifically [http://www.w3.org/2005/Incubator/lld/wiki/Use_Case_Subject_Search Subject Search].

<nowiki>
@prefix scheme : <http://example.com/concept-scheme/>.

scheme:subject-heading a skos:ConceptScheme, bp:Container.
</nowiki>

The client wishes to insert a new concept into the scheme.

<nowiki>
PATCH http://example.com/concept-scheme/subject-heading HTTP/1.1
Host: example.com
Content-Type: text/turtle

@prefix : <http://example.com/>.
@prefix scheme : <http://example.com/concept-scheme/>.
@prefix concept : <http://example.com/concept/>.

<change1>
a cs:ChangeSet ;
cs:subjectOfChange scheme:subject-heading ;
cs:createdDate "2012-01-01T00:00:00Z" ;
cs:changeReason "Update concept scheme" ;
cs:addition [
a rdf:Statement ;
rdf:subject concept:Outer+space--Exploration ;
rdf:predicate skos:inScheme ;
rdf:object scheme:subject-heading .
] .
</nowiki>

The response indicates the revised state of the container resource.

<nowiki>
HTTP/1.1 200 OK
ETag: W/"111111111"

@prefix scheme : <http://example.com/concept-scheme/>.
@prefix concept : <http://example.com/concept/>.

scheme:subject-heading a skos:ConceptScheme, bp:Container.

concept:Outer+space--Exploration skos:inScheme scheme:subject-heading.
</nowiki>

== Place resource in more than one container (UC-LDPC4-S2) ==
SNOMED CT allows concepts with more than one parent that don't fall into a lattice.
In the example below, we add the same concept to two different container concepts (via skos:narrowerTransitive).
The example uses skos:narrowerTransitive to elide intervening concepts.

<nowiki>
@prefix concept : <http://example.com/concept/>.

concept:TissueSpecimen a skos:Concept, bp:Container ;
bp:membershipPredicate skos:narrowerTransitive .

concept:SpecimenFromTrunk a skos:Concept, bp:Container ;
bp:membershipPredicate skos:narrowerTransitive .
</nowiki>

We now wish to assert a new concept concept:TissueSpecimenFromHeart which falls under both concepts.

<nowiki>
PATCH http://example.com/concept/TissueSpecimen HTTP/1.1
Host: example.com
Content-Type: text/turtle

@prefix : <http://example.com/>.
@prefix concept : <http://example.com/concept/>.

<change1>
a cs:ChangeSet ;
cs:subjectOfChange concept:TissueSpecimen ;
cs:createdDate "2012-01-01T00:00:00Z" ;
cs:changeReason "Update concept hierarchy" ;
cs:addition [
a rdf:Statement ;
rdf:subject concept:TissueSpecimen ;
rdf:predicate skos:narrowerTransitive ;
rdf:object concept:TissueSpecimenFromHeart .
] ;
cs:addition [
a rdf:Statement ;
rdf:subject concept:TissueSpecimenFromHeart ;
rdf:predicate rdf:type ;
rdf:object skos:Concept .
] ;
</nowiki>

<nowiki>
HTTP/1.1 200 OK
ETag: W/"1234567890"

@prefix concept : <http://example.com/concept/>.

concept:TissueSpecimen a skos:Concept, bp:Container ;
bp:membershipPredicate skos:narrowerTransitive ;
skos:narrowerTransitive concept:TissueSpecimenFromHeart .
</nowiki>

The second container is patched separately.

<nowiki>
PATCH http://example.com/concept/SpecimenFromTrunk HTTP/1.1
Host: example.com
Content-Type: text/turtle

@prefix : <http://example.com/>.
@prefix concept : <http://example.com/concept/>.

<change1>
a cs:ChangeSet ;
cs:subjectOfChange concept:SpecimenFromTrunk ;
cs:createdDate "2012-01-01T00:00:00Z" ;
cs:changeReason "Update concept hierarchy" ;
cs:addition [
a rdf:Statement ;
rdf:subject concept:SpecimenFromTrunk ;
rdf:predicate skos:narrowerTransitive ;
rdf:object concept:TissueSpecimenFromHeart .
] .
</nowiki>

The response confirms the addition.

<nowiki>
HTTP/1.1 200 OK
ETag: W/"1234567891"

@prefix concept : <http://example.com/concept/>.

concept:SpecimenFromTrunk a skos:Concept, bp:Container ;
bp:membershipPredicate skos:narrowerTransitive ;
skos:narrowerTransitive concept:TissueSpecimenFromHeart .
</nowiki>

==Remove a LDPR from a container but not delete it from the system (UC-LDPC4-S3)==
Selectively remove membership properties from a container resource resource.

# The client requests an HTTP GET of a URI identifying an LDP container.
# The server answers with an RDF representation of the container membership and the entity tag.
# The client requests an HTTP PATCH on the container describing the removal of the membership relation between the container and the subordinate resource.
# The server answers 204 No Content to confirm the patch.
An HTTP GET is used to retrieve the initial state of the container.

<nowiki>
GET http://example.com/planets HTTP/1.1
Host: example.com
Accept: text/turtle
</nowiki>

The response lists the container membership and entity tag.

<nowiki>
HTTP/1.1 200 OK
Content-Type: text/turtle
ETag: W/"1234567890"

eg:planets a skos:Collection, bp:Container;
skos:prefLabel "The planets"@en;
skos:member eg:Mercury;
skos:member eg:Venus;
skos:member eg:Earth;
skos:member eg:Mars;
skos:member eg:Jupiter;
skos:member eg:Saturn;
skos:member eg:Uranus;
skos:member eg:Neptune;
skos:member eg:Pluto.
</nowiki>

An HTTP PATCH is used to directly edit membership.

<nowiki>
PATCH http://example.com/planets HTTP/1.1
Host: example.com
Content-Type: text/turtle
If-Match: W/"1234567890"

<change1> a cs:ChangeSet ;
cs:subjectOfChange eg:planets ;
cs:createdDate "2012-01-01T00:00:00Z" ;
cs:changeReason "Pluto is a dwarf planet" ;
cs:removal [
a rdf:Statement ;
rdf:subject eg:planets ;
rdf:predicate skos:member ;
rdf:object eg:Pluto .
] .
</nowiki>

The response confirms the removal.

<nowiki>
HTTP/1.1 200 OK
ETag: W/"1234567891"

eg:planets a skos:Collection, bp:Container;
skos:prefLabel "The planets"@en;
skos:member eg:Mercury;
skos:member eg:Venus;
skos:member eg:Earth;
skos:member eg:Mars;
skos:member eg:Jupiter;
skos:member eg:Saturn;
skos:member eg:Uranus;
skos:member eg:Neptune.
</nowiki>

==Move a LDPC under another LDPC (UC-LDPC4-S4)==

This example is based on [http://www.w3.org/TR/skos-primer/ The SKOS Primer].
Assume we already have the following SKOS concepts. In this example, the concepts mammals, animals and cats are all defined as containers.

<nowiki>
@prefix concept : <http://example.com/concept/>.

concept:animals a skos:Concept, bp:Container ;
bp:membershipPredicate skos:narrower .

concept:mammals a skos:Concept, bp:Container ;
bp:membershipPredicate skos:narrower ;
skos:narrower concept:cats .

concept:cats a skos:Concept, bp:Container ;
bp:membershipPredicate skos:narrower ;
skos:broader concept:mammals .

</nowiki>

We now wish to assert the concept hierarchy; the missing relationship between animals and mammals.

<nowiki>
PATCH http://example.com/concept/animals HTTP/1.1
Host: example.com
Content-Type: text/turtle

@prefix : <http://example.com/>.
@prefix concept : <http://example.com/concept/>.

<change1>
a cs:ChangeSet ;
cs:subjectOfChange concept:animals ;
cs:createdDate "2012-01-01T00:00:00Z" ;
cs:changeReason "Update concept scheme" ;
cs:addition [
a rdf:Statement ;
rdf:subject concept:animals ;
rdf:predicate skos:narrower ;
rdf:object concept:mammals .
] ;
cs:addition [
a rdf:Statement ;
rdf:subject concept:mammals ;
rdf:predicate skos:broader ;
rdf:object concept:animals .
] ;
</nowiki>

The response confirms the addition.

<nowiki>
HTTP/1.1 200 OK
ETag: W/"1234567891"

@prefix concept : <http://example.com/concept/>.

concept:animals a skos:Concept, bp:Container ;
bp:membershipPredicate skos:narrower ;
skos:narrower concept:mammals.

concept:mammals skos:broader concept:animals .
</nowiki>

==Selective update (UC-LDPC5-S1)==
Selectively add and remove properties to and from the identified resource. The scenario covers a typical sequence of events where the client first GETs the current state prior to the update.

# The client requests an HTTP GET of a URI identifying an LDP resource.
# The server answers with an RDF representation of the resource and the entity tag.
# The client requests an HTTP PATCH describing the updates.
# The server answers 204 No Content to confirm the patch.

This example relates to user-story [http://www.w3.org/2012/ldp/wiki/Use_Cases_And_Requirements#Hosting_POSTed_Resources Hosting posted resources],
and is based on [http://heliosplatform.sourceforge.net/ontologies/helios_bt.html Helios].

<nowiki>
GET http://example.com/mycatalog?non-member-properties HTTP/1.1
Host: example.com
Accept: text/turtle
</nowiki>

<nowiki>
HTTP/1.1 200 OK
Content-Type: text/turtle
ETag: W/"9999999999"

@prefix : <http://example.com/dcat/>.

:mycatalog a bp:Container;
bp:membershipSubject :catalog;
bp:membershipPredicate dcat:record.

:catalog a dcat:Catalog ;
dcterms:title "Example catalog" .
</nowiki>

The new publisher information is added to the catalog with HTTP PATCH. This example uses a Talis changeset.

<nowiki>
PATCH http://example.com/mycatalog?non-member-properties HTTP/1.1
Host: example.com
Content-Type: text/turtle
If-Match: W/"9999999999"

@prefix : <http://example.com/>.

<change1>
a cs:ChangeSet ;
cs:subjectOfChange :catalog ;
cs:createdDate "2012-01-01T00:00:00Z" ;
cs:changeReason "Update catalog metadata" ;
cs:addition [
a rdf:Statement ;
rdf:subject : catalog ;
rdf:predicate dcterms:publisher ;
rdf:object <http://example.com/people/alice> .
] .
</nowiki>

The response confirms successful update of the container resource.

<nowiki>
HTTP/1.1 200 OK
ETag: W/"10000000000"

@prefix : <http://example.com/>.

:mycatalog a bp:Container;
bp:membershipSubject :catalog;
bp:membershipPredicate dcat:record.

:catalog a dcat:Catalog ;
dcterms:title "Example catalog" ;
dcterms:publisher <http://example.com/people/alice>.
</nowiki>

==substituting update ==
# The client requests an HTTP GET of a URI identifying an LDP container non-membership properties.
# The server answers with an RDF representation of the container and the entity tag.
# The client requests an HTTP PUT with a replacement description and the appropriate Content-Type.
# The server answers 204 No Content to confirm the patch.

This example relates to user-story [http://www.w3.org/2012/ldp/wiki/Use_Cases_And_Requirements#Hosting_POSTed_Resources Hosting posted resources],
and is based on [http://heliosplatform.sourceforge.net/ontologies/helios_bt.html Helios].

<nowiki>
@prefix : <http://example.com/>.

:mycatalog a bp:Container;
bp:membershipSubject :catalog;
bp:membershipPredicate dcat:record.

:catalog a dcat:Catalog ;
dcterms:title "Example catalog" ;
dcat:record :record-001.

:record-001 a dcat:CatalogRecord ;
foaf:primaryTopic :dataset-001 ;
dcterms:issued "2011-12-11"^^xsd:date.

:dataset-001 a dcat:Dataset ;
dcterms:title "Example dataset" .
</nowiki>

The initial state of the non-membership properties of a container are retrieved.

<nowiki>
GET http://example.com/mycatalog?non-member-properties HTTP/1.1
Host: example.com
Accept: text/turtle
</nowiki>

<nowiki>
HTTP/1.1 200 OK
Content-Type: text/turtle
ETag: W/"9999999999"

@prefix : <http://example.com/dcat/>.

:mycatalog a bp:Container;
bp:membershipSubject :catalog;
bp:membershipPredicate dcat:record.

:catalog a dcat:Catalog ;
dcterms:title "Example catalog" .
</nowiki>

The non-membership properties of a container may be substituted with HTTP PUT.This enables us to add a publisher to the catalog.

<nowiki>
PUT http://example.com/people/alice HTTP/1.1
Host: example.com
Content-Type: text/turtle
If-Match: W/"9999999999"

@prefix : <http://example.com/dcat/>.

:mycatalog a bp:Container;
bp:membershipSubject :catalog;
bp:membershipPredicate dcat:record.

:catalog a dcat:Catalog ;
dcterms:title "Example catalog" ;
dcterms:publisher <http://example.com/people/alice>.
</nowiki>

The response confirms successful update of the container resource.

<nowiki>
HTTP/1.1 204 No Content
ETag: W/"10000000000"
</nowiki>
==Requirements==
===TBD: Which of these follow from the use-cases?===
# Update resources, either RDF-based or not
# Use optimistic collision detection on updates
# Apply minimal constraints for creation and update
# Remove a resource, including any associations with a container
# Get members of a container
# Get just data about a container, without all the members
# Handle a large number of members of a container, breaking up representation into pages

===TBD: Which of these follow from use-cases?===
# Define a minimal set of RDF media-types/representations
# Define a limited number of literal value types
# Use standard vocabularies as appropriate
# Ensure clients are ready for resource format and type changes
# When getting members of a container, provide data about the members
# Allow pages to have order information for members, within a page and across all pages

Use Cases And Requirements

Sbattle2 — Mon, 10 Dec 2012 11:15:10 GMT

Sbattle2: /* Constrained Devices and Networks */

= Linked Data Platform Use Cases And Requirements =

This is a working document used to collect use cases and requirements for consideration by the WG.
The starting point comes from [http://www.w3.org/Submission/2012/SUBM-ldbpucr-20120326/ Linked Data Basic Profile Use Cases and Requirements].

== Steps to Complete ==

* <strike>Nov 26? WG to confirm User Story content: add, remove, refine (see process below). Note: this is ONLY User Stories (not Use Cases, Use Case Scenarios or Requirements)</strike>
** Issues before Nov 26th? will be included into FPWD
* Editors to:
** <strike>Dec 3 refine User Stories based on feedback</strike>
** <strike>Dec 5 elaborate on Use Cases in support of User Stories</strike>
* Dec 10 - WG to review prior to FPWD
** Review period ends Dec 15th
** insert open issues into draft for FPWD
* Dec 17 - Publish FPWD
** convert wiki page to ReSpec for FPWD
* Dec ?? Deadline for publications by year end 2012

===To Be Done===
* <strike>Move [[#LDP_and_Authentication.2FAuthorization| LDP and Authentication]] to [http://www.w3.org/2012/ldp/wiki/AccessControl AccessControl]</strike>
* <strike>Complete [[#Alternative_scenario:_moving_contained_resources| moving contained resources]] scenario with content from ericP on issue-30.</strike>
* Augment [[#Cloud_Infrastructure_Management| Cloud Infrastructure Management]] scenario with content from Roger Menday.
* <strike>Ensure issue-40/41 are fully covered in [[#UC8:_Managing_non-RDF_Resources| UC8: Managing non-RDF Resources]]. 2 scenarios (single v multiple attachments) ?</strike>
* <strike>Contact owner of [[#Data_Sharing| Data Sharing]] user-story to determine if we keep or not.</strike>
* Review [[#Requirements| Requirements]] section for functional/non-functional requirements arising in UCs.
* <strike>Propose resolutions to open issues against UC&R where possible.</strike>
* <strike>Identify and acknowledge user-story contributors.</strike>
* Check hyperlinks
* Convert to ReSpec
* Annotate document with open issues against UC&R
** [http://www.w3.org/2012/ldp/track/issues/30 ISSUE-30] (OPEN)
** [http://www.w3.org/2012/ldp/track/issues/40 ISSUE-40] (RAISED)
** [http://www.w3.org/2012/ldp/track/issues/41 ISSUE-41] (RAISED)

=== Process to introduce new User Stories & Use Cases ===

Open an Issue in the tracker against the UC&R product. The WG will review these and decide whether they are valid.

== Scope and Motivation ==

Linked Data was defined by Tim Berners-Lee with the following guidelines [http://www.w3.org/DesignIssues/LinkedData.html]:

# Use URIs as names for things
# Use HTTP URIs so that people can look up those names
# When someone looks up a URI, provide useful information, using the standards (RDF*, SPARQL)
# Include links to other URIs. so that they can discover more things

These four rules have proven very effective in guiding and inspiring people to publish Linked Data on the web. The amount of data, especially public data, available on the web has grown rapidly, and an impressive number of extremely creative and useful “mashups” have been created using this data as result.

There has been much less focus on the potential of Linked Data as a model for managing data on the web - the majority of the Application Programming Interfaces (APIs) available on the Internet for creating and updating data follow a Remote Procedure Call (RPC) model rather than a Linked Data model.

If Linked Data were just another model for doing something that RPC models can already do, it would be of only marginal interest. Interest in Linked Data arises from the fact that applications with an interface defined using Linked Data can be much more easily and seamlessly integrated with each other than applications that offer an RPC interface. In many problem domains, the most important problems and the greatest value are found not in the implementation of new applications, but in the successful integration of multiple applications into larger systems.

Some of the features that make Linked Data exceptionally well suited for integration include:

* A single interface – defined by a common set of HTTP methods – that is universally understood and is constant across all applications. This is in contrast with the RPC architecture where each application has a unique interface that has to be learned and coded to.
* A universal addressing scheme – provided by HTTP URLs – for both identifying and accessing all “entities”. This is in contrast with the RPC architecture where there is no uniform way to either identify or access data.
* A simple yet extensible data model – provided by RDF – for describing data about a resource in a way which doesn’t require prior knowledge of vocabulary being used.

Experience implementing applications and integrating them using Linked Data has shown very promising results, but has also demonstrated that the original four rules defined by Tim Berners-Lee for Linked Data are not sufficient to guide and constrain a writable Linked Data API. As was the case with the original four rules, the need generally is not for the invention of fundamental new technologies, but rather for a series of additional rules and patterns that guide and constrain the use of existing technologies in the construction of a Basic Profile for Linked Data to achieve interoperability.

The following list illustrates a few of the issues that require additional rules and patterns:
* What URLs do I post to in order to create new resources?
* How do I get lists of existing resources, and how do I get basic information about them without having to access each one?
* How should I detect and deal with race conditions on write?
* What media-types/representations should I use?
* What standard vocabularies should I use?
* What primitive data types should I use?

A good goal for the Basic Profile for Linked Data would be to define a specification required to allow the definition of a writable Linked Data API equivalent to the simple application APIs that are often written on the web today using the Atom Publishing Protocol (APP). APP shares some characteristics with Linked Data, such as the use of HTTP and URLs. One difference is that Linked Data relies on a flexible data model with RDF, which allows for multiple representations.

== Organization of this Document ==

This document is organized as follows:

* '''[[#User Stories| User Stories]]''' capture statements about system requirements written from a user or application perspective. They are typically lightweight and informal and can run from one line to a paragraph or two (sometimes described as an 'epic') [http://www.agilemodeling.com/artifacts/userStory.htm]. Analysis of each user story will reveal a number of (functional) use-cases and other non-functional requirements. See [http://www.w3.org/TR/dap-policy-reqs/| Device API Access Control Use Cases and Requirements] for a good example of user stories and their analysis.

* '''[[#Use Cases| Use Cases]]''' are used to capture and model functional requirements. Use cases describe the system’s behavior under various conditions [http://alistair.cockburn.us/get/2465], cataloguing who does what with the system, for what purpose, but without concern for system design or implementation [http://www.bredemeyer.com/pdf_files/functreq.pdf]. Each use case is identified by a reference number to aid cross-reference from other documentation; use-case indexing in this document is based on [http://www.w3.org/TR/rdb2rdf-ucr/ rdb2rdf use-cases]. A variety of styles may be used to capture use-cases, from a simple narrative to a structured description with actors, pre/post conditions, and step-by-step behaviours as in [http://www.w3.org/TR/powder-use-cases/ POWDER: Use Cases and Requirements], and non-functional requirements raised by the use-case. Use cases act like the hub of a wheel, with spokes supporting requirements analysis, scenario-based evaluation, testing, and integration with non-functional, or quality requirements.

* '''Scenarios''' are more focused still, representing a single instance of a use case in action. Scenarios may range from lightweight narratives as seen in [http://www.w3.org/TR/media-frags-reqs/ Use cases and requirements for Media Fragments], to being formally modeled as interaction diagrams. Each use-case should include at least a primary scenario, and possibly other alternative scenarios.

* '''[[#Requirements| Requirements]]''' list non-functional or quality requirements, and the use cases they may be derived from. This approach is exemplified in the [http://dvcs.w3.org/hg/gld/raw-file/default/dcat-ucr/index.html Use Cases and Requirements for the Data Catalog Vocabulary].

== User Stories ==

=== Maintaining Social Contact Information ===

Many of us have multiple email accounts that include information about the people and organizations we interact with – names, email addresses, telephone numbers, instant messenger identities and so on. When someone’s email address or telephone number changes (or they acquire a new one), our lives would be much simpler if we could update that information in one spot and all copies of it would automatically be updated. In other words, those copies would all be linked to some definition of “the contact.” There might also be good reasons (like off-line email addressing) to maintain a local copy of the contact, but ideally any copies would still be linked to some central “master.”

Agreeing on a format for “the contact” is not enough, however. Even if all our email providers agreed on the format of a contact, we would still need to use each provider’s custom interface to update or replace the provider’s copy, or we would have to agree on a way for each email provider to link to the “master”. If we look outside our own personal interests, it would be even more useful if the person or organization exposed their own contact information so we could link to it.

What would work in either case is a common understanding of the resource, a few formats needed, and access guidance for these resources. This would support how to acquire a link to a contact, and how to use those links to interact with a contact (including [[#UC3: Retrieve resource description|reading]], [[#UC4: Update existing resource|updating]], and [[#Alternative scenario: delete resource|deleting]] it), as well as how to easily [[#Primary scenario: create resource|create a new contact]] and add it to my contacts and when deleting a contact, how it would be removed from my list of contacts. It would also be good to be able to add some application-specific data about my contacts that the original design didn’t consider. Ideally we’d like to eliminate multiple copies of contacts, there would be additional valuable information about my contacts that may be stored on separate servers and need a simple way to link this information back to the contacts. Regardless of whether a contact collection is my own, shared by an organization, or all contacts known to an email provider (or to a single email account at an email provider), it would be nice if they all worked pretty much the same way.

=== Keeping Track of Personal and Business Relationships ===

In our daily lives, we deal with many different organizations in many different relationships, and they each have data about us. However, it is unlikely that any one organization has all the information about us. Each of them typically gives us access to the information (at least some of it), many through websites where we are uniquely identified by some string – an account number, user ID, and so on. We have to use their applications to interact with the data about us, however, and we have to use their identifier(s) for us. If we want to build any semblance of a holistic picture of ourselves (more accurately, collect all the data about us that they externalize), we as humans must use their custom applications to find the data, copy it, and organize it to suit our needs.

Would it not be simpler if at least the Web-addressable portion of that data could be linked to consistently, so that instead of maintaining various identifiers in different formats and instead of having to manually supply those identifiers to each one’s corresponding custom application, we could essentially build a set of bookmarks to it all? When we want to [[#UC3: Retrieve resource description|examine]] or [[#UC4: Update existing resource|change]] their contents, would it not be simpler if there were a single consistent application interface that they all supported? Of course it would.

Our set of links would probably be a [[#UC6: Aggregate resources|simple collection]]. The information held by any single organization might be a mix of simple data and [[#UC6: Aggregate resources|collections of other data]], for example, a bank account balance and a collection of historical transactions. Our bank might easily have [[#Alternative scenario: create a nested container|a collection of accounts for each of its collection of customers]].

=== System and Software Development Tool Integration ===

System and software development tools typically come from a diverse set of vendors and are built on various architectures and technologies. These tools are purpose built to meet the needs for a specific domain scenario (modeling, design, requirements and so on.) Often tool vendors view integrations with other tools as a necessary evil rather than providing additional value to their end-users. Even more of an afterthought is how these tools’ data -- such as people, projects, customer-reported problems and needs -- integrate and relate to corporate and external applications that manage data such as customers, business priorities and market trends. The problem can be isolated by standardizing on a small set of tools or a set of tools from a single vendor, but this rarely occurs and if does it usually does so only within small organizations. As these organizations grow both in size and complexity, they have needs to work with outsourced development and diverse internal other organizations with their own set of tools and processes. There is a need for better support of more complete business processes (system and software development processes) that span the roles, tasks, and data addressed by multiple tools. This demand has existed for many years, and the tools vendor industry has tried several different architectural approaches to address the problem. Here are a few:

* Implement an API for each application, and then, in each application, implement “glue code” that exploits the APIs of other applications to link them together.
* Design a single database to store the data of multiple applications, and implement each of the applications against this database. In the software development tools business, these databases are often called “repositories.”
* Implement a central “hub” or “bus” that orchestrates the broader business process by exploiting the APIs described previously.

It is fair to say that although each of those approaches has its adherents and can point to some successes, none of them is wholly satisfactory. The use of Linked Data as an application integration technology has a strong appeal. [http://open-services.net/ OSLC]

=== Library Linked Data ===

The W3C Library Linked Data working group has a number of use cases cited in their Use Case Report. [http://www.w3.org/2005/Incubator/lld/wiki/UseCaseReport LLD-UC] These referenced use cases focus on the need to extract and correlate library data from disparate sources. Variants of these use cases that can provide consistent formats, as well as ways to improve or update the data, would enable simplified methods for both efficiently sharing this data as well as producing incremental updates without the need for repeated full extractions and import of data.

The 'Digital Objects Cluster' contains a number of relevant use-cases:

* Grouping: This should "Allow the end-users to define [[#UC6: Aggregate resources|groups of resources]] on the web that for some reason belong together. The relationship that exists between the resources is often left unspecified. Some of the resources in a group may not be under control of the institution that defines the groups."

* Enrichment: "Enable end-users to [[#UC4: Update existing resource|link resources together]]."

* Browsing: "[[#UC7: Filter resource description|Support end-user browsing through groups]] and resources that belong to the groups."

* Re-use: "Users should have the capability to re-use all or parts of a collection, with all or part of its metadata, elsewhere on the linked Web."

The 'Collections' cluster also contains a number of relevant use-cases:

* Collection-level description: "Provide [[#UC7: Filter resource description|metadata pertaining to a collection as a whole]], in contrast to item-level description."

* Collections discovery: "Enable innovative collection discovery such as identification of nearest location of a physical collection where a specific information resource is found or mobile device applications ... based on collection-level descriptions."

* Community information services: Identify and classify collections of special interest to the community.

=== Municipality Operational Monitoring ===

Across various cities, towns, counties, and various municipalities there is a growing number of services managed and run by municipalities that produce and consume a vast amount of information. This information is used to help monitor services, predict problems, and handle logistics. In order to effectively and efficiently collect, produce, and analyze all this data, a fundamental set of loosely coupled standard data sources are needed. A simple, low-cost way to [[#UC3: Retrieve resource description|expose data]] from the diverse set of monitored services is needed, one that can easily integrate into the municipalities of other systems that inspect and analyze the data. All these services have links and dependencies on other data and services, so having a simple and scalable linking model is key.

=== Healthcare ===

For physicians to analyze, diagnose, and propose treatment for patients requires a vast amount of complex, changing and growing knowledge. This knowledge needs to come from a number of sources, including physicians’ own subject knowledge, consultation with their network of other healthcare professionals, public health sources, food and drug regulators, and other repositories of medical research and recommendations.

To diagnose a patient’s condition requires current data on the patient’s medications and medical history. In addition, recent pharmaceutical advisories about these medications are linked into the patient’s data. If the patient experiences adverse affects from medications, these physicians need to publish information about this to an appropriate regulatory source. Other medical professionals require access to both validated and emerging effects of the medication. Similarly, if there are geographical patterns around outbreaks that allow both the awareness of new symptoms and treatments, this information needs to quickly reach a very distributed and diverse set of medical information systems. Also, reporting back to these regulatory agencies regarding new occurrences of an outbreak, including additional details of symptoms and causes, is critical in producing the most effective treatment for future incidents.

=== Metadata Enrichment in Broadcasting ===

There are many different use cases when broadcasters show interest in metadata [[#UC4: Update existing resource| enrichment]]:

* enrich archive or news metadata by linking facts, events, locations and personalities
* enrich metadata generated by automatic extraction tools such as person identification, etc.
* enrich definitions of terms in classification schemes or enumeration lists

This comes in support of more effective information management and data/content mining (if you can't find your content, it' like if you don't have and must either recreate or acquire it again, which is not financially effective).

However, there is a need for solutions facilitating linkage to other data sources and taking care of the issues such as discovery, automation, disambiguation. Etc. Other important issues that broadcasters would face are the editorial quality of the linked data, its persistence, and usage rights.

=== Aggregation and Mashups of Infrastructure Data ===

For infrastructure management (such as storage systems, virtual machine environments, and similar IaaS and PaaS concepts), it is important to provide an environment in which information from different sources can be [[#UC6: Aggregate resources|aggregated]], [[#UC7: Filter resource description|filtered]], and visualized effectively. Specifically, the following use cases need to be taken into account:

* While some data sources are based on Linked Data, others are not, and aggregation and mashups must work across these different sources.
* Consumers of the data sources and aggregated/filtered data streams are not necessarily implementing Linked Data themselves, they may be off-the-shelf components such as dashboard frameworks for composing visualizations.
* Simple versions of this scenario are pull-based, where the data is requested from data sources. In more advanced settings, without a major change in architecture it should be possible to move to a push-based interaction model, where data sources push notifications to subscribers, and data sources provide different services that consumers can subscribe to (such as "informational messages" or "critical alerts only").

In this scenario, the important factors are to have abstractions that allow easy aggregation and filtering, are independent from the internal data model of the sources that are being combined, and can be used for pull-based interactions as well as for push-based interactions.

=== Sharing payload of RDF data among low-end devices ===

Several projects around the idea of [http://worldwidesemanticweb.wordpress.com/ downscaling the Semantic Web] need to be able to ship payloads of RDF across the nodes member of a given network. The transfers are done in a constrained context in terms of bandwidth, scope of the local semantics employed by the nodes and computing capabilities of the nodes. In a P2P style, every node has the capability to act either as a data consumer or a data provider, serving its own data or acting as a relay to pass other's data along (typically in mesh networks).

The transfer of an arbitrary payload of RDF data could be implemented through the container mechanism, adding and removing sets of RDF triples to it. Currently, one of the project "SemanticXO" uses named graphs and the graph protocol to create/delete/copy graphs across the nodes but this (almost) imposes the usage of a triple store. Unfortunately, triple store are rather demanding piece of software that are not always usable on limited hardware. Some generic ReST like interaction backed up with a lightweight column store would be better approach.

=== Sharing Binary Resources and Metadata ===

When publishing datasets about stars one may want to publish links to the pictures in which those stars appear, and this may well require publishing the pictures themselves. Vice versa: when publishing a picture of space we need to know which telescope took the picture, which part of the sky it was pointing at, what filters were used, which identified stars are visible, who can read it, who can write to it, ...

If LinkedData contains information about resources that are most naturally expressed in non-rdf formats (be they binary such as pictures or videos, or human readable documents in XML formats), those non RDF formats should be just as easy to publish to the LinkedData server as the RDF relations that link those resources up. A LinkedData server should therefore allow publishing of non linked data resources too, and make it easy to publish and edit metadata about those resources.

The resource comes in two parts - the image and information about the image (which may in the image file but better external to it as it's more general). The information about the image is vital. It's a compound item of image data and other data (being application metadata about the image does not distinguish from the platform's point-of-view.

=== Data Catalogs ===

The Asset Description Metadata Schema ([http://joinup.ec.europa.eu/asset/adms/home ADMS]) provides the data model to describe semantic assets repositories contents, but this leaves many open challenges when building a federation of these repositories to serve the need of assets reuse. These include accessing and querying individual repositories and efficiently retrieving [[#UC5: Determine if a resource has changed| updated content]] without having to retrieve the whole content. Hence, we chose to build the integration solution capitalizing on the Data Warehousing integration approach. This allows us to cope with heterogeneity of sources technologies and to benefit from the optimized performance it offers, given that individual repositories do not usually change frequently. With Data Warehousing, the federation requires to:

* understand the data, i.e. understand their semantic descriptions, and other systems.
* seamlessly exchange the semantic assets metadata from different repositories
* keep itself up-to-date.

Repositories owners can maintain de-referenceable URIs for their repository description and contained assets in a Linked Data compatible manner. ADMS provides the necessary data model to enable meaningful exchange of data. However, This leaves the challenge of efficient access to the data not fully addressed.

Related: [http://spec.datacatalogs.org/ Data Catalog Schema and Protocol]

=== Constrained Devices and Networks ===

Information coming from resource constrained devices in the Web of Things ([http://en.wikipedia.org/wiki/Web_of_Things WoT]) has been identified as a major driver in many domains, from smart cities to environmental monitoring to real-time tracking. The amount of information produced by these devices is growing exponentially and needs to be accessed and integrated in a systematic, standardized and cost efficient way. By using the same standards as on the Web, integration with applications will be simplified and higher-level interactions among resource constrained devices, abstracting away heterogeneities, will become possible. Up-coming IoT/WoT standards such as [http://datatracker.ietf.org/wg/6lowpan/ 6LowPAN] - IPv6 for resource constrained devices - and the Constrained Application Protocol ([http://tools.ietf.org/html/draft-ietf-core-coap CoAP]), which provides a downscaled version of HTTP on top of UDP for the use on constrained devices, are already at a mature stage. The next step now is to support RESTful interfaces also on resource constrained devices, adhering to the Linked Data principles. Due to the limited resources available, both on the device and in the network (such as bandwidth, energy, memory) a solution based on SPARQL Update is at the current point in time considered not to be useful and/or feasible. An approach based on the [http://tools.ietf.org/html/draft-castellani-core-http-mapping HTTP-CoAP Mapping] would enable constrained devices to directly participate in a Linked Data-based environment.

=== Services Supporting the Process of Science ===
Many fields of science now include branches with in silico data-intensive methods, e.g. bioinformatics, astronomy. To support these new methods we look to move beyond the established platforms provided by scientific workflow systems to capture, assist, and preserve the complete lifecycle from record of the experiment, through local trusted sharing, analysis, dissemination (including publishing of experimental data "beyond the PDF"), and re-use.

* [[#UC6: Aggregate resources|Aggregations]], specifically ''Research Objects (ROs)'' that are exchanged between services and clients bringing together workflows, data sets, annotations, and provenance. We use an RDF model for this. While some aggregated contents are encoded using RDF and in increasing number are linked data sources, others are not; while some are stored locally "within" the RO, others are remote (in both cases this is often due to size of the resources or access policies).
* Services that are distributed and linked. Some may be centralising for e.g. publication, others may be local, e.g. per lab. We need lightweight services that can be simply and easily integrated into and scale across the wide variety of softwares and data used in science: we have adopted a RESTful approach where possible.
** Foundation services that collect and expose ROs for storage, modification, exploration, and reuse.
** Services that provide added-value to ROs such as seamless import/export from scientific workflow systems, automated stability evaluation, or recommendation (and therefore interact with the foundation services to retrieve/store/modify/ROs).

seeAlso: [http://www.wf4ever-project.org/ Wf4Ever]

=== Project Membership Information : Information Evolution ===

Information about people and projects changes as roles change, as organisations change
and as contact details change. Finding the current state of a project is important
in enabling people to contact the right person in the right role. It can also be
useful to look back and see who was performing what role in the past.

A use of a Linked Data Platform could be to give responsibility for managing
such information with the project team itself, not requiring updates to be
requested of a centralised website administrator.

This could be achieved with:

* Resource descriptions for each person and project
* A container resource to describe roles/membership in the project.

To retain the history of the project, the old version of a resources,
including container resources, should be retained so there is a need to address both specific items
and also have a notion of "current".

Access to information has two aspects:
* Access to the "current" state, regardless of the version of the resource description
* Access to historical state, via access to a specific version of the resource description

=== Cloud Infrastructure Management===

Cloud operators offer API support to provide customers with remote access for infrastructure management. Infrastructure consists of Systems, Computers, Networks, Discs, etc, and the overall structure can be seen as mostly hierarchical, (Cloud contains Systems, Systems contain Machines, etc). This is complemented with crossing links (e.g. Machines connected to a Network). The IaaS scenario also makes requirements for lifecycle management, non-instant changes and history capture. Infrastructure management can be seen as the manipulation of the underlying graph.

== Use Cases ==
The following use-cases are each derived from one or more of the user-stories above. These use-cases are explored in detail through the development of scenarios, each motivated by some key aspect exemplified by a single user-story. The examples they contain are included purely for illustrative purposes, and should not be interpreted normatively.

===UC1: Manage containers===
A number of user-stories introduce the idea of a ''container'' as a mechanism for creating and managing resources within the context of an application. Resources grouped together within the same container would typically belong to the same application. A container is identified by a URI so is a resource in its own right.
The properties of a container may also represent the ''affordances'' of that container, enabling clients to determine what other operations they can do on that container. These operations may include descriptions of application specific services that can be invoked by exchanging RDF documents.

* Provide "access guidance for ... resources" (affordances) (from user-story, [[#Maintaining Social Contact Information|Maintaining Social Contact Information]]).

====Primary scenario: create container====
Create a new container resource within the LDP server.
In [[#Services Supporting the Process of Science|Services supporting the process of science]], [http://wf4ever.github.com/ro-primer/ Research Objects] are semantically rich aggregations of resources that bring together data, methods and people in scientific investigations. A basic workflow research object will be created to aggegate [http://ceur-ws.org/Vol-903/paper-01.pdf scientific workflows] and the artefacts that result from this workflow. The research object begins life as an empty container into which workflows, datasets, results and other data will be added throughout the lifecycle of the project.

<nowiki>
@prefix ro: http://purl.org/wf4ever/ro#
@prefix dct: http://purl.org/dc/terms/
@prefix ore: http://www.openarchives.org/ore/

<> a ro:ResearchObject, ore:Aggregation ;
dct:created "2012-12-01"^^xsd:dateTime .
</nowiki>

====Alternative scenario: create a nested container====
The motivation for nested containers comes from the [[#System and Software Development Tool Integration| System and Software Development Tool Integration]] user-story. The OSLC Change Management vocabulary allows bug reports to have attachments referenced by the membership predicate <nowiki>oslc_cm:attachment</nowiki>. The 'top-level-container' contains issues, and each issue resource has its own container of attachment resources.

<nowiki>
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix oslc_cm: <http://open-services.net/ns/cm#>.
@prefix : <http://example.org/>.

:top-level-container rdfs:member :issue1234 .

:issue1234 a oslc_cm:ChangeRequest;
dcterms:identifier "1234";
dcterms:type "a bug";
dcterms:related :issue1235 ;
oslc_cm:attachments :attachments123.

:issue1235 a oslc_cm:ChangeRequest;
dcterms:title "a related bug".

:attachments a oslc_cm:AttachmentList;
oslc_cm:attachment :attachment324, :attachment251.
</nowiki>

===UC2: Manage resources===
This use-case addresses the managed lifecycle of a resource and is concerned with resource ''ownership''. The responsibility for managing resources belongs with their container.
For example, a container may accept a request from a client to make a new resource.
This use-case focuses on creation and deletion of resources in the context of a container, and the potential for transfer of ownership by moving resources between containers.
The ownership of a resource should always be clear; no resource managed in this way should ever be owned by more than one container.

Once a new resource has been created it should be identified by a URI. Clients may defer responsibility for establishing dereferenceable URIs to the container of their data.
The container is a natural choice for the endpoint for this interface as it will already have some application-specific knowledge about the contained resources.
While the LDP has ultimate control over resource naming, some applications may require more control over naming, perhaps to provide a more human-readable URI. An LDP server could support something like the [http://tools.ietf.org/html/rfc5023 Atom Publishing Protocol] slug header to convey a user defined naming 'hint'.

* Non-duplication of resources: "Eliminate multiple copies", representing resources in a single place (from [[#Maintaining Social Contact Information]]).
* Distribution of resources: Linked aata "may be stored on separate servers" (from [[#Maintaining Social Contact Information]]).
* Consistent, global naming: Resources should be "linked to consistently, ... instead of maintaining various identifiers in different formats" (from [[#Keeping Track of Personal and Business Relationships]]).

====Primary scenario: create resource====
Resources begin life by being created within a container. From user-story, [[#Maintaining Social Contact Information|Maintaining Social Contact Information]], It should be possible to "easily create a new contact and add it to my contacts." This suggests that resource creation is closely linked to the application context. The new resource is created in a container representing "my contacts." The lifecycle of the resource is linked to the lifecycle of it's container. So, for example, if "my contacts" is deleted then a user would also reasonably expect that all contacts within it would also be deleted.

Contact details are captured as an RDF description and it's properties, including "names, email addresses, telephone numbers, instant messenger identities and so on." The description may include non-standard RDF; "data about my contacts that the original design didn’t consider."
The following RDF could be used to describe contact information using the [http://www.foaf-project.org FOAF] vocabulary. A contact is represented here by a <nowiki>foaf:PersonalProfileDocument</nowiki> defining a resource that can be created and updated as a single-unit, even though it may describe ancillary resources, such as a <nowiki>foaf:Person</nowiki>, below.

<nowiki>
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

<> a foaf:PersonalProfileDocument;
foaf:PrimaryTopic [
a foaf:Person;
foaf:name "Timothy Berners-Lee";
foaf:title "Sir";
foaf:firstName "Timothy";
foaf:surname "Berners-Lee";
foaf:nick "TimBL", "timbl";
foaf:homepage <http://www.w3.org/People/Berners-Lee/>;
foaf:weblog <http://dig.csail.mit.edu/breadcrumbs/blog/4>;
foaf:mbox <mailto:timbl@w3.org>;
foaf:workplaceHomepage <http://www.w3.org/>.
]
</nowiki>

====Alternative scenario: delete resource====
Delete a resource and all it's properties. If the resource resides within a container it will be removed from that container, however other links to the deleted resource may be left as dangling references.
In the case where the resource is a container, the server may also delete any or all contained resources.
In normal practice, a deleted resource cannot be reinstated. There are however, edge-cases where limited undelete may be desirable.
Best practice states that "[http://www.w3.org/TR/cooluris/| Cool URIs don't change]", which implies that deleted URIs shouldn't be recycled.

====Alternative scenario: moving contained resources====
Many resources may have value beyond the life of their membership in a container. This implies methods to add references to revise container membership.
Cloning container members for use in other containers results in duplication of information and maintenance problems; web practice is to encourage the creation of one resource, which may be referenced as many places as necessary. A change of ownership may - or may not - imply a change of URI, depending upon the specific LDP naming policy. While assigning a new URI to a resource is discouraged [http://www.w3.org/DesignIssues/Architecture.html#HTTP], it is possible to indicate that a resource has moved with an appropriate HTTP response.

===UC3: Retrieve resource description===
Access the current description of a resource, containing properties of that resource and links to related resources. The representation may include descriptions of related resources that cannot be accessed directly.
Depending upon the application, an LDP may enrich the retrieved RDF with additional triples. Examples include adding incoming links, sameAs closure and type closure.
The HTTP response should also include versioning information (i.e. last update or entity tag) so that subsequent updates can ensure they are being applied to the correct version.

* Use standard vocabularies as appropriate to enable a "common understanding of the resource" (from [[#Maintaining Social Contact Information|Maintaining Social Contact Information]]).
* A "scalable linking model is key" (from [[#Municipality Operational Monitoring]]).

====Primary scenario====
The user-story [[#Project Membership Information : Information Evolution| Project Membership Information]] discusses the representation of information about people and projects. It calls for "Resource descriptions for each person and project" allowing project teams to review information held about these resources. The example below illustrates the kinds of information that might be held about organizational structures based on the [http://www.epimorphics.com Epimorphics] [http://www.epimorphics.com/public/vocabulary/org.html organizational ontology].

Note that the example below defines two resources (shown as separate sections below) that will be hosted on an LDP based at <nowiki>http://example.com/</nowiki>. The representations of these resources may include descriptions of related resources, such as <nowiki>http://www.w3.org/</nowiki>, that that fall under a different authority and therefore can't be served from the LDP at this location.

<nowiki>
@prefix org: <http://www.w3.org/ns/org#> .
@prefix owltime: <http://www.w3.org/2006/time> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@base <http://example.com/> .

<member1> a org:Membership ;
org:member <http://www.w3.org/People/Berners-Lee/card#i> ;
org:organization http://www.w3.org/> ;
org:role <director> ;
org:memberDuring [a owltime:Interval; owltime:hasBeginning [
owltime:inXSDDateTime "1994-10-01T00:00:00Z"^^xsd:dateTime]] .

<http://www.w3.org/> a org:FormalOrganization ;
skos:prefLabel "The World Wide Web Consortium"@en ;
skos:altLabel "W3C" .
</nowiki>

<nowiki>
@prefix org: <http://www.w3.org/ns/org#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@base <http://example.com/> .

<director> a org:Role ;
rdfs:label "Director" .
</nowiki>

====Alternative scenario: retrieve description of a non-document resource====
In many cases, the things that are of interest are not always the things that are resolvable. The example below demonstrates how a foaf profile may be used to distinguish between the person and the profile; the former being the topic of the latter. This begs the question as to what a client should do with such non-document resources. In this case the HTTP protocol requires that the fragment part be stripped off before requesting the URI from the server. The result is a resolvable URI for the profile.

<nowiki>
@base <http://www.w3.org/People/Berners-Lee/card>
@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@prefix dc: <http://purl.org/dc/elements/1.1/>.

<> a foaf:PersonalProfileDocument ;
dc:title "Tim Berners-Lee's FOAF file" ;
foaf:homepage <http://www.w3.org/People/Berners-Lee/> ;
foaf:primaryTopic <#i> .
</nowiki>

===UC4: Update existing resource===
Change the RDF description of a LDP resource, potentially removing or overwriting existing data. This allows applications to ''enrich'' the representation of a resource by addling additional links to other resources.

* Unrestricted vocabulary: It should be possible be "able to add ... application-specific data" to resources (from [[#Maintaining Social Contact Information]]).

====Primary scenario: enrichment====
This relates to user-story [[#Metadata Enrichment in Broadcasting| Metadata Enrichment in Broadcasting]] and is based on the [http://www.bbc.co.uk/ontologies/sport/ BBC Sports Ontology]. The ''resource-centric'' view of linked-data provides a natural granularity for substituting, or overwriting a resource and its data. The simplest kind of update would simply replace what is currently known about a resource with a new representation. There are two distinct resources in the example below; a sporting event and an associated award. The granularity of the LDP would allow a user to replace the information about the award without disturbing the information about the event.

<nowiki>
@prefix sport: <http://www.bbc.co.uk/ontologies/sport/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

:mens_sprint a sport:MultiStageCompetition;
rdfs:label "Men's Sprint";
sport:award <#gold_medal> .

<#gold_medal> a sport:Award .
</nowiki>

We can enrich the description as events unfold, linking to the winner of the gold medal by substituting the above description with the following.

<nowiki>
@prefix sport: <http://www.bbc.co.uk/ontologies/sport/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

:mens_sprint a sport:MultiStageCompetition;
rdfs:label "Men's Sprint";
sport:award <#gold_medal> .
<#gold_medal> a sport:Award;
sport:awarded_to [
a foaf:Agent ;
foaf:name "Chris Hoy" .
] .
</nowiki>

====Alternative scenario: selective update of a resource====
This relates to user-story [[#Data Catalogs|Data Catalogs]], based on the [http://vocab.deri.ie/dcat Data Catalog Vocabulary].
A catalogue is described by the following RDF model.

<nowiki>
@prefix dcat: <http://www.w3.org/ns/dcat#> .
@prefix dcterms: <http://purl.org/dc/terms/> .

:catalog a dcat:Catalog ;
dcat:dataset :dataset/001;
dcterms:issued "2012-12-11"^^xsd:date.
</nowiki>

A catalog may contain multiple datasets, so when linking to new datasets it would be simpler and preferable to selectively add just the new dataset links.
A Talis ''changeset'' [http://docs.api.talis.com/getting-started/changesets][http://www.w3.org/2009/12/rdf-ws/papers/ws07] could be used to add a new <nowiki>dc:title</nowiki> to the dataset. The following update would be directed to the catalogue to add an additional dataset.

<nowiki>
@prefix : <http://example.com/>.
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix cs: <http://purl.org/vocab/changeset/schema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.

<change1>
a cs:ChangeSet ;
cs:subjectOfChange :catalog ;
cs:createdDate "2012-01-01T00:00:00Z" ;
cs:changeReason "Update catalog datasets" ;
cs:addition [
a rdf:Statement ;
rdf:subject :catalog ;
rdf:predicate dcat:dataset ;
rdf:object :dataset/002 .
] .
</nowiki>

===UC5: Determine if a resource has changed===
It should be possible to retrieve versioning information about a resource (e.g. last modified or entity tag) without having to download a representation of the resource.
This information can then be compared with previous information held about that resource to determine if it has changed.
This versioning information can also be used in subsequent ''conditional'' requests to ensure they are only applied if the version is unchanged.

====Primary scenario====
Based on the user-story, [[#Constrained Devices and Networks| Constrained Devices and Networks]], an LDP could be configured to act as a proxy for a [http://tools.ietf.org/html/draft-ietf-core-coap CoAP] based [http://en.wikipedia.org/wiki/Web_of_Things Web of Things]. As an observer of CoAP resources, the LDP registers its interest so that it will be notified whenever the sensor reading changes. Clients of the LDP can interrogate the LDP to determine if the state has changed.

In this example, the information about a sensor and corresponding sensor readings can be represented as RDF resources. The first resource below, represents a sensor described using the [http://www.w3.org/2005/Incubator/ssn/ Semantic Sensor Network] ontology.
<nowiki>
@prefix : <http://example.com/energy-management/>.

<> a :MainsFrequencySensor;
rdfs:comment "Sense grid load based on mains frequency";
ssn:hasMeasurementCapability [
a :FrequencyMeasurementCapability;
ssn:hasMeasurementProperty <#property_1> .
] .
</nowiki>

The value of the sensor changes in real-time as measurements are taken. The LDP client can interrogate the resource below to determine if it has changed, ''without'' necessarily having to download the RDF representation. As different sensor properties are represented disjointly (separate RDF representations) they may change independently.

<nowiki>
@prefix : <http://example.com/energy-management/>.

<http://example.com/energy-management#property_1> :hasMeasurementPropertyValue <> .
<> a :FrequencyValue;
:hasQuantityValue "50"^^xsd:float.
</nowiki>

===UC6: Aggregate resources===
There is a requirement to be able to manage ''collections'' of resources. The concept of a collection overlaps with, but is distinct from that of a container. These collections are (weak) aggregations, unrelated to the lifecycle management of resources, and distinct from the ownership between a resource and its container. However, the composition of a container may be reflected as a collection to support navigation of the container and its contents. There is a need to be able to create collections by adding and deleting individual membership properties. Resources may belong to multiple collections, or to none.

* Resource descriptions are a "mix of simple data and collections" (from [[#Keeping Track of Personal and Business Relationships]]).
* Relative URIs: It should be possible to "ship payloads of RDF" for a collection as a whole without breaking internal links (from [[#Constrained Devices and Networks]]).

====Primary scenario: add a resource to a collection====
This example is from [[#Library Linked Data|Library Linked Data]] and [http://www.w3.org/2005/Incubator/lld/wiki/UseCaseReport LLD-UC], specifically [http://www.w3.org/2005/Incubator/lld/wiki/Use_Case_Subject_Search Subject Search].

There is an existing collection at <nowiki><http://example.com/concept-scheme/subject-heading></nowiki> that defines a collection of subject headings. This collection is defined as a skos:ConceptScheme and
the client wishes to insert a new concept into the scheme. which will be related to the collection via a <nowiki>skos:inScheme</nowiki> link. The new subject-heading, "outer space exploration", is not necessarily owned by a container. The following RDF would be added to the (item-level) description of the collection.

<nowiki>
@prefix scheme : <http://example.com/concept-scheme/>.
@prefix concept : <http://example.com/concept/>.

scheme:subject-heading a skos:ConceptScheme.

concept:Outer+space+Exploration skos:inScheme scheme:subject-heading.
</nowiki>

====Alternative scenario: add a resource to multiple collections====
Logically, a resource should not be owned by more than one container. however, it may be a member of multiple collections which define a weaker form of ''aggregation''. As this is simply a manipulation of the RDF description of a collection, it should be possible to add the same resource to multiple collections.

As a machine-readable collection of medical terms, the [http://www.ihtsdo.org| SNOMED] ontology is of key importance in [[#Healthcare | healthcare]]. SNOMED CT allows concepts with more than one parent that don't fall into a lattice.
In the example below, the same concept may fall under two different parent concepts.
The example uses skos:narrowerTransitive to elide intervening concepts.

<nowiki>
@prefix : <http://example.com/snomed/>.

:_119376003 a skos:Concept ;
skos:prefLabel "Tissue specimen"
skos:narrowerTransitive :TissueSpecimenFromHeart.

:_127462005 a skos:Concept ;
skos:prefLabel "Specimen from heart"
skos:narrowerTransitive :TissueSpecimenFromHeart.

:_128166000 a skos:Concept;
rdfs:label "Tissue specimen from heart".
</nowiki>

===UC7: Filter resource description===
This use-case extends the normal behaviour of retrieving an RDF description of a resource, by dynamically excluding specific (membership) properties.
For containers, it is often desirable to be able to read a collection, or item-level description that excludes the container membership.

====Primary scenario: retrieve collection-level description====
This scenario, based on [[#Library Linked Data| Library Linked Data]], uses the Dublin Core Metadata Initiative [http://dublincore.org/groups/collections/collection-application-profile/| Collection-Level] description.
A collection can refer to any aggregation of physical or digital items.
This scenario covers the case whereby a client can request a collection-level description as typified by the example below, without necessarily having to download a full listing of the items within the collection.

<nowiki>
@prefix rdf: <rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">.
@prefix dc: <http://purl.org/dc/elements/1.1/>.
@prefix : <http://example.org/bookshelf/>.
@prefix dcmitype: <http://purl.org/dc/dcmitype/>.
@prefix cld: <http://purl.org/cld/terms/>.
@prefix dcterms: <http://purl.org/dc/terms/>.

<> dc:type dcmitype:Collection ;
dc:title "Directory of organizations working with Linked Data" ;
dcterms:abstract "This is a directory of organisations specializing in Linked Data."
cld:isLocatedAt <http://dir.w3.org>
cld:isAccessedVia <http://dir.w3.org/rdf/2012/directory/directory-list.xhtml?construct>
</nowiki>

====Alternative scenario: retrieve item-level description of a collection====
This use-case scenario, also based on [[#Library Linked Data| Library Linked Data]], focuses on obtaining an item-level description of the resources aggregated by a collection.
The simplest scenario is where the members of a collection are returned within a single representation, so that a client can explore the data by following these links. Different applications may use different membership predicates to capture this aggregation. The example below uses <nowiki>rdfs:member</nowiki>, but many different membership predicates are in common use, including RDF Lists.
Item-level descriptions can be captured using the Functional Requirements for Bibliographic Records ([http://www.ifla.org/publications/functional-requirements-for-bibliographic-records FRBR]) [http://vocab.org/frbr/core.html ontology].

<nowiki>
@prefix frbr: <http://purl.org/vocab/frbr/core#>.

<> rdfs:member <#ebooks97>, <#ebooks21279>.

<#work97> a frbr:LiteraryWork;
dc:title "Flatland: a romance of many dimensions" ;
frbr:creator <#Abbott_Edwin>;
frbr:manifestation <ebook97>.

<#work21279> a frbr:LiteraryWork;
dc:title "2 B R 0 2 B" ;
frbr:creator <#Vonnegut_Kurt>;
frbr:manifestation <ebook21279>.
</nowiki>

Collections are potentially very large, so some means may be required to limit the size of RDF representation returned by the LDP (e.g. pagination).

===UC8: Manage media resources===
It should be possible to easily add non-RDF media resources to containers that accept them. Media resources may be updated and removed during the lifecycle of the container.

====Primary scenario: describe media resources====
From the User Story [[#Sharing Binary Resources and Metadata| Sharing Binary Resources and Metadata]] it should be possible to easily add non RDF resources to a containers that accept them. Clients submit a non-RDF representation to a container in a media type accepted by that container. The container creates a URI to represent this media resource, and creates a link from the container to the new URI.The media resource may have an explicit representation of the media type. It should be possible to find the metadata about such a resource and to access and edit it in the usual ways.

This example uses the [http://www.w3.org/TR/mediaont-10/#ont-ttl Ontology for Media Resources] to describe a media resource added to a collection.
<nowiki>
@prefix ma: <http://www.w3.org/ns/ma-ont#> .

<dataset> a ma:Collection ;
:hasMember <dataset/image1.jpg>

<dataset/image1.jpg> a ma:MediaResource ;
ma:hasFormat "image/jpeg" .
</nowiki>

====Alternative scenario: media-resource attachments====
A resource may have multiple ''renditions''; the idea that you can have a PDF and a JPEG representing the same thing. A user is trying to create a work order along with an attached image showing a faulty machine part. To the user and to the work order system, these two artifacts are managed as a set. A single request may create the work order, the attachment, and the relationship between them, atomically.
When the user retrieves the work order later, they expect a single request by default to retrieve the work order plus all attachments.
When the user updates the work order, e.g. to mark it completed, they only want to update the work order proper, not its attachments.
Users may add/remove/replace attachments to the work order during its lifetime.

== Requirements ==

'''TODO: Refine these based on use case and scenario updates'''

===Functional Requirements===
# Create Containers, from [[#UC1: Manage containers]]
# Creation of nested containers, from [[#UC1: Manage containers]]
# Creation of resources (within a container), from [[#UC2: Manage resources]]
# Deletion of resources, from [[#UC2: Manage resources]]
# Moving contained resources, from [[#UC2: Manage resources]]
# Retrieve resource description, from [[#UC3: Retrieve resource description]]
# Retrieve description of a non-document resource, from [[#UC3: Retrieve resource description]]
# Enrichment (substituting update of existing resource), from [[#UC4: Update existing resource]]
# Selective update of a resource, from [[#UC4: Update existing resource]]
# Determine if a resource has changed, from [[#UC5: Determine if a resource has changed]]
# Add a resource to a collection, from [[#UC6: Aggregate resources]]
# Add a resource to multiple collections, from [[#UC6: Aggregate resources]]
# Retrieve collection-level description, from [[#UC7: Filter resource description]]
# Retrieve item-level description of a collection, from [[#UC7: Filter resource description]]
# Add non-RDF resources, from [[#UC8: Manage non-RDF Resources]]
# Add multiple non-RDF resources, from [[#UC8: Manage non-RDF Resources]]

===Non-Functional Requirements===

# Provide access guidance to resources, from [[#UC1: Manage containers]]
# Non-duplication of resources, from [[#UC2: Manage resources]]
# Distribution of resources, from [[#UC2: Manage resources]]
# Consistent, global naming, from [[#UC2: Manage resources]]
# Use standard vocabularies as appropriate, from [[#UC3: Retrieve resource description]]
# Scalable linking model, from [[#UC3: Retrieve resource description]]
# Unrestricted vocabulary, from [[#UC4: Update existing resource]]
# Resource descriptions are a "mix of simple data and collections", from [[#UC6: Aggregate resources]]
# Relative URIs enabling sharing of collections, from [[#UC6: Aggregate resources]]

== Acknowledgements ==
We would like to acknowledge the contributions of user-story authors; Christophe Guéret, Roger Menday, Eric Prud'hommeaux.

== References ==