e-Framework Service Usage Model Name

Provide a simple, informative name for the Service Usage Model (SUM).

Name:

JISC Design for Learning sharing SUM

Alternative Names:

Design for Learning Shared Resources, DfL sharing solution

Version

Provide the e-Framework Service Usage Model Version for this description.

1.0

Version History

Include requested information about all versions of this document.

Version	Date	Author	Description	Organization / Project
1.0	17/9/2007	W. G. Kraan	Initial Draft	JISC-CETIS

Rationale

Briefly summarise the intended use of the SUM; justify including it in the e-Framework.

The DfL sharing solution is a lightweight and community focussed means of building a resource collection online. It's salient characteristics are that it is built collaboratively, is designed to work alongside a range of other sharing solutions, and is non-deterministic in structure and metadata scheme. Also, because it requires practically no investment on the part of the community, yet is not dependent on a single webservice provider either, the solution could be useful for other communities with heterogeneous resource sets that are also used by various other, non-overlapping communities.

Classification

Type an "X" in the brackets next to the most appropriate choice for each category. Required categories are shown in Bold; any non-required categories that are not used may be deleted.

To be provided by the submitter:

SUM Type	[X] Domain	[ ] CORE (a commonly recurring SUM; designation requires e-Framework Integrity Group approval)
Domain(s)	[ ] Learning & Teaching	[ ] Research [ ] Libraries	[ ] Administration [ ] IT Services	[X] Common
Maturity	[X] Immature	[ ] Mature
Purpose(s)	[X] Exemplar	[ ] Application	[ ] Modelling	[ ] Toolkit
XOR (exclusive "or‚")	[X] Service Genres	[ ] Service Expressions
Development Status	[ ] Proposed	[X] Developmental	[ ] Prototype	[ ] Production
Deployment Scale	[X] Isolated	[ ] Ubiquitous
State Behaviour	[ ] Stateful	[X] Stateless
Transactional Behaviour	[ ] Transactional and ACID	[ ] Transactional but Non ACID	[X] Non-Transactional
Batch Behaviour(s)	[X] Individual	[ ] Batch
Time-Constraint Behaviour	[ ] Hard Real Time	[ ] Soft Real Time	[X] None
Service End Point	[ ] Provider	[ ] Requestor	[ ] Transcoder (both requests and provides)
Authentication/Authorization Dependency	[X] Auth-Dependent	[ ] Auth-Independent
Protocol Binding(s) (only applies to service expression-based SUMs)	[X] Web Service [ ] SOAP	[X] REST [X] HTTP	[ ]Other

To be determined by the e-Framework:

Status	[ ] Approved	[ ] Placeholder [ ] Unapproved	[ ] Superseded [ ] Withdrawn
Confidence Level	[ ] High	[ ] Medium	[ ] Low

Notation [optional]

List and explain the conventions and terminology used that are essential for understanding the rest of the Service Usage Model description. A complete list of terms should be included in the Glossary (below).

<type text here>

Description

Write an informal, non-technical narrative describing what the Service Usage Model does and how it does it: the problem it addresses and its intended function, business-level capabilities and basic workflow.

The Design for Learning resource sharing SUM outlines how a community can create a single, coherent view on a set of heterogeneous resources. A common problem when setting up such sharing solutions is the fact that resources very often need to live in multiple collections at the same time. These collections are often gathered in very different tools (e.g. repositories), and are subject to different metadata and other sharing policies that are specific to the communities that own the collections.

Rather than duplicate the resources in another stand-alone repository, the Design for Learning resource sharing SUM solves the multiple collection problem by a) leaving the resources in whichever repository the author wishes to deposit them, and b) relying on the lowest common denominator between these repositories: the availability of a URI that points either to the resource or a description of it.

Users can record these URIs as bookmarks in a single account on a bookmarking service. A single agreed tag for the resources identifies them, while a set of tags from three vocabularies offers a starting point for the collaborative structuring of the collection. The result is displayed in a number of ways in a feed aggregator that is embedded in a wiki.

Business Process Modelling

Summarise the business analysis motivating the Service Usage Model and provide a link to the full analysis. Then outline the business function(s) and process(es) that the Service Usage Model supports to provide context for its Functionality, but do not go into detail about system functions, services or workflows.

1. Bookmarking Configuration

• Register Bookmarking system account. A username and password are obtained from a bookmarking system by sharing initiator.

• Share account details with community The account details are communicated to all members of the community by sharing initiator.

• Share community specific resource tag The tag is communicated to all members of the community by sharing initiator. It uniquely identifies resources to be collected by the community. It also enables community members to use their own accounts with the same service.

2. Content Management

• Determine tag vocabularies The sharing initiator and one or more community members select one or more vocabularies for the initial tag set.

• Prime the community collection The sharing initiator and one or more community members add a few exemplar resources by bookmarking them. This will also make the tagsets available in the bookmarking system.

