Pulled in content from wiki version
authorsspeiche
Sun, 16 Dec 2012 11:04:21 -0500
changeset 24 2181c58ad40f
parent 23 51eff68f0e53
child 25 aad28fc3943d
Pulled in content from wiki version
ldp-ucr.html
--- a/ldp-ucr.html	Fri Dec 14 15:28:41 2012 -0500
+++ b/ldp-ucr.html	Sun Dec 16 11:04:21 2012 -0500
@@ -119,23 +119,1615 @@
 </section>
  
 <section>
-<h1 id="intro">Scope and Motivation</h1>
+<h1 id="scope">Scope and Motivation</h1>
+	<p>
+		Linked Data was defined by Tim Berners-Lee with the following
+		guidelines <a
+			href="http://www.w3.org/DesignIssues/LinkedData.html"
+			class="external autonumber"
+			title="http://www.w3.org/DesignIssues/LinkedData.html"
+			rel="nofollow">[1]</a>:
+	</p>
+	<ol>
+		<li>Use URIs as names for things</li>
+		<li>Use HTTP URIs so that people can look up those names</li>
+		<li>When someone looks up a URI, provide useful information,
+			using the standards (RDF*, SPARQL)</li>
+		<li>Include links to other URIs. so that they can discover
+			more things</li>
+	</ol>
+	<p>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.</p>
+	<p>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.</p>
+	<p>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.</p>
+	<p>Some of the features that make Linked Data exceptionally
+		well suited for integration include:</p>
+	<ul>
+		<li>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.</li>
+		<li>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.</li>
+		<li>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.</li>
+	</ul>
+	<p>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.</p>
+	<p>The following list illustrates a few of the issues that
+		require additional rules and patterns:</p>
+	<ul>
+		<li>What URLs do I post to in order to create new resources?
+		</li>
+		<li>How do I get lists of existing resources, and how do I
+			get basic information about them without having to access each
+			one?</li>
+		<li>How should I detect and deal with race conditions on
+			write?</li>
+		<li>What media-types/representations should I use?</li>
+		<li>What standard vocabularies should I use?</li>
+		<li>What primitive data types should I use?</li>
+	</ul>
+	<p>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.</p>
 
 </section>
+
+<section>
+<h1 id="org">Organization of this Document</h1>
+	<p>This document is organized as follows:</p>
+	<ul>
+		<li><b><a href="#user-stories" title=""> User Stories</a></b>
+			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') <a
+			href="http://www.agilemodeling.com/artifacts/userStory.htm"
+			class="external autonumber"
+			title="http://www.agilemodeling.com/artifacts/userStory.htm"
+			rel="nofollow">[2]</a>. Analysis of each user story will reveal a
+			number of (functional) use-cases and other non-functional
+			requirements. See <a
+			href="http://www.w3.org/TR/dap-policy-reqs/|"
+			class="external text"
+			title="http://www.w3.org/TR/dap-policy-reqs/|" rel="nofollow">Device
+				API Access Control Use Cases and Requirements</a> for a good example
+			of user stories and their analysis.</li>
+	</ul>
+	<ul>
+		<li><b><a href="#use-cases" title=""> Use Cases</a></b> are
+			used to capture and model functional requirements. Use cases
+			describe the system’s behavior under various conditions <a
+			href="http://alistair.cockburn.us/get/2465"
+			class="external autonumber"
+			title="http://alistair.cockburn.us/get/2465" rel="nofollow">[3]</a>,
+			cataloguing who does what with the system, for what purpose, but
+			without concern for system design or implementation <a
+			href="http://www.bredemeyer.com/pdf_files/functreq.pdf"
+			class="external autonumber"
+			title="http://www.bredemeyer.com/pdf_files/functreq.pdf"
+			rel="nofollow">[4]</a>. 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 <a
+			href="http://www.w3.org/TR/rdb2rdf-ucr/" class="external text"
+			title="http://www.w3.org/TR/rdb2rdf-ucr/" rel="nofollow">rdb2rdf
+				use-cases</a>. 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 <a
+			href="http://www.w3.org/TR/powder-use-cases/"
+			class="external text"
+			title="http://www.w3.org/TR/powder-use-cases/" rel="nofollow">POWDER:
+				Use Cases and Requirements</a>, 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.</li>
+	</ul>
+	<ul>
+		<li><b>Scenarios</b> are more focused still, representing a
+			single instance of a use case in action. Scenarios may range from
+			lightweight narratives as seen in <a
+			href="http://www.w3.org/TR/media-frags-reqs/"
+			class="external text"
+			title="http://www.w3.org/TR/media-frags-reqs/" rel="nofollow">Use
+				cases and requirements for Media Fragments</a>, to being formally
+			modeled as interaction diagrams. Each use-case should include at
+			least a primary scenario, and possibly other alternative
+			scenarios.</li>
+	</ul>
+	<ul>
+		<li><b><a href="#reqs" title=""> Requirements</a></b>
+			lists non-functional or quality requirements, and the use cases
+			they may be derived from. This approach is exemplified in the <a
+			href="http://dvcs.w3.org/hg/gld/raw-file/default/dcat-ucr/index.html"
+			class="external text"
+			title="http://dvcs.w3.org/hg/gld/raw-file/default/dcat-ucr/index.html"
+			rel="nofollow">Use Cases and Requirements for the Data
+				Catalog Vocabulary</a>. 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.</li>
+	</ul>
+</section>
 	
 <section>
 <h1 id="userstories">User Stories</h1>
 
