Use Cases And Requirements

From Linked Data Platform
Revision as of 06:24, 4 October 2012 by Rgarcaca (Talk | contribs)

Jump to: navigation, search

Contents

1 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 Linked Data Basic Profile Use Cases and Requirements.

1.1 Scope and Motivation

1.2 User Stories

1.2.1 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 reading, updating, and deleting it), as well as how to easily 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.

1.2.1.1 Analysis

The user story above includes the the following functional requirements:

The story describes an ideal situation where "we could update [contact] information in one spot." Such a master copy of a collection of contacts is represented as a container resource (Basic Profile Container).

A "common understanding of the resource" would be supported by using a well-known ontology such as FOAF (Friend of a Friend) to capture contact details. In addition to this, it should be possible, even at runtime, to "add some application-specific data about my contacts that the original design didn’t consider."

  • It should be possible to "easily create a new contact and add it to my contacts." Contact details are captured as a resource (Basic Profile Resource) and it's properties. This is an example of use-case #UC-BPC2: Create resource within a container.

"There might also be good reasons ... to maintain a local copy of the contact." HTTP clients may cache RDF representations of resources. When a contact changes "all copies of it would automatically be updated." This client-side behaviour is outside the scope of the LDP, however it should allow clients to determine whether or not contact details have changed so that they may trigger such an update.

  • "when deleting a contact, ... it would be removed from my list of contacts." This is an example of use-case #UC-BPR4: Delete resource.

Within this story, contact information can be merged, "Regardless of whether a contact collection is my own, [or] shared." It is common for linked data publishers to use <http://www.w3.org/2002/07/owl#sameAs> to define aliases between two resources; in this case between contacts in my own collection and those in a shared collection (see <http://linkeddatabook.com/editions/1.0/#htoc20>). The server may or may not support the dereferencing of sameAs links; this is outside the scope of the LDP. However, the data source can be treated as an independent actor within the use-case, leaving it free to perform this function or not, as the application demands.

1.2.2 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 examine or 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 simple collection. The information held by any single organization might be a mix of simple data and collections of other data, for example, a bank account balance and a collection of historical transactions. Our bank might easily have a collection of accounts for each of its collection of customers.

1.2.2.1 Analysis

This describes a scenario where is is possible to "build a set of bookmarks" to our personal information. The LDP makes it possible to identify each resource of interest with a consistent URI. A "single consistent application interface" is provided by a RESTful HTTP interface and the exchange of RDF representations.

This user story emphasises that, directly or indirectly, containers may contain other containers. For example, "a collection of accounts for each of its collection of customers".

1.2.3 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. OSLC

1.2.3.1 Analysis

OSLC Services use HTTP for create, retrieve, update and delete operations on resources. The OSLC core specifies the following resource operations:

1.2.4 Library Linked Data

The W3C Library Linked Data working group has a number of use cases cited in their Use Case Report. 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.

1.2.4.1 Analysis

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

  • Grouping: This should "Allow the end-users to define 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." This is an example of #UC8: Add existing resource to a container.
  • 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:

  • 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." The Basic Profile does not define how clients discover BPCs.
  • Community information services: Identify and classify collections of special interest to the community.

1.2.5 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 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.

1.2.6 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.

1.2.6.1 Analysis

This story raises questions about the privacy and security of health information. In the US this requires compliance with the Health Insurance Portability and Accountability Act (HIPAA). The Privacy Rule standards address the use and disclosure of "individually identifiable health information" called “protected health information” (PHI). A goal of the Privacy Rule is to assure that an individual's health information is properly protected while allowing the flow of health information needed to provide and promote high quality healthcare as described above. Consequently, there are no restrictions on the use or disclosure of properly de-identified health information.

1.2.7 Metadata enrichment in broadcasting

There are many different use cases when broadcasters show interest in metadata 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.

1.2.8 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 aggregated, 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.

1.2.8.1 Analysis

The LDP specification supports scenarios that are "pull-based, where the data is requested from data sources." While out of scope, push-notifications may be supported by implementations.