• Add resource to community collection Community members add their own resources to the collection by bookmarking them using a variety of clients.

• Edit resource tags Community members can add new tags to the collection by adding them to any resource

• Rename tag Following consensus, existing tags can be renamed across the collection by any community member

3. Discovery

• Render collection The collections is rendered in the community's web presence by picking up a feed from the bookmarking system.

• Structure collection rendering Depending on the evolution of the tag set on the bookmarking system, the collection can be filtered on any characteristic.

• Alert users to new resource Members of the community can subscribe to collection specific feeds using their own feed aggregators.

SUM Diagram

Provide a diagram that is similar to the Generic SUM diagram used on the e-Framework website. Include only the SUM diagram here; the narrative explaining the diagram belongs in "Structure & Organisation‚". When submitting this completed document, also upload the diagram graphics as a separate file, or combine the file with this document to upload as a ZIP file.

Usage Scenarios [optional]

Briefly describe one or more applications that use the Service Usage Model or give examples of business scenarios that use the SUM’s workflows.

<type text here>

Applicability [optional]

Provide a detailed explanation about how and when the Service Usage Model is to be used or not used; include specific constraints and assumptions.

<type text here>

Functionality

Outline the individual system functions that the Service Usage Model provides in terms of workflows, messages, and data (documents); include constraints and conditions but do not include implementation-specific information. If appropriate, include an illustration of the workflows, related data and processes.

Make sharing solution available

1. Account creation

• the system receives a username and password

• the system returns an account URL

2. Collection tag registration

• A member of the community authenticates to the system in order to access the account

• The system receives a URI that identifies a collection resource and a tag that identifies the collection

• The system stores the URI, the collection tag and their association to each other and the account

• The system returns a URI that lists all resources associated with the collection tag as a feed and optionally visually as well.

3. Account dissemination

• A member of the community sends the account credentials and the collection tag to all other members of the community

Content Management

4. Add resource

• A member of the community authenticates to the system in order to access the account

• The system returns a list of resource URIs and associated tags (the collection tags and others)

• The system receives a URI that identifies a new collection resource, the tag that identifies the collection, and an unbounded number of other tags

• The system stores the URI, the tags, their association to each other and the account

• The system returns separate URIs that list all resources associated with any combination of submitted tags as a feed

5. Manage tags

• A member of the community authenticates to the system in order to access the account

• The system receives a request to dissociate a tag from a resource URI

• The system removes the tag to resource URI association in its store

• The system receives a request to add a tag to a resource URI

• The system stores the tag (if new) and associates it to the resource URI in its store

• The system receives a request to rename a tag x to y across all the resources gathered in the account

• The system substitutes all instances of the x tag with instances of the y tag across all resources gathered in the account

• The system returns separate URIs that list all resources associated with any combination of submitted tags as a feed

Present collection

6. Configure web presence

• A member of the community with suitable credentials authenticates to the community's web presence

• The web presence establishes the member's authority to edit web content in the community's web presence

• The web presence receives the URI that lists all resources associated with the collection tag as a feed

• The web presence returns a visual rendition of the list of all resources associated with the collection tag

• Optionally, the web presence receives the separate URIs that lists all resources associated with a combination of the collection tag and any other tags as feeds

• The web presence returns a visual rendition of the list of all resources associated with the collection tag, as structured by the choice of additional tags

7. Obtain resources

• A web user accesses the community's web presence to see the resource listing

• The web user selects a resource from the list by selecting the resource URI, after which either

1. The resource gets returned directly to the user's browser

1. The user gets directed to a page that describes the resource, including means of obtaining a representation

Structure & Organisation

Outline the services, data sources and choreography that underlie all the individual functionalities in the Service Usage Model. Describe how the functions are integrated at the service level as a whole system.

Account creation

Account creation is done within a trust zone, via a web user interface. The user credentials (username, password) are stored within the zone, along with an identifier. The credentials have a one to one relationship with authorisation role: for the purposes of the SUM, everyone is a user, and has only got access to the associated bookmarking account. As a variation, some bookmarking systems may accept OpenID credentials to establish an account, and authenticate against it.

Collection tag registration and resource addition

Is done via a web user interface or via an instance of the 'Add {bookmark}' service genre. The data transferred consists of the resource URL, a comment and one or more tags are part of the request (post authentication). Along with an account association, that data is stored in a central bookmark store.

Account dissemination

Community members can be notified of account and collection tag details via an instance of the Alert genre, or instances of the Email or Messaging genres.

Manage tags

Tags can be managed via instances of the Annotate, Classify and Add {bookmark} service genres, or web user interface equivalents. Annotate is used where comments associated with a community collection resource are manipulated, Classify in uses where only the tags associated with community collection resource are manipulated, and Add {bookmark} in uses where URIs that identify community collection resources are manipulated.

In each case, the comments, tags, and resource URIs are stored in a central bookmark store.

Configure and render collection

The community web presence can have its own authentication and authorisation system. The web presence has a client implementation of an Syndicate service genre. It connects to providing instances of the Syndicate service genre that exposes the contents of the central bookmark store.

Obtain resources

The web applications that store the community's resources are assumed to provide their own authentication and authorisation functionality. It is, however, expected that they will be able to provide a publicly accessible web page that describes the resource.

Applicable Standards [recommended]

List the standards that pertain to the functionality of the Service Usage Model as a whole; provide the name, version and citation link (to the  JISC Standards Catalogue if possible). Note any conformance requirements and extensions.

Syndicate

 RSS

or

 Atom

Authentication

 HTTP basic authentication

Design Decisions & Tradeoffs [optional]

Describe the decisions involved in designing the Service Usage Model. Limit the discussion to the design of the overall Service Usage Model; do not discuss internal details of the services or specific applications.

The main trade-off in this SUM is the decision to share one bookmarking account with many users. The advantage is that it is likely to ease the participation of those members of the community who do not have experience of bookmarking services. The reason for this is twofold: it bypasses the signing-up phase, and, more importantly, it allows the current tag set to be pre-populated in bookmarking user interfaces. This means that the tags the community have agreed on are visible, and just a click away.

The disadvantage of a shared account is that it can lead to control issues (people performing edits on the resources, comments or tags that are not universally appreciated). Fortunately, implementors of the SUM don't have to choose between the single or multiple account variants at implementation time: it will work with either or both at any time.

Likewise, it is possible to construct a very similar SUM to the Design for Learning with multiple bookmark stores. In the interest of simplicity, that variant has been left out of scope here.

Implementation Guidance & Dependencies [optional]

Describe all anticipated issues that may affect the implementation of applications that use the Service Usage Model, such as the organisation, performance, behaviours, representations and policies.

The most likely implementation route for functions 1, 2, 4 and 5 is on an existing, third party web bookmarking application such as del.icio.us, furl, and digg or clones of the same. There are a number of issues to consider when choosing between them:

• Can the bookmarks be (legally!) exported from the bookmark store, and if so, in what format?

• Does the bookmarking web app provide Add {bookmark}, Annotate and Categorise service genre instances or just web user interfaces?

• Are the service expressions subject to IPR restrictions?

• Are there hosted clones of the web app, and/or is an open source implementation of the web app available?

Known Uses [optional]

List the known implementations or uses of the Service Usage Model by any applications or systems. List other Service Usage Models that incorporate, use or are dependent on this Service Usage Model.

An implementation is currently under construction in the JISC  Design for Learning support web presence.

Data Sources Used

Provide the names and descriptions of all data sources used in the Service Usage Model.

User attributes and credentials

At least one store is used to control access to the bookmark store. An optional other is used to control access to the community's web presence.

Bookmark store

One central store that persists the association between a resource URI, comments, tags and user accounts.

Feed aggregator

The feeds that are derived from the central bookmark store data are persisted in the community web presence, and synchronised at regular intervals.

Related SUMs [optional]

List the names and versions of other Service Usage Models that are used within this Service Usage Model to build the functionality.

<type text here>

Services Used

List the names and versions of the Service Genres XOR Service Expressions that this Service Usage Model is based on.

• Add {bookmark}

• Annotate

• Categorise

• Syndicate

CORE SUMs Used [recommended]

List the names and versions of all Commonly Recurring (CORE) SUMs that this Service Usage Model is based on.

<type text here>

References

List references and bibliographic citations to works needed to understand the Service Usage Model.

Open source client libraries that implement the del.icio.us service expression of the Add {bookmark}, Annotate and Categorise service genres:  delicious java

Add {bookmark} service expression:  Delicious API / Posts

Annotate and Categorise service expression:  Delicious API / Tags

Open source implementations of del.icio.us expressions of the Add {bookmark}, Annotate and Categorise genres  in PHP and one  in Perl

Glossary [optional]

List and define the domain-specific terms used in documenting the Service Usage Model.

<type text here>

This SUM is licensed under:

 Creative Commons Attribution-NonCommercial-ShareAlike 2.5 licence

Submitting the Service Usage Model Description

For additional guidance in preparing the Service Usage Model description, refer to Guidelines for Submitting a Service Usage Model to the e-Framework and the technical definitions of the Service Usage Model Description Elements. For further assistance, contact the e-Framework editor at: editor@…

Prior to submitting the description, please read the e-Framework Intellectual Property Rights statement Also add your information to the copyright statements in the footer of this template.

By submitting this document, you agree to contribute this document under the  Creative Commons Attribution-NonCommercial-ShareAlike 2.5 licence.

When you have completed the Service Usage Model description, go to the Submit SUMs page at  www.e-framework.org. Click on ‚"Upload your submission‚" and follow the directions.

SUM Template v7.1 20070529 © Copyright, JISC, DEST & e-Framework Partners, 2007

SUM Content © Copyright, JISC-CETIS, 2007