+	<section>
+	<h2 id="story-social">Maintaining Social Contact Information</h2>
+	<p>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.”</p>
+	<p>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.</p>
+	<p>
+		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 <a
+			href="#UC3:_Retrieve_resource_description" title="">reading</a>,
+		<a href="#UC4:_Update_existing_resource" title="">updating</a>,
+		and <a href="#Alternative_scenario:_delete_resource" title="">deleting</a>
+		it), as well as how to easily <a
+			href="#Primary_scenario:_create_resource" title="">create a
+			new contact</a> 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.
+	</p>
+	</section>
+	
+	<section>
+	<h2 id="story-tracking_relationships">Keeping Track of Personal and
+			Business Relationships</h2>
+	<p>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.</p>
+	<p>
+		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 <a
+			href="#UC3:_Retrieve_resource_description" title="">examine</a>
+		or <a href="#UC4:_Update_existing_resource" title="">change</a>
+		their contents, would it not be simpler if there were a single
+		consistent application interface that they all supported? Of
+		course it would.
+	</p>
+	<p>
+		Our set of links would probably be a <a
+			href="#UC6:_Aggregate_resources" title="">simple collection</a>.
+		The information held by any single organization might be a mix of
+		simple data and <a href="#UC6:_Aggregate_resources" title="">collections
+			of other data</a>, for example, a bank account balance and a
+		collection of historical transactions. Our bank might easily have
+		<a href="#Alternative_scenario:_create_a_nested_container"
+			title="">a collection of accounts for each of its collection
+			of customers</a>.
+	</p>
+	</section>
+	
+	<section>
+	<h2 id="story-oslc">System and Software Development
+			Tool Integration</h2>
+	<p>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:</p>
+	<ul>
+		<li>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.</li>
+		<li>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.”</li>
+		<li>Implement a central “hub” or “bus” that orchestrates the
+			broader business process by exploiting the APIs described
+			previously.</li>
+	</ul>
+	<p>
+		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. <a
+			href="http://open-services.net/" class="external text"
+			title="http://open-services.net/" rel="nofollow">OSLC</a>
+	</p>
+	</section>
+	
+	<section>
+	<h2 id="story-lld">Library Linked Data</h2>
+	<p>
+		The W3C Library Linked Data working group has a number of use
+		cases cited in their Use Case Report. <a
+			href="http://www.w3.org/2005/Incubator/lld/wiki/UseCaseReport"
+			class="external text"
+			title="http://www.w3.org/2005/Incubator/lld/wiki/UseCaseReport"
+			rel="nofollow">LLD-UC</a> 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.
+	</p>
+	<p>The 'Digital Objects Cluster' contains a number of relevant
+		use-cases:</p>
+	<ul>
+		<li>Grouping: This should "Allow the end-users to define <a
+			href="#UC6:_Aggregate_resources" title="">groups of resources</a>
+			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."
+		</li>
+	</ul>
+	<ul>
+		<li>Enrichment: "Enable end-users to <a
+			href="#UC4:_Update_existing_resource" title="">link resources
+				together</a>."
+		</li>
+	</ul>
+	<ul>
+		<li>Browsing: "<a href="#UC7:_Filter_resource_description"
+			title="">Support end-user browsing through groups</a> and
+			resources that belong to the groups."
+		</li>
+	</ul>
+	<ul>
+		<li>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."</li>
+	</ul>
+	<p>The 'Collections' cluster also contains a number of relevant
+		use-cases:</p>
+	<ul>
+		<li>Collection-level description: "Provide <a
+			href="#UC7:_Filter_resource_description" title="">metadata
+				pertaining to a collection as a whole</a>, in contrast to item-level
+			description."
+		</li>
+	</ul>
+	<ul>
+		<li>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."</li>
+	</ul>
+	<ul>
+		<li>Community information services: Identify and classify
+			collections of special interest to the community.</li>
+	</ul>
+	</section>
+	
+	<section>
+	<h2 id="story-meter-monitoring">Municipality Operational
+			Monitoring</h2>
+	<p>
+		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 <a
+			href="#UC3:_Retrieve_resource_description" title="">expose
+			data</a> 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.
+	</p>
+	</section>
+	
+	<section>
+	<h2 id="story-healthcare">Healthcare</h2>
+	<p>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.</p>
+	<p>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.</p>
+	</section>	
+	
+	<section>
+	<h2 id="story-media">Metadata Enrichment in Broadcasting</h2>
+	<p>
+		There are many different use cases when broadcasters show interest
+		in metadata <a href="#UC4:_Update_existing_resource" title="">
+			enrichment</a>:
+	</p>
+	<ul>
+		<li>enrich archive or news metadata by linking facts, events,
+			locations and personalities</li>
+		<li>enrich metadata generated by automatic extraction tools
+			such as person identification, etc.</li>
+		<li>enrich definitions of terms in classification schemes or
+			enumeration lists</li>
+	</ul>
+	<p>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).</p>
+	<p>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.</p>
+	</section>
+		
+	<section>
+	<h2 id="story-mashup">Aggregation and Mashups of Infrastructure Data</h2>
+	<p>
+		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 <a href="#UC6:_Aggregate_resources"
+			title="">aggregated</a>, <a
+			href="#UC7:_Filter_resource_description" title="">filtered</a>,
+		and visualized effectively. Specifically, the following use cases
+		need to be taken into account:
+	</p>
+	<ul>
+		<li>While some data sources are based on Linked Data, others
+			are not, and aggregation and mashups must work across these
+			different sources.</li>
+		<li>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.</li>
+		<li>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").</li>
+	</ul>
+	<p>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.</p>
+	</section>
+	
+	<section>
+	<h2 id="story-device">Sharing payload of RDF data among low-end devices</h2>
+	<p>
+		Several projects around the idea of <a
+			href="http://worldwidesemanticweb.wordpress.com/"
+			class="external text"
+			title="http://worldwidesemanticweb.wordpress.com/" rel="nofollow">downscaling
+			the Semantic Web</a> 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).
+	</p>
+	<p>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.</p>
+	</section>
+	
+	<section>
+	<h2 id="story-binary_and_etadata">Sharing Binary Resources and Metadata</h2>
+	<p>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, ...</p>
+	<p>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.</p>
+	<p>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.</p>
+	</section>
+	
+	<section>
+	<h2 id="story-data_cats">Data Catalogs</h2>
+	<p>
+		The Asset Description Metadata Schema (<a
+			href="http://joinup.ec.europa.eu/asset/adms/home"
+			class="external text"
+			title="http://joinup.ec.europa.eu/asset/adms/home" rel="nofollow">ADMS</a>)
+		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 <a
+			href="#UC5:_Determine_if_a_resource_has_changed" title="">
+			updated content</a> 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:
+	</p>
+	<ul>
+		<li>understand the data, i.e. understand their semantic
+			descriptions, and other systems.</li>
+		<li>seamlessly exchange the semantic assets metadata from
+			different repositories</li>
+		<li>keep itself up-to-date.</li>
+	</ul>
+	<p>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.</p>
+	<p>
+		Related: <a href="http://spec.datacatalogs.org/"
+			class="external text" title="http://spec.datacatalogs.org/"
+			rel="nofollow">Data Catalog Schema and Protocol</a>
+	</p>
+	</section>
+	
+	<section>
+	<h2 id="story-donstrained_devices">Constrained Devices and Networks</h2>
+	<p>
+		Information coming from resource constrained devices in the Web of
+		Things (<a href="http://en.wikipedia.org/wiki/Web_of_Things"
+			class="external text"
+			title="http://en.wikipedia.org/wiki/Web_of_Things" rel="nofollow">WoT</a>)
+		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 <a
+			href="http://datatracker.ietf.org/wg/6lowpan/"
+			class="external text"
+			title="http://datatracker.ietf.org/wg/6lowpan/" rel="nofollow">6LowPAN</a>
+		- IPv6 for resource constrained devices - and the Constrained
+		Application Protocol (<a
+			href="http://tools.ietf.org/html/draft-ietf-core-coap"
+			class="external text"
+			title="http://tools.ietf.org/html/draft-ietf-core-coap"
+			rel="nofollow">CoAP</a>), 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 <a
+			href="http://tools.ietf.org/html/draft-castellani-core-http-mapping"
+			class="external text"
+			title="http://tools.ietf.org/html/draft-castellani-core-http-mapping"
+			rel="nofollow">HTTP-CoAP Mapping</a> would enable constrained
+		devices to directly participate in a Linked Data-based
+		environment.
+	</p>
+	</section>
+	
+	<section>
+	<h2 id="story-process_of_science">Services Supporting the Process
+			of Science</h2>
+	<p>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.</p>
+	<ul>
+		<li><a href="#UC6:_Aggregate_resources" title="">Aggregations</a>,
+			specifically <i>Research Objects (ROs)</i> 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).</li>
+		<li>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.
+			<ul>
+				<li>Foundation services that collect and expose ROs for
+					storage, modification, exploration, and reuse.</li>
+				<li>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).</li>
+			</ul>
+		</li>
+	</ul>
+	<p>
+		seeAlso: <a href="http://www.wf4ever-project.org/"
+			class="external text" title="http://www.wf4ever-project.org/"
+			rel="nofollow">Wf4Ever</a>
+	</p>
+	</section>
+	
+	<section>
+	<h2 id="story-project_data">Project Membership Information: Information Evolution</h2>
+	<p>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.</p>
+	<p>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.</p>
+	<p>This could be achieved with:</p>
+	<ul>
+		<li>Resource descriptions for each person and project</li>
+		<li>A container resource to describe roles/membership in the
+			project.</li>
+	</ul>
+	<p>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".</p>
+	<p>Access to information has two aspects:</p>
+	<ul>
+		<li>Access to the "current" state, regardless of the version
+			of the resource description</li>
+		<li>Access to historical state, via access to a specific
+			version of the resource description</li>
+	</ul>
+	</section>
+	
+	<section>
+	<h2 id="story-cloud">Cloud Infrastructure Management</h2>
+	<p>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).</p>
+	<p>The IaaS scenario makes specific requirements on lifecycle
+		management and discovery, handling non-instant changes, history
+		capture and query:</p>
+	<ul>
+		<li>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.</li>
+		<li>It is often the case that attaining a new lifecycle state
+			is not instantaneous. Clients require a universal mechanism for
+			monitoring such changes.</li>
+		<li>A facility to retrieve all events in the lifecycle of a
+			resource can be useful.</li>
+		<li>Query provides the means to interrogate the resources
+			behind the API, as well as finding new entry points into the
+			application.</li>
+	</ul>
+	<p>Infrastructure management may be viewed as the manipulation
+		of the underlying graph of resources.</p>
+	</section>
+
 </section>
 
 <section>
 <h1 id="usecases">Use Cases</h1>
 
