InterParty Functional Requirements A presentation to the final InterParty Seminar The Hague 13 June 2003 David Martin

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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.