--- 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>
+@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 .
+
+</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>
+@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.
+
+</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>
+@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/>.
+ ]
+
+</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>
+@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" .
+
+</pre>
+ <pre>
+@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" .
+
+</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>
+@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> .
+
+</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>
+@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 .
+
+</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>
+@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" .
+ ] .
+
+</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>
+@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.
+
+</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>
+@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 .
+ ] .
+
+</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>
+@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> .
+ ] .
+
+</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>
+@prefix : <http://example.com/energy-management/>.
+
+<http://example.com/energy-management#property_1> :hasMeasurementPropertyValue <> .
+<> a :FrequencyValue;
+ :hasQuantityValue "50"^^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
+ <http://example.com/concept-scheme/subject-heading> 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>
+@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.
+
+</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>
+@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".
+
+</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>
+@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>
+
+</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>
+@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>.
+
+</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>
+@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" .
+
+</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>