UKOLN International Repository Workshop: Identifier Interoperability

[EDIT: Maurice Vanderfeesten has a fuller summary of the outcomes.]

First Report:

• Many resonances with what was already said in other streams: support for scholarly cycle, recognition of range of solutions, disagreement on scope, needing to work with more than traditional repositories.
  
• Identifying: objects (not just data), institutions, and people in limited roles.
  
• Will model relations between identifiers; there are both implicit and explicit information models involved.
  
• Temporal change needs to be modelled; there are lots of challenges.
  
• Not trying to build the one identifier system, but loose coupling of identifier services with already extant identifier systems.
  
• Start with small sets of functionality and then expand.
  
• Identifiers are created for defined periods and purposes, based on distinguishing attributes of things.
  

Second Report:

• We can't avoid the "more research needed" phase of work: need to work out workflows and use cases to support the identifier services, though the infrastructure will be invisible to some users.
  
• Need rapid prototyping of services, not waterfall.
  
• The mindmaps provided by the workshop organisers of parties involved in the repository space [will be published soon] are useful, and need to be kept up to date through the lifetime of project.
  
• There may not be much to do internationally for object identification, since repositories are doing this already; but we likely need identifiers for repositories.
  
• Author identifiers: repositories should not be acting as naming authorities, but import that authority from outside.
  
• There are different levels of trust for naming authorities; assertions about authors change across time.
  
• An interoperability service will allow author to bind multiple identities together, and give authors the control to prevent their private identities being included in with their public personas.
  
  

Third Report:

• The group has been pragmatic in its reduction of scope.
  
• There will be identifiers for: Organisations, repositories, people, objects.
  
• Identifiers are not names: we not building a name registry, and name registries have their own distinct authority.
• Organisations:
  
  • Identifiers for these should be built on top of existing systems (which is a general principle for this work).
  • There could usefully be a collection of organisation identifiers, maintained as a federated system, and including temporal change in its model.
    
  • The organisation registry can be tackled by geographical region, and start on existing lists, e.g. DNS.
    
  
  
• Repositories:
  
  • There shall be a registry for repositories. There shall be rules and vetting for getting on the registry, sanity checks. Here too there are temporal concerns to model: repositories come into and out of existence.
    
  • The registry shall be a self-populating system, building on existing systems like OpenDOAR. It should also offer depopulation (a repository is pinged, and found no longer to be live.)
    
  • There is a many-to-many relation of repositories to institutions.
    
  • The registry shall not be restricted to open access repositories.
    
  
  
• Objects:
  
  • We are not proposing to do a new identifier scheme.
    
  • We are avoiding detailed information models such as FRBR for now.
    
  • We propose to create do equivalence service at FRBR Manifestation level between two identifiers: e.g. a query on whether this ARK and this Handle are pointing to the same bitstream of data, though possibly at different locations.
    
  • Later on could build a Same FRBR Expression service (do these two identifiers point to digital objects with the same content).
    
  • The equivalence service would be identifier schema independent [and would likely be realised in RDF].
    
  
  
• People:
  
  • A people identification service could be federated or central.
    
  • People have multiple identities: we would offer an equivalence service and a non-equivalence service between multiple identities.
    
  • The non-equivalence service is needed because this is not a closed-world set: people may assert that two identities are the same, or are not the same.
    
  • The service would rely on self-assertions by the user being identified.
    
  • The user would select identities, out of a possibly prepopulated list.
    
  • People may want to leave identities out of their assertions of equivalence (i.e. keep them private).