+	<p>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.</p>
+		
+	<section>
+	<h2 id="uc-manage_containers">Use Case: Manage containers</h2>
+	<p>
+		A number of user-stories introduce the idea of a <i>container</i>
+		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 <i>affordances</i>
+		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.
+	</p>
+	<ul>
+		<li>Provide "access guidance for ... resources" (affordances)
+			(from user-story, <a
+			href="#Maintaining_Social_Contact_Information" title="">Maintaining
+				Social Contact Information</a>).
+		</li>
+	</ul>
+	
+	<section>
+	<h3 id="scen-create_container">Primary scenario: create
+			container</h3>
+	<p>
+		Create a new container resource within the LDP server. In <a
+			href="#Services_Supporting_the_Process_of_Science" title="">Services
+			supporting the process of science</a>, <a
+			href="http://wf4ever.github.com/ro-primer/" class="external text"
+			title="http://wf4ever.github.com/ro-primer/" rel="nofollow">Research
+			Objects</a> 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 <a href="http://ceur-ws.org/Vol-903/paper-01.pdf"
+			class="external text"
+			title="http://ceur-ws.org/Vol-903/paper-01.pdf" rel="nofollow">scientific
+			workflows</a> 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.
+	</p>
+	<pre>
[email protected] ro:     http://purl.org/wf4ever/ro#
[email protected] dct:    http://purl.org/dc/terms/
[email protected] ore:    http://www.openarchives.org/ore/
+
+&lt;&gt; a ro:ResearchObject, ore:Aggregation ;
+    dct:created &quot;2012-12-01&quot;^^xsd:dateTime .
+ 
+</pre>
+	</section>
+	
+	<section>
+	<h3 id="scen-create_a_nested_container">Alternative scenario: create a
+			nested container</h3>
+	<p>
+		The motivation for nested containers comes from the <a
+			href="#System_and_Software_Development_Tool_Integration" title="">
+			System and Software Development Tool Integration</a> user-story. The
+		OSLC Change Management vocabulary allows bug reports to have
+		attachments referenced by the membership predicate
+		oslc_cm:attachment. The 'top-level-container' contains issues, and
+		each issue resource has its own container of attachment resources.
+	</p>
+	<pre>
[email protected] dcterms: &lt;http://purl.org/dc/terms/&gt;.
[email protected] rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
[email protected] oslc_cm: &lt;http://open-services.net/ns/cm#&gt;.
[email protected] : &lt;http://example.org/&gt;.
+
+:top-level-container rdfs:member :issue1234 .
+
+:issue1234 a oslc_cm:ChangeRequest;
+      dcterms:identifier &quot;1234&quot;;
+      dcterms:type &quot;a bug&quot;;
+      dcterms:related :issue1235 ;
+      oslc_cm:attachments :attachments123.
+
+:issue1235 a oslc_cm:ChangeRequest;
+      dcterms:title &quot;a related bug&quot;.
+
+:attachments a oslc_cm:AttachmentList;
+      oslc_cm:attachment :attachment324, :attachment251.
+ 
+</pre>
+	</section>
+	</section>
+	
+	<section>
+	<h2 id="uc-manage_resources">Use Case: Manage resources</h2>
+	<p>
+		This use-case addresses the managed lifecycle of a resource and is
+		concerned with resource <i>ownership</i>. 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.
+	</p>
+	<p>
+		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 <a
+			href="http://tools.ietf.org/html/rfc5023" class="external text"
+			title="http://tools.ietf.org/html/rfc5023" rel="nofollow">Atom
+			Publishing Protocol</a> slug header to convey a user defined naming
+		'hint'.
+	</p>
+	<ul>
+		<li>Non-duplication of resources: "Eliminate multiple
+			copies", representing resources in a single place (from <a
+			href="#Maintaining_Social_Contact_Information" title="">#Maintaining
+				Social Contact Information</a>).
+		</li>
+		<li>Distribution of resources: Linked aata "may be stored on
+			separate servers" (from <a
+			href="#Maintaining_Social_Contact_Information" title="">#Maintaining
+				Social Contact Information</a>).
+		</li>
+		<li>Consistent, global naming: Resources should be "linked to
+			consistently, ... instead of maintaining various identifiers in
+			different formats" (from <a
+			href="#Keeping_Track_of_Personal_and_Business_Relationships"
+			title="">#Keeping Track of Personal and Business
+				Relationships</a>).
+		</li>
+	</ul>
+	
+	<section>
+	<h3 id="scen-create_resource">Primary scenario: create resource</h3>
+	<p>
+		Resources begin life by being created within a container. From
+		user-story, <a href="#Maintaining_Social_Contact_Information"
+			title="">Maintaining Social Contact Information</a>, 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.
+	</p>
+	<p>
+		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 <a
+			href="http://www.foaf-project.org" class="external text"
+			title="http://www.foaf-project.org" rel="nofollow">FOAF</a>
+		vocabulary. A contact is represented here by a
+		foaf:PersonalProfileDocument defining a resource that can be
+		created and updated as a single-unit, even though it may describe
+		ancillary resources, such as a foaf:Person, below.
+	</p>
+	<pre>
[email protected] foaf:  &lt;http://xmlns.com/foaf/0.1/&gt; .
+
+&lt;&gt; a foaf:PersonalProfileDocument;
+	foaf:PrimaryTopic [ 
+		a foaf:Person;
+		foaf:name &quot;Timothy Berners-Lee&quot;;
+		foaf:title &quot;Sir&quot;;
+		foaf:firstName &quot;Timothy&quot;;
+		foaf:surname &quot;Berners-Lee&quot;;
+		foaf:nick &quot;TimBL&quot;, &quot;timbl&quot;;
+		foaf:homepage &lt;http://www.w3.org/People/Berners-Lee/&gt;;
+		foaf:weblog &lt;http://dig.csail.mit.edu/breadcrumbs/blog/4&gt;;
+		foaf:mbox &lt;mailto:[email protected]&gt;;
+		foaf:workplaceHomepage &lt;http://www.w3.org/&gt;.
+	]
+ 
+</pre>
+	</section>
+	
+	<section>
+	<h3 id="scen-delete_resource">Alternative scenario: delete
+			resource</h3>
+	<p>
+		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 "<a href="http://www.w3.org/TR/cooluris/|"
+			class="external text" title="http://www.w3.org/TR/cooluris/|"
+			rel="nofollow">Cool URIs don't change</a>", which implies that
+		deleted URIs shouldn't be recycled.
+	</p>
+	</section>
+	
+	<section>
+	<h3 id="scen-moving_contained_resources">Alternative scenario: moving
+			contained resources</h3>
+	<p>
+		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 <a
+			href="http://www.w3.org/DesignIssues/Architecture.html#HTTP"
+			class="external autonumber"
+			title="http://www.w3.org/DesignIssues/Architecture.html#HTTP"
+			rel="nofollow">[5]</a>, it is possible to indicate that a
+		resource has moved with an appropriate HTTP response.
+	</p>
+	</section>
+	</section>
+	
+	<section>
+	<h2 id="uc-retrieve_resource_description">Use Case: Retrieve resource
+			description</h2>
+	<p>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.</p>
+	<ul>
+		<li>Use standard vocabularies as appropriate to enable a
+			"common understanding of the resource" (from <a
+			href="#Maintaining_Social_Contact_Information" title="">Maintaining
+				Social Contact Information</a>).
+		</li>
+		<li>A "scalable linking model is key" (from <a
+			href="#Municipality_Operational_Monitoring" title="">#Municipality
+				Operational Monitoring</a>).
+		</li>
+	</ul>
+	
+	<section>
+	<h3 id="scen-fetch">Primary scenario</h3>
+	<p>
+		The user-story <a
+			href="#Project_Membership_Information_:_Information_Evolution"
+			title=""> Project Membership Information</a> 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 <a
+			href="http://www.epimorphics.com" class="external text"
+			title="http://www.epimorphics.com" rel="nofollow">Epimorphics</a>
+		<a href="http://www.epimorphics.com/public/vocabulary/org.html"
+			class="external text"
+			title="http://www.epimorphics.com/public/vocabulary/org.html"
+			rel="nofollow">organizational ontology</a>.
+	</p>
+	<p>Note that the example below defines two resources (shown as
+		separate sections below) that will be hosted on an LDP based at
+		http://example.com/. The representations of these resources may
+		include descriptions of related resources, such as
+		http://www.w3.org/, that that fall under a different authority and
+		therefore can't be served from the LDP at this location.</p>
+	<pre>
[email protected] org: &lt;http://www.w3.org/ns/org#&gt; .
[email protected] owltime: &lt;http://www.w3.org/2006/time&gt; .
[email protected] xsd: &lt;http://www.w3.org/2001/XMLSchema#&gt; .
[email protected] &lt;http://example.com/&gt; .
+     
+&lt;member1&gt; a org:Membership ;
+	org:member &lt;http://www.w3.org/People/Berners-Lee/card#i&gt; ;
+	org:organization http://www.w3.org/&gt; ;
+	org:role &lt;director&gt; ;
+	org:memberDuring [a owltime:Interval; owltime:hasBeginning [
+		owltime:inXSDDateTime &quot;1994-10-01T00:00:00Z&quot;^^xsd:dateTime]] .
+
+&lt;http://www.w3.org/&gt; a org:FormalOrganization ;
+	skos:prefLabel &quot;The World Wide Web Consortium&quot;@en ;
+	skos:altLabel &quot;W3C&quot; .
+ 
+</pre>
+					<pre>
[email protected] org: &lt;http://www.w3.org/ns/org#&gt; .
[email protected] rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt; .
[email protected] &lt;http://example.com/&gt; .
+
+&lt;director&gt; a org:Role ;
+	rdfs:label &quot;Director&quot; .
+ 
+</pre>
+	</section>
+	
+	<section>
+	<h3 id="scen-alt_non-document_resource">Alternative scenario: retrieve
+			description of a non-document resource</h3>
+	<p>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.</p>
+	<pre>
[email protected] &lt;http://www.w3.org/People/Berners-Lee/card&gt;
[email protected] foaf: &lt;http://xmlns.com/foaf/0.1/&gt;.
[email protected] dc: &lt;http://purl.org/dc/elements/1.1/&gt;.
+
+&lt;&gt; a foaf:PersonalProfileDocument ;
+	dc:title &quot;Tim Berners-Lee's FOAF file&quot; ;
+	foaf:homepage &lt;http://www.w3.org/People/Berners-Lee/&gt; ;
+	foaf:primaryTopic &lt;#i&gt; .
+ 
+</pre>
+	</section>
+	</section>
+	
+	<section>
+	<h2 id="uc-update_existing">Use Case: Update existing resource</h2>
+	<p>
+		Change the RDF description of a LDP resource, potentially removing
+		or overwriting existing data. This allows applications to <i>enrich</i>
+		the representation of a resource by addling additional links to
+		other resources.
+	</p>
+	<ul>
+		<li>Unrestricted vocabulary: It should be possible be "able
+			to add ... application-specific data" to resources (from <a
+			href="#Maintaining_Social_Contact_Information" title="">#Maintaining
+				Social Contact Information</a>).
+		</li>
+	</ul>
+	
+	<section>
+	<h3 id="scen-update_enrichment">Primary scenario: enrichment</h3>
+	<p>
+		This relates to user-story <a
+			href="#Metadata_Enrichment_in_Broadcasting" title="">
+			Metadata Enrichment in Broadcasting</a> and is based on the <a
+			href="http://www.bbc.co.uk/ontologies/sport/"
+			class="external text"
+			title="http://www.bbc.co.uk/ontologies/sport/" rel="nofollow">BBC
+			Sports Ontology</a>. The <i>resource-centric</i> 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.
+	</p>
+	<pre>
[email protected] sport: &lt;http://www.bbc.co.uk/ontologies/sport/&gt; .
[email protected] rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt; .
+ 
+ :mens_sprint a sport:MultiStageCompetition;
+    rdfs:label &quot;Men's Sprint&quot;;
+    sport:award &lt;#gold_medal&gt; .
+
+&lt;#gold_medal&gt; a sport:Award .
+ 
+</pre>
+	<p>We can enrich the description as events unfold, linking to
+		the winner of the gold medal by substituting the above description
+		with the following.</p>
+	<pre>
[email protected] sport: &lt;http://www.bbc.co.uk/ontologies/sport/&gt; .
[email protected] rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt; .
[email protected] foaf: &lt;http://xmlns.com/foaf/0.1/&gt; .
+ 
+ :mens_sprint a sport:MultiStageCompetition;
+    rdfs:label &quot;Men's Sprint&quot;;
+    sport:award &lt;#gold_medal&gt; .
+&lt;#gold_medal&gt; a sport:Award; 
+    sport:awarded_to [
+        a foaf:Agent ;
+        foaf:name &quot;Chris Hoy&quot; .
+    ] .
+ 
+</pre>
+	</section>
+	
+	<section>
+	<h3 id="scen-alt_selective_update">Alternative scenario: selective
+			update of a resource</h3>
+	<p>
+		This relates to user-story <a href="#Data_Catalogs" title="">Data
+			Catalogs</a>, based on the <a href="http://vocab.deri.ie/dcat"
+			class="external text" title="http://vocab.deri.ie/dcat"
+			rel="nofollow">Data Catalog Vocabulary</a>. A catalogue is
+		described by the following RDF model.
+	</p>
+	<pre>
[email protected] dcat: &lt;http://www.w3.org/ns/dcat#&gt;	.
[email protected] dcterms: &lt;http://purl.org/dc/terms/&gt; .
+   
+ :catalog a dcat:Catalog ;
+    dcat:dataset :dataset/001;
+    dcterms:issued &quot;2012-12-11&quot;^^xsd:date.
+ 
+</pre>
+	<p>
+		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 <i>changeset</i> <a
+			href="http://docs.api.talis.com/getting-started/changesets"
+			class="external autonumber"
+			title="http://docs.api.talis.com/getting-started/changesets"
+			rel="nofollow">[6]</a><a
+			href="http://www.w3.org/2009/12/rdf-ws/papers/ws07"
+			class="external autonumber"
+			title="http://www.w3.org/2009/12/rdf-ws/papers/ws07"
+			rel="nofollow">[7]</a> could be used to add a new dc:title to the
+		dataset. The following update would be directed to the catalogue
+		to add an additional dataset.
+	</p>
+	<pre>
[email protected] : &lt;http://example.com/&gt;.
[email protected] dcterms: &lt;http://purl.org/dc/terms/&gt; .
[email protected] cs: &lt;http://purl.org/vocab/changeset/schema#&gt; .
[email protected] rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
+
+&lt;change1&gt;
+  a cs:ChangeSet ;
+  cs:subjectOfChange :catalog ;
+  cs:createdDate &quot;2012-01-01T00:00:00Z&quot; ;
+  cs:changeReason &quot;Update catalog datasets&quot; ;
+  cs:addition [
+    a rdf:Statement ;
+    rdf:subject :catalog ;
+    rdf:predicate dcat:dataset ;
+    rdf:object :dataset/002 .
+  ] .
+ 
+</pre>
+	</section>
+	</section>
+	
+	<section>
+	<h2 id="uc-has_resource_changed">Use Case: Determine if a resource has
+			changed</h2>
+	<p>
+		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 <i>conditional</i>
+		requests to ensure they are only applied if the version is
+		unchanged.
+	</p>
+	
+	<section>
+	<h3 id="scen-primary_has_changed">Primary scenario</h3>
+	<p>
+		Based on the user-story, <a
+			href="#Constrained_Devices_and_Networks" title="">
+			Constrained Devices and Networks</a>, an LDP could be configured to
+		act as a proxy for a <a
+			href="http://tools.ietf.org/html/draft-ietf-core-coap"
+			class="external text"
+			title="http://tools.ietf.org/html/draft-ietf-core-coap"
+			rel="nofollow">CoAP</a> based <a
+			href="http://en.wikipedia.org/wiki/Web_of_Things"
+			class="external text"
+			title="http://en.wikipedia.org/wiki/Web_of_Things" rel="nofollow">Web
+			of Things</a>. 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.
+	</p>
+	<p>
+		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 <a
+			href="http://www.w3.org/2005/Incubator/ssn/"
+			class="external text"
+			title="http://www.w3.org/2005/Incubator/ssn/" rel="nofollow">Semantic
+			Sensor Network</a> ontology.
+	</p>
+	<pre>
[email protected] : &lt;http://example.com/energy-management/&gt;.
+
+&lt;&gt; a :MainsFrequencySensor;
+  rdfs:comment &quot;Sense grid load based on mains frequency&quot;;
+  ssn:hasMeasurementCapability [
+	a :FrequencyMeasurementCapability;
+	ssn:hasMeasurementProperty &lt;#property_1&gt; .
+  ] .
+ 
+</pre>
+	<p>
+		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, <i>without</i> necessarily having to
+		download the RDF representation. As different sensor properties
+		are represented disjointly (separate RDF representations) they may
+		change independently.
+	</p>
+	<pre>
[email protected] : &lt;http://example.com/energy-management/&gt;.
+
+&lt;http://example.com/energy-management#property_1&gt; :hasMeasurementPropertyValue &lt;&gt; .
+&lt;&gt; a :FrequencyValue;
+	:hasQuantityValue &quot;50&quot;^^xsd:float.
+ 
+</pre>
+	</section>
+	</section>
+	
+	<section>
+	<h2 id="uc-aggregate_resources">>Use Case: Aggregate resources</h2>
+	<p>
+		There is a requirement to be able to manage <i>collections</i> 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.
+	</p>
+	<ul>
+		<li>Resource descriptions are a "mix of simple data and
+			collections" (from <a
+			href="#Keeping_Track_of_Personal_and_Business_Relationships"
+			title="">#Keeping Track of Personal and Business
+				Relationships</a>).
+		</li>
+		<li>Relative URIs: It should be possible to "ship payloads of
+			RDF" for a collection as a whole without breaking internal links
+			(from <a href="#Constrained_Devices_and_Networks" title="">#Constrained
+				Devices and Networks</a>).
+		</li>
+	</ul>
+	
+	<section>
+	<h3 id="scen-add_a_resource_to_a_collection">Primary scenario: add a resource
+			to a collection</h3>
+	<p>
+		This example is from <a href="#Library_Linked_Data" title="">Library
+			Linked Data</a> and <a
+			href="http://www.w3.org/2005/Incubator/lld/wiki/UseCaseReport"
+			class="external text"
+			title="http://www.w3.org/2005/Incubator/lld/wiki/UseCaseReport"
+			rel="nofollow">LLD-UC</a>, specifically <a
+			href="http://www.w3.org/2005/Incubator/lld/wiki/Use_Case_Subject_Search"
+			class="external text"
+			title="http://www.w3.org/2005/Incubator/lld/wiki/Use_Case_Subject_Search"
+			rel="nofollow">Subject Search</a>.
+	</p>
+	<p>There is an existing collection at
+		&lt;http://example.com/concept-scheme/subject-heading&gt; 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 skos:inScheme 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.</p>
+	<pre>
[email protected] scheme : &lt;http://example.com/concept-scheme/&gt;.
[email protected] concept : &lt;http://example.com/concept/&gt;.
+
+scheme:subject-heading a skos:ConceptScheme.
+
+concept:Outer+space+Exploration skos:inScheme scheme:subject-heading.
+ 
+</pre>
+	</section>
+	
+	<section>
+	<h3 id="scen-add_a_resource_to_multiple_collections">Alternative scenario: add a
+			resource to multiple collections</h3>
+	<p>
+		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 <i>aggregation</i>. 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.
+	</p>
+	<p>
+		As a machine-readable collection of medical terms, the <a
+			href="http://www.ihtsdo.org|" class="external text"
+			title="http://www.ihtsdo.org|" rel="nofollow">SNOMED</a> ontology
+		is of key importance in <a href="#Healthcare" title="">
+			healthcare</a>. 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.
+	</p>
+	<pre>
[email protected] : &lt;http://example.com/snomed/&gt;.
+
+:_119376003 a skos:Concept ;
+	skos:prefLabel &quot;Tissue specimen&quot;
+	skos:narrowerTransitive :TissueSpecimenFromHeart.
+   
+:_127462005 a skos:Concept ;
+	skos:prefLabel &quot;Specimen from heart&quot;
+   skos:narrowerTransitive :TissueSpecimenFromHeart.
+
+:_128166000 a skos:Concept;
+	rdfs:label &quot;Tissue specimen from heart&quot;.
+ 
+</pre>
+	</section>
+	</section>
+	
+	<section>
+	<h2 id="uc-filter_resource_description">Use Case: Filter resource description</h2>
+	<p>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.</p>
+		
+	<section>
+	<h3 id="scen-retrieve_collection-level_description">Primary scenario: retrieve
+			collection-level description</h3>
+	<p>
+		This scenario, based on <a href="#Library_Linked_Data" title="">
+			Library Linked Data</a>, uses the Dublin Core Metadata Initiative <a
+			href="http://dublincore.org/groups/collections/collection-application-profile/|"
+			class="external text"
+			title="http://dublincore.org/groups/collections/collection-application-profile/|"
+			rel="nofollow">Collection-Level</a> 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.
+	</p>
+	<pre>
[email protected] rdf: &lt;rdf=&quot;http://www.w3.org/1999/02/22-rdf-syntax-ns#&quot;&gt;.
[email protected] dc: &lt;http://purl.org/dc/elements/1.1/&gt;.
[email protected] : &lt;http://example.org/bookshelf/&gt;.
[email protected] dcmitype: &lt;http://purl.org/dc/dcmitype/&gt;.
[email protected] cld: &lt;http://purl.org/cld/terms/&gt;.
[email protected] dcterms: &lt;http://purl.org/dc/terms/&gt;.
+ 
+&lt;&gt; dc:type dcmitype:Collection ;
+	dc:title &quot;Directory of organizations working with Linked Data&quot; ;
+	dcterms:abstract &quot;This is a directory of organisations specializing in Linked Data.&quot;
+	cld:isLocatedAt &lt;http://dir.w3.org&gt;
+	cld:isAccessedVia &lt;http://dir.w3.org/rdf/2012/directory/directory-list.xhtml?construct&gt;
+ 
+</pre>
+	</section>
+	
+	<section>
+	<h3 id="scen-retrieve_item-level_description_of_a_collection">Alternative scenario: retrieve
+			item-level description of a collection</h3>
+	<p>
+		This use-case scenario, also based on <a
+			href="#Library_Linked_Data" title=""> Library Linked Data</a>,
+		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
+		rdfs:member, 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 (<a
+			href="http://www.ifla.org/publications/functional-requirements-for-bibliographic-records"
+			class="external text"
+			title="http://www.ifla.org/publications/functional-requirements-for-bibliographic-records"
+			rel="nofollow">FRBR</a>) <a
+			href="http://vocab.org/frbr/core.html" class="external text"
+			title="http://vocab.org/frbr/core.html" rel="nofollow">ontology</a>.
+	</p>
+	<pre>
[email protected] frbr: &lt;http://purl.org/vocab/frbr/core#&gt;.
+
+&lt;&gt; rdfs:member &lt;#ebooks97&gt;, &lt;#ebooks21279&gt;.
+
+&lt;#work97&gt; a frbr:LiteraryWork;
+   dc:title &quot;Flatland: a romance of many dimensions&quot; ;
+	frbr:creator &lt;#Abbott_Edwin&gt;;
+	frbr:manifestation &lt;ebook97&gt;.
+ 
+&lt;#work21279&gt; a frbr:LiteraryWork;
+	dc:title &quot;2 B R 0 2 B&quot; ;
+	frbr:creator &lt;#Vonnegut_Kurt&gt;;
+	frbr:manifestation &lt;ebook21279&gt;.
+ 
+</pre>
+	<p>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).</p>
+	</section>
+	</section>
+	
+	<section>
+	<h2 id="uc-manage_media_resources">UC8: Manage media resources</h2>
+	<p>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.</p>
+		
+	<section>
+	<h3 id="scen-access_media_resources">Primary scenario: access media
+			resources</h3>
+	<p>
+		From the User Story <a
+			href="#Sharing_Binary_Resources_and_Metadata" title="">
+			Sharing Binary Resources and Metadata</a> 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.
+	</p>
+	<p>
+		This example uses the <a
+			href="http://www.w3.org/TR/mediaont-10/#ont-ttl"
+			class="external text"
+			title="http://www.w3.org/TR/mediaont-10/#ont-ttl" rel="nofollow">Ontology
+			for Media Resources</a> to describe a media resource added to a
+		collection.
+	</p>
+	<pre>
[email protected] ma: &lt;http://www.w3.org/ns/ma-ont#&gt; .
+
+&lt;dataset&gt; a ma:Collection ;
+	:hasMember &lt;dataset/image1.jpg&gt;
+
+&lt;dataset/image1.jpg&gt; a ma:MediaResource ;
+	ma:hasFormat &quot;image/jpeg&quot; .
+ 
+</pre>
+	</section>
+	
+	<section>
+	<h3 id="Alternative_scenario:_media-resource_attachments">Alternative scenario:
+			media-resource attachments</h3>
+	<p>
+		A resource may have multiple <i>renditions</i>; 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.
+	</p>
+	</section>
+	</section>
 </section>
 
 <section>
 <h1 id="reqs">Requirements</h1>
 
