1 / 15

Functional requirements

Functional requirements. Essential first step, alongside analysis of existing schemes Undertaken, therefore, during the first and second quarters of the project Leading to a statement of the minimum functional requirements that an InterParty Network would need to support

hyman
Download Presentation

Functional requirements

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. InterParty Functional requirements • Essential first step, alongside analysis of existing schemes • Undertaken, therefore, during the first and second quarters of the project • Leading to a statement of the minimum functional requirements that an InterParty Network would need to support • No preconceptions at this stage as to how they should be delivered • As it turned out, a process of seeking to simplify as far as possible (but no further)

  2. InterParty Some working hypotheses • InterParty is an alliance of independent bodies - InterParty Members or IPMs • Each maintains its own identification and metadata system in its own domain • IPMs participate because they see benefits • From being able to see and use Common Metadata from other IPMs: data sharing • From communicating between their own domain and those of other (selected) IPMs by mapping across domains: interoperation • Common Metadata includes • A certain level of metadata about “public identities” • Assertions made about relationships between public identities in different domains

  3. InterParty Party and public identity • Party • An individual or organisation involved in the creation or dissemination of intellectual property • Public Identity • An identity that is associated with and is used publicly by a party (or a group of parties) • Public Identity Identifier - PIDI • An identifier assigned to a public identity by an IPM and designed to be unique within the domain of that IPM: a PIDI may be a number, or it may be a controlled form of name (eg in a library name authority system) • InterParty Link • An assertion about a relationship between two PIDIs in two different IPM domains - ie, between two public identities

  4. InterParty “Party” metadata Publicly known Not publicly known Sensitive Public Identity Party Party and public identity InterParty is concerned with “public identities” not “persons” or “parties”

  5. InterParty is is is PIDI NSC: 876X54 PIDI NSA:123456 PIDI NSB:Brian Green InterParty Links

  6. InterParty Connecting public identities • IPM A, a national library • Knows the public identity “XXXXXX” as the author of a series of, let us say, highly-regarded political biographies • IPM B, an authors licensing and collecting society • Knows that the rights associated with the public identity “XXXXXX” are managed by a private limited company in the Cayman Islands, as are the rights associated with seven other public identities under which the person behind “XXXXXX” has written romantic fiction • None of this sensitive information is disclosed to the InterParty Network! • Only the public identities and their relationships are openly asserted

  7. InterParty Data sharing • An IPM has online access to Common Metadata • Of all other IPMs or of a chosen subgroup • Purposes of online access • To help resolve uncertainties of identification within the IPM’s own domain • To download data for adding to the metadata held within the IPM’s own database • To provide the basis for creating InterParty Links • It is fundamental that all IPMs must agree to allow their Common Metadata to be used in these ways

  8. InterParty Interoperation • An IPM may use InterParty Links to enable it to interoperate with another IPM or group of IPMs • Subject to the agreement of all the IPMs concerned • There can be no obligation on any IPM to support interoperation with any other IPM • The InterParty Network is not intended to support specific applications involving interoperation • It will maintain the database of links and the limited functionality needed to find and download a link • Individual IPMs will develop and maintain the applications that use links • It is conceivable that some might be developed co-operatively by the InterParty Network as a whole

  9. InterParty Fundamental processes • Enquiry • Viewing and downloading metadata • Asserting, commenting on, and authorising links • Support for interoperation • Automatic mapping between two consenting IPM domains

  10. InterParty Enquiry • Enquiry is required for data sharing, for asserting links and for interoperation • Enquiry by name • Typically uncontrolled, possibly incomplete • May be accompanied by other metadata • Specify the set of IPMs whose Common Metadata is to be searched • Enquiry by PIDI from “own” namespace • For maintaining links and, as an automated look-up, for interoperation • Enquiry by PIDI from another namespace • For following up links; and, possibly, as an automated look-up, for interoperation • Enquiry by other metadata? • Usefulness depends on the consistency that can be achieved in metadata from IPMs

  11. InterParty View and download metadata • Envisaged as primarily human-to-machine processes • Restricted to authorised users from IPMs only - no third-party access • Review Common Metadata returned by enquiry • Follow up existing links if any • Download selected content for use within own domain

  12. InterParty Assert and authorise links • Again, primarily human-to-machine processes • Only the IPM that “owns” a PIDI may assert a link with a PIDI in another domain • “Inferred links” - ((A=B) and (B=C )) implies (C=A) - may be generated automatically • Any IPM can add comment supporting or questioning a link • For a link to be authorised for interoperation between two IPM domains, both IPMs must have endorsed it

  13. InterParty Link relationships • As simple as possible • Binary only • IS • IS NOT (where IS might otherwise be thought likely) • IS COMPLEX • Where two domains have different rules as to what constitutes a Public Identity • For example, domain A may treat Ruth Rendell and Barbara Vine as a single Public Identity, while domain B treats them as two separate Public Identities • Debatable whether the live InterParty Network should attempt to be more specific about complex relationships

  14. InterParty Support for interoperation • Machine-to-machine process • Send a PIDI from own domain (usually but not necessarily?), specifying target domain(s) • Receive “equivalent” PIDI(s) from target domain(s) • For interoperation requiring a high degree of confidence, only authorised assertions will be regarded as showing “equivalence” • Transfer received PIDI(s) to user application

  15. InterParty In summary • The functional requirement is for... • An InterParty Network open only to its members... • Giving each member online access to Common Metadata from all of the others (or those it chooses to work with)... • Enabling each member to draw on this resource to improve its own local party identification and metadata system… • Supporting assertion and maintenance of very simple links between IPM domains… • And providing the means for automated mapping between IPMs that agree to interoperate.

More Related