Linked Data Platform Use Cases and Requirements

3.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, 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.

3.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 member of its collection of customers.

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

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

The 'Digital Objects Cluster' 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."

• Enrichment: "Enable end-users to link resources together."

• Browsing: "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 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.

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

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

3.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's like you don't have it 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.

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

3.9 Sharing payload of RDF data among low-end devices

Several projects around the idea of 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, the "SemanticXO" project uses named graphs and the graph store protocol to create/delete/copy graphs across the nodes but this (almost) imposes the usage of a triple store. Unfortunately, triple stores are rather demanding pieces 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.

3.10 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 Linked Data 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 be in the image file but is better kept 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 (application metadata about the image) does are not distinguished from the platform's point-of-view.

3.11 Data Catalogs

The Asset Description Metadata Schema (ADMS) provides the data model to describe semantic asset repository contents, but this leaves many open challenges when building a federation of these repositories to serve the need of asset 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 one 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.

Repository 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

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

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

• 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 an 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: Wf4Ever

3.14 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 to the project team itself, instead of requiring updates to be requested from 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

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

4.1 Use Case: 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).

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

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

4.2 Use Case: 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 server 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 Atom Publishing Protocol slug header to convey a user defined naming 'hint' [RFC5023].

• Non-duplication of resources: "Eliminate multiple copies", representing resources in a single place (from #Maintaining Social Contact Information).
• Distribution of resources: Linked data "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).

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

4.3 Use Case: 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 server 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).
• A "scalable linking model is key" (from #Municipality Operational Monitoring).

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

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

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

4.4 Use Case: 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).

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

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

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

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

4.5 Use Case: 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.

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

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

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

4.6 Use Case: 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).

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

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

4.7 Use Case: 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.

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

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

4.8 Use Case: 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.

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

5.1 Functional Requirements

1. Create Containers, from Use Case: Manage containers
2. Creation of nested containers, from Use Case: Manage containers
3. Creation of resources (within a container), from Use Case: Manage resources
4. Deletion of resources, from Use Case: Manage resources
5. Moving contained resources, from Use Case: Manage resources
6. Retrieve resource description, from Use Case: Retrieve resource description
7. Retrieve description of a non-document resource, from Use Case: Retrieve resource description
8. Enrichment (substituting update of existing resource), from Use Case: Update existing resource
9. Selective update of a resource, from Use Case: Update existing resource
10. Determine if a resource has changed, from Use Case: Determine if a resource has changed
11. Add a resource to a collection, from Use Case: Aggregate resources
12. Add a resource to multiple collections, from Use Case: Aggregate resources
13. Retrieve collection-level description, from Use Case: Filter resource description
14. Retrieve item-level description of a collection, from Use Case: Filter resource description
15. Access media resources, from Use Case: Manage media resources
16. Media-resource attachments, from Use Case: Manage media resources

5.2 Non-Functional Requirements

1. Provide access guidance to resources, from Use Case: Manage containers
2. Non-duplication of resources, from Use Case: Manage resources
3. Distribution of resources, from Use Case: Manage resources
4. Consistent, global naming, from Use Case: Manage resources
5. Use standard vocabularies as appropriate, from Use Case: Retrieve resource description
6. Scalable linking model, from Use Case: Retrieve resource description
7. Unrestricted vocabulary, from Use Case: Update existing resource
8. Resource descriptions are a "mix of simple data and collections", from Use Case: Aggregate resources
9. Relative URIs enabling sharing of collections, from Use Case: Aggregate resources