1.2.9 Data Sharing

In a downscaled context, where the used of a central data repository is replaced by several smaller servers, it is necessary to be able to ship information among the servers. A device in the network may publish an information on a server with an other device as a target receiver. This message will then have to be forwarded from server to server until that target is reached. A set of common standards for updating the content of containers and the description of the resources will be necessary to implement such feature (not taking the routing aspect into consideration here).

1.2.9.1 Analysis

LDP implementations may employ different strategies for achieving scalable performance, including the use of federated web-servers as described.

1.2.10 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. 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).

"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.

1.2.11 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>. LDBP doesn't provide any gudiance around that.

1.2.11.1 Analysis

This relates to #UC-UC-BPC2: Create resource within a container. How does the new resource, in this case '_:newBug' relate to the POSTed representation.

1.2.12 LDP and Authentication/Authorization

Access to the Linked Data Platform often may require authentication and authorization. Access by clients can depend on the interaction context (different resources are needed for accomplishing different goals), client identity (different clients have different levels of access), and possibly client roles (access control may be coupled to roles instead of identities, in which case client/role associations need to be established) and/or client attributes (access control may be coupled to attributes which can be used even when the client identities are unknown, assuming that the attributes can be reliably determined). On the Web, many different ways of identification (establishing naming schemes that uniquely identify entities of interest), authentication (frameworks for verifying someone's claim to have an identity), and authorization (granting access to a resource based on an identity and some access control scheme) exist. In addition, in many cases platforms must integrate into existing scenarios around these issues, and cannot freely pick a framework from scratch. Thus, LDP should provide developers with some guidance around the following issues:

  • How should LDP services integrate into existing landscapes of identification, authentication, and authorization? For some established technologies, maybe we can provide guidance and patterns on how to support them.
  • What is a reasonable authentication and authorization model? LDP will be used to drive many different services, and these might have different models of how clients should have access to LDP services in the context of those specific application scenarios. What is a reasonable model so that LDP providers can handle this flexibility, and still can support identification, authentication, and authorization frameworks that are dictated by the environment? In this context, is it more reasonable to deal with roles or attributes in granting the access to the clients?

1.2.13 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.

1.2.13.1 Analysis

(Andy): 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

A key issue for our work is whether to link these two elements or treat them separately:

Coupled: treat as a single BPR - one implication might be to allow a single POST/PUT with RDF and non-RDF parts, and have the BPR server manage the URI naming for the non-RDF part.

Separate: treat as the RDF data as a BPR - one implication might be that the image to be put somewhere with a URL, then receive just the metadata as a BPR which references the URL.

1.2.14 Data catalogs

The Asset Description Metadata Schema (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 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: Data Catalog Schema and Protocol

1.2.15 Constrained Devices and Networks

Information coming from resource constrained devices in the 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 6LowPAN - IPv6 for resource constrained devices - and the Constrained Application Protocol (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-CoAP Mapping would enable constrained devices to directly participate in a Linked Data-based environment.

For a detailed description of application scenarios for constrained devices see a separate document kindly compiled by Myriam Leggieri.

1.2.16 Services supporting the process of science

General movitation

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.

Specific requirements

  • 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).
  • Compatibility with access control that can reflect the needs for privacy and publication at different stages of the research lifecycle.

seeAlso: Wf4Ever


1.2.17 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 Link 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

See also Maintaining Social Contact Information.

1.3 Use Cases

In the scenarios that follow, there are a number of commonly used namespace prefixes:

@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#>.
 

1.3.1 Actors

  • Client: The client communicates with the LDP via an HTTP RESTful RDF protocol. It may cache RDF representations returned by the LDP.
  • Data Source: The LDP communicates with one or more data sources that may perform application specific inference, such as type and sameAs closure.

1.3.2 UC-BPR1: Retrieve RDF representation of a resource

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

1.3.2.1 Assumptions

1.3.2.2 Scenarios

1.3.2.2.1 Primary Scenario: Request RDF representation of an information resource

In the basic case, the requested resource is an information resource:

  1. The client performs a GET request on a URI identifying a resolvable information resource. If the client requires a Turtle representation, it provides an accept header requesting media type "text/turtle".
  2. The server communicates with the data source to build at least a concise bounded description of the requested resource.
  3. The server answers with HTTP response code 200 OK and returns the requested representation, describing the resource in the requested format.

The 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.

@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>.
 

The resource identified by <http://example.com/people/alice> is requested below:

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

The response describes Alice, but not Bob :

HTTP/1.1 200 OK 
Content-Type: text/turtle
ETag: "123456789"

@prefix : <http://example.com/people/>.

:alice a foaf:Person;
   rdfs:label "Alice";
   foaf:mbox <mailto:alice@example.com>;
   foaf:knows :bob.
 
1.3.2.2.2 Alternative Scenario: Request 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 BPR.

  1. The client performs a HTTP GET request on a URI identifying a non-information resource.
  2. The server answers with an HTTP 303 See Other response code, redirecting the client to an information resource.
  3. The client performs an HTTP GET request on the resolvable BPR, with an accept header requesting information in the required format.
  4. The server answers with a HTTP response code 200 OK and sends the client the requested RDF representation.

The data source holds social contact information about Alice and Bob, and the client requests contact details for Alice. The wdrs:describedby relationships introduce a distinction between things and their descriptions.

@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.
 

In this case, the <http://example.com/people/alice> resource is redirected to it's descriptive URI, <http://example.com/people/alice.rdf>.

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

The first response is the 303 redirect to <http://example.com/people/alice.rdf>.

HTTP/1.1 303 See Other
Location: http://example.com/people/alice.rdf
 

The client performs a GET of the returned location:

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

The response includes information about <http://example.com/people/alice.rdf> and anything it describes.

HTTP/1.1 200 OK 
Content-Type: text/turtle
ETag: "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.
 

1.3.2.3 Non-Functional

  • The response header includes the ETag for the BPR.
  • The response contains a concise description (possibly application specific) of the requested resource. See <http://www.w3.org/Submission/CBD/> for discussion of Concise Bounded Descriptions.

1.3.2.4 Issues

  • Are non-resolvable non-information resources supported, and are they redirected to BPRs?
  • Is Last-Modified returned in the entity header?
  • If the describedby link is hosted on a different server, should the LDP simply redirect to that location, or fetch and merge the results with locally hosted RDF, and include the Content-Location in the response header?

1.3.3 UC-BPR2: Update existing resource

An HTTP PUT may be used to replace the current properties of a resource. Alternatively, an HTTP patch may be used to selectively update existing properties of the resource.

1.3.3.1 Assumptions

1.3.3.2 Scenarios

1.3.3.2.1 Primary Scenario: Replace the current resource in full

Replace the entire persistent state of the identified resource with the entity representation in the body of the request.

In the basic case, the requested resource is an information resource:

  1. The client performs a GET request on a URI identifying a Basic Profile Resource. If the client requires a Turtle representation, it provides an accept header requesting media type "text/turtle".
  2. The server communicates with the data source to build at least a concise bounded description of the requested resource.
  3. The server answers with HTTP response code 200 OK and returns the requested representation, describing the resource in the requested format, including the current ETag.
  4. The client performs a PUT on the same URI with RDF representing the updated resource, including an If-Match header with the current (expected) ETag.
  5. The server communicates the updated RDF representation to the data source, comparing ETags.
  6. The server responds with an appropriate status code

The data source holds social contact information about Alice, and the client wishes to update the email contact details for her.

@prefix : <http://example.com/people/>.

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

The client performs an initial HTTP GET to establish the current state of the resource.

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

As well as the RDF state, the client saves the ETag.

HTTP/1.1 200 OK 
Content-Type: text/turtle
ETag: "123456789"

@prefix : <http://example.com/people/>.

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

The resource identified by <http://example.com/people/alice> is updated below, including the current ETag:

PUT http://example.com/people/alice HTTP/1.1
Host: example.com
Content-Type: text/turtle
If-Match: "123456789"

@prefix : <http://example.com/people/>.

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

The response confirms the update:

HTTP/1.1 200 OK 
Content-Type: text/turtle
ETag: "123456790"
 
1.3.3.2.2 Alternative Scenario: Selective update of the resource

Selectively add and remove properties to and from the identified resource.

  1. The client performs a HEAD request on a URI identifying a basic profile resource.
  2. The server answers with HTTP response code 200 OK and returns ETag.
  3. The client sends an HTTP PATCH describing the updates.
  4. The server response describes the final updated state of the resource.

The data source holds social contact information about Alice, and the client wishes to update the email contact details for her.

@prefix : <http://example.com/people/>.

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

The client may perform an HTTP HEAD to get the current ETag.

HEAD http://example.com/people/alice HTTP/1.1
Host: example.com
Accept: text/turtle
 

The response contains the ETag header that will be added to the PATCH.

HTTP/1.1 200 OK 
Content-Type: text/turtle
ETag: "123456789"
 

The resource identified by <http://example.com/people/alice> is updated below, including the current ETag. The PATCH is defined here using a changeset.

PUT http://example.com/people/alice HTTP/1.1
Host: example.com
Content-Type: text/turtle
If-Match: "123456789"

@prefix : <http://example.com/people/>.
@prefix cs: <http://purl.org/vocab/changeset/schema#>
<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> .
  ] .
 

The response confirms the update:

HTTP/1.1 200 OK 
Content-Type: text/turtle
ETag: "123456790"

@prefix : <http://example.com/people/>.

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

1.3.3.3 Non-Functional

1.3.3.4 Issues

1.3.4 UC-BPR3: Determine if a resource has changed

The client may use the entity tag associated with a resource to determine if it has changed. In the simplest scenario, the client may perform an HTTP HEAD to retrieve and compare the latest entity tag with the entity tag of the cached copy. Alternatively, the client may conditionally request the resource using an HTTP GET with an 'If-None-Match' and the last known entity tag.

1.3.4.1 Assumptions

1.3.4.2 Scenarios

1.3.4.2.1 Primary Scenario: Use HTTP HEAD to retrieve ETag
1.3.4.2.2 Alternative Scenario: Conditional HTTP GET using 'If-None-Match'

1.3.4.3 Non-Functional

1.3.4.4 Issues

  • Can the Last-Modified date be used in addition to the entity tag?

1.3.5 UC-BPR4: Delete resource

An HTTP DELETE is issued by the client to delete the resource and all it's properties, on the server.

1.3.5.1 Assumptions

1.3.5.2 Scenarios

1.3.5.2.1 Primary Scenario

1.3.5.3 Non-Functional

1.3.5.4 Issues

1.3.6 UC-BPR5: Create resource

A resource may be created independently of a container using HTTP PUT.

1.3.6.1 Assumptions

1.3.6.2 Scenarios

1.3.6.2.1 Primary Scenario

1.3.6.3 Non-Functional

1.3.6.4 Issues

1.3.7 UC-BPC1: List resources within a container

The LDP server accepts a GET request for a particular container resource, returning an RDF representation comprising information about that container and the resources that it contains. The properties for each resource may be retrieved at the same time, or separately. When the contents of a container are too numerous, it may be paginated.

1.3.7.1 Assumptions

1.3.7.2 Scenarios

1.3.7.2.1 Primary Scenario: List contained resources but not their properties

The accept header specifies the required media type for the returned RDF serialization.

This scenario is based on the user-story #Maintaining Social Contact Information. The LDP holds social contact information in a container called /mycontacts (an information resource).

<http://example.com/mycontacts>
   a bp:Container;
   rdfs:member
      <http://example.com/people/alice>,
      <http://example.com/people/bob>.

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

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

The user requests information about the container resource.

GET http://example.com/mycontacts HTTP/1.1
Host: example.com
Accept: text/turtle
 

The response should include information about the container and references to contained resources, but not information about them.

<http://example.com/mycontacts>
   a bp:Container;
   rdfs:member
      <http://example.com/people/alice>,
      <http://example.com/people/bob>.
 
1.3.7.2.2 Alternative Scenario: List contained resources with their properties
1.3.7.2.3 Alternative Scenario: List contained resources and their properties redirected to first page
1.3.7.2.4 Alternative Scenario: List single page of contained resources and their properties

1.3.7.3 Non-Functional

1.3.7.4 Issues

  • The member resources may include non-information resources.

1.3.8 UC-BPC2: Create resource within a container

An HTTP POST to the target container, including a representation of the new resource, creates a new resource with the provided properties within that container.

1.3.8.1 Assumptions

1.3.8.2 Scenarios

1.3.8.2.1 Primary Scenario

1.3.8.3 Non-Functional

1.3.8.4 Issues

  • How does the created resource relate to the RDF description? See #Hosting POSTed Resources. Specifically, in the supplied representation does the document base have the same referent as the created resource?
  • Should POST support a user supplied local-name 'hint', to support more human-readable URIs?

1.3.9 UC-BPC3: Retrieve non-member properties of a container

1.3.9.1 Assumptions

1.3.9.2 Scenarios

1.3.9.2.1 Primary Scenario

1.3.9.3 Non-Functional

1.3.9.4 Issues

1.3.10 UC-BPC4: Add existing resource or container to a container

The same resource may be a member of multiple containers.

1.3.10.1 Assumptions

1.3.10.2 Scenarios

1.3.10.2.1 Primary scenario: Add a pre-existing resource to a container

1.3.10.3 Non-Functional

1.3.10.4 Issues

  • According to the Linked Data Basic Profile 1.0, PUT and PATCH should not be used:- "BPC servers should not allow HTTP PUT to update a BPC’s members" and should only use "HTTP PATCH as the preferred method for updating BPC non-membership properties." See ISSUE-7.
  • As BPCs as noted as being potentially large memberships, sending a whole, updated BPC after changes is not practical. See ISSUE-7.

1.3.11 UC-BPC5: Update container non-membership properties

Use HTTP PUT or HTTP PATCH to update a BPC's non-membership properties.

1.3.11.1 Assumptions

1.3.11.2 Scenarios

1.3.11.2.1 Primary Scenario

1.3.11.3 Non-Functional

1.3.11.4 Issues

1.3.12 UC-BPC6: Determine if a container has changed

1.3.12.1 Assumptions

1.3.12.2 Scenarios

1.3.12.2.1 Primary Scenario

1.3.12.3 Non-Functional

1.3.12.4 Issues

1.3.13 UC-BPC7: Delete a container

1.3.13.1 Assumptions

1.3.13.2 Scenarios

1.3.13.2.1 Primary Scenario

1.3.13.3 Non-Functional

1.3.13.4 Issues

  • Where BPR's are managed by a container, they may be deleted along with the container. See ISSUE-7, 'The doc talks about the "the BPC that was used to create it [BPR]"

(5.6.2) and "should remove it from any other containers..." This means the creating container is distinguished and needs to manage the BPRs is creates separately from those it did not.'

1.3.14 UC-BPC8: Remove a resource from a container without deleting it

1.3.14.1 Assumptions

1.3.14.2 Scenarios

1.3.14.2.1 Primary Scenario

1.3.14.3 Non-Functional

1.3.14.4 Issues

1.4 Requirements

  1. Define a minimal set of RDF media-types/representations
  2. Define a limited number of literal value types
  3. Use standard vocabularies as appropriate
  4. Update resources, either RDF-based or not
  5. Use optimistic collision detection on updates
  6. Ensure clients are ready for resource format and type changes
  7. Apply minimal constraints for creation and update
  8. Add a resource to an existing container
  9. Remove a resource, including any associations with a container
  10. Get members of a container
  11. When getting members of a container, provide data about the members
  12. Get just data about a container, without all the members
  13. Handle a large number of members of a container, breaking up representation into pages
  14. Allow pages to have order information for members, within a page and across all pages

1.5 Acknowledgements

1.6 References