+<section>
+	<h2 id="reqs-functional">Functional Requirements</h2>
+	<ol>
+		<li>Create Containers, from <a href="#UC1:_Manage_containers"
+			title="">#UC1: Manage containers</a>
+		</li>
+		<li>Creation of nested containers, from <a
+			href="#UC1:_Manage_containers" title="">#UC1: Manage
+				containers</a>
+		</li>
+		<li>Creation of resources (within a container), from <a
+			href="#UC2:_Manage_resources" title="">#UC2: Manage resources</a>
+		</li>
+		<li>Deletion of resources, from <a
+			href="#UC2:_Manage_resources" title="">#UC2: Manage resources</a>
+		</li>
+		<li>Moving contained resources, from <a
+			href="#UC2:_Manage_resources" title="">#UC2: Manage resources</a>
+		</li>
+		<li>Retrieve resource description, from <a
+			href="#UC3:_Retrieve_resource_description" title="">#UC3:
+				Retrieve resource description</a>
+		</li>
+		<li>Retrieve description of a non-document resource, from <a
+			href="#UC3:_Retrieve_resource_description" title="">#UC3:
+				Retrieve resource description</a>
+		</li>
+		<li>Enrichment (substituting update of existing resource),
+			from <a href="#UC4:_Update_existing_resource" title="">#UC4:
+				Update existing resource</a>
+		</li>
+		<li>Selective update of a resource, from <a
+			href="#UC4:_Update_existing_resource" title="">#UC4: Update
+				existing resource</a>
+		</li>
+		<li>Determine if a resource has changed, from <a
+			href="#UC5:_Determine_if_a_resource_has_changed" title="">#UC5:
+				Determine if a resource has changed</a>
+		</li>
+		<li>Add a resource to a collection, from <a
+			href="#UC6:_Aggregate_resources" title="">#UC6: Aggregate
+				resources</a>
+		</li>
+		<li>Add a resource to multiple collections, from <a
+			href="#UC6:_Aggregate_resources" title="">#UC6: Aggregate
+				resources</a>
+		</li>
+		<li>Retrieve collection-level description, from <a
+			href="#UC7:_Filter_resource_description" title="">#UC7:
+				Filter resource description</a>
+		</li>
+		<li>Retrieve item-level description of a collection, from <a
+			href="#UC7:_Filter_resource_description" title="">#UC7:
+				Filter resource description</a>
+		</li>
+		<li>Access media resources, from <a
+			href="#UC8:_Manage_media_resources" title="">#UC8: Manage
+				media resources</a>
+		</li>
+		<li>Media-resource attachments, from <a
+			href="#UC8:_Manage_media_resources" title="">#UC8: Manage
+				media resources</a>
+		</li>
+	</ol>
+	</section>
+	
+	<section>
+	<h2 id="reqs-non-functional">Non-Functional Requirements</h2>
+	<ol>
+		<li>Provide access guidance to resources, from <a
+			href="#UC1:_Manage_containers" title="">#UC1: Manage
+				containers</a>
+		</li>
+		<li>Non-duplication of resources, from <a
+			href="#UC2:_Manage_resources" title="">#UC2: Manage resources</a>
+		</li>
+		<li>Distribution of resources, from <a
+			href="#UC2:_Manage_resources" title="">#UC2: Manage resources</a>
+		</li>
+		<li>Consistent, global naming, from <a
+			href="#UC2:_Manage_resources" title="">#UC2: Manage resources</a>
+		</li>
+		<li>Use standard vocabularies as appropriate, from <a
+			href="#UC3:_Retrieve_resource_description" title="">#UC3:
+				Retrieve resource description</a>
+		</li>
+		<li>Scalable linking model, from <a
+			href="#UC3:_Retrieve_resource_description" title="">#UC3:
+				Retrieve resource description</a>
+		</li>
+		<li>Unrestricted vocabulary, from <a
+			href="#UC4:_Update_existing_resource" title="">#UC4: Update
+				existing resource</a>
+		</li>
+		<li>Resource descriptions are a "mix of simple data and
+			collections", from <a href="#UC6:_Aggregate_resources" title="">#UC6:
+				Aggregate resources</a>
+		</li>
+		<li>Relative URIs enabling sharing of collections, from <a
+			href="#UC6:_Aggregate_resources" title="">#UC6: Aggregate
+				resources</a>
+		</li>
+	</ol>
+	</section>
 </section>
 
 
@@ -148,6 +1740,7 @@
 <h1>Change History</h1>
 <ul>
 	<li>2012-12-14 - Initial ReSpec'ing framework for <a href="http://www.w3.org/2012/ldp/wiki/Use_Cases_And_Requirements">Workgroup working wiki document</a> (SS)</li>
+	<li>2012-12-16 - Pulled in and ReSpec'd content from <a href="http://www.w3.org/2012/ldp/wiki/Use_Cases_And_Requirements">Workgroup working wiki document</a> (SS)</li>
 </ul></section>
     
   </body>