Contributions > Service Genres > Classify 1.1 Login
  Minimize

 
      Minimize
Name
 
  • Name: Classify
Rationale
 

This Service Genre has been developed to outline the functionalities and bahaviours required of services which assign classifiers to data items, without altering the source data.

Classification
 
Domain(s) [ ] Learning & Teaching [ ] Research
[ ] Libraries
[ ] Administration
[ ] IT Services
[X] Common
Maturity [ ] Immature [X] Mature
Development Scale [ ] Isolated [X] Ubiquitous
Status [X] Approved [ ] Placeholder
[ ] Unapproved
[ ] Superseded
[ ] Withdrawn
Confidence Level [ ] High [X] Medium [ ] Low
Version
 
  • e-Framework Service Genre Version: v1.1
Version History
 
Version Date Author Description Organisation / Project
v1.1
2007-02-28
Phil Nicholls
Accepted by eFIG
JISC
Description
 

This Service Genre describes the assignment of a classifier to an object. Classifications are assigned as specific properties to an object from a bounded, unordered set of values, with all classifiers being equivalent.

The original object MAY be modified by the Classify service. The Classifier MAY be applied to a proxy of the object. The Classifier MAY be applied as metadata. Objects MAY be classified by a number of properties using different classifications.

The data used to make up the set from which classifiers are drawn (the Classification Scheme) MUST be finite, and MUST NOT be ordered. The Classification Scheme consists of the property to which the Classification is assigned, and all allowable values. (Example: Property could be “Colour”. Values could be “Red”, “Green”, “Blue”).

Classifications MAY be made anonymously. Classifications SHOULD NOT be accompanied by comments.

As defined the Classification Service Genre is not access controlled. Any client may attempt to contact a Classification service end point. There are no authentication controls. The service end point is responsible for determining which individual objects can be classified and which clients can make classifications to existing objects.

Functionality
 

The Classify Service Genre supports functions that enable the assignment and alteration of classifications.

  • Assign Classification: allows a requester to assign a classification to an existing object. Classify Services SHOULD store the classification permanently within the context of the object. Classifications MUST be assigned to a distinct property as described by the Classification Scheme
  • Alter Classification: allows a requester to edit an existing classification on an object.
  • Delete Classification: allows a requester to remove an existing classification and associated property from an object.

No other functionality is defined. The functionality that is defined MAY be extended.

Usage Scenarios
 

 

Applicability
 
  • Classify SHOULD be used when an unordered bounded value is to be assigned to an object
  • Classifications MAY be applied to collections of objects as well individual objects
  • Classify SHOULD NOT be used if an unbounded, unbounded value is to be assigned to an object. Annotation SHOULD be used instead
  • Classify SHOULD NOT be used if an ordered, bounded value is to be assigned to an object. Rating SHOULD be used instead
Requests & Behaviours
 

Requests SHOULD be implemented to enable all functionality.

Assign Classification SHALL meet the following conditions:

  • The Request SHOULD specify:
    • The target object to be classified
    • The target Property to be classified
    • A value from the classifiers for the property to be applied
  • The Request MAY Specify:
    • The author of the Classification

Alter Classification SHALL meet the following conditions:

  • The Request SHOULD specify:
    • The target property to be altered/li>
    • A new value from the classifiers for that property
  • The Request MAY specify:
    • The author of the Classification

Delete Classification SHALL meet the following conditions:

  • The Request SHOULD specify the target Property to be deleted

Responses SHOULD:

  • Indicate any error conditions
Use & Interactions
 

Individual Service Expressions SHOULD provide models showing how clients interact with service interfaces.

Structure
 

 

Applicable Standards
 

None

Design Decisions and Tradeoffs
 

Authorisation SHOULD be considered when specialising this Service Genre. Specifically, whether owners of the original object are authorised to delete and edit Classifications.

Management of the Classification Scheme SHOULD be specified by the Service Expression or SUM which incorporates Rating.

The management of which objects can be classified SHOULD be considered by the Service Expression or SUM which incorporates Rating.

Implementation Guidance and Dependencies
 

 

Known Uses
 

 

Related Service Usage Models (SUMs)
 

 

Related CORE SUMs
 

None


Intellectual Property Rights: This document is governed by the e-Framework Intellectual Property Rights Statement [http://www.e-framework.org/Default.aspx?tabid=738]. © Copyright, JISC, DEST & e-Framework Partners 2007. This document may be used under the Creative Commons Attribution-ShareAlike 2.5 Australia License [http://creativecommons.org/licenses/by-sa/2.5/au/].


The words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [RFC 2119].

The Service Genre description uses e-Framework Service Genre description elements as of 2006-12-09, updated to include draft e-Framework service classifications. Other terms, e.g., client, provider, and resource, are used as defined in the e-Framework.

 
Related SUMs   Minimize
 
    Minimize
Unless otherwise noted material from the e-Framework website can be downloaded for your own use under a Creative Commons Attribution-ShareAlike 2.5 Australia License
CreativeCommons-by-sa.png
 
Thursday, August 28, 2008
Copyright e-Framework Partners 2006 - 2008

Terms and Conditions

Privacy Statement