A Jangle actor records details of any person that Jangle needs to know about. Mostly, this will be borrowers/patrons.

Schema version 1

The first pass at this should be as simple as possible, making no reference to libraries, institutions, addresses etc.. This boils down to:

• id (a system ID)
• honorific_prefix (Dr., Mrs., Miss - should this be a lookup?)
• honorific_suffix
• first_names
• last_name
• sex (male/female - again, a lookup?)
• date_of_birth
• email_address
• telephone
• mobile_phone
• created_at
• updated_at

Note that this also includes some of the properties you might put in vCard, such as email addresses and telephone numbers. (Note that these should perhaps be normalised into a separate contact_methods table, which could enable setting a preferred contact method - but let's ignore that for now.)

Whether an actor should also have attributes relating to library-specific data, I'm not sure.

I think we could have a separate table to deal with identity_types:

• id (system ID)
• identity_description (e.g. barcode, institutional_id)

And then associations between an actor and a type of identity (identities):

• id (system ID for this identity)
• actor_id
• identity_type_id
• value (e.g. the person's actual barcode or ID)

This follows the line of some of Ross' ideas about the flexibility to add new attributes, but restricts this to the one part of the domain we know will vary (i.e. the types of authentication systems people are likely to use).

Issues with handling identities like this:

• Relating identities to credentials: e.g. if someone has a barcode, you might need to associate that with a pin and/or password; similarly for their institutional ID. Should these be treated as one identity with two parts; or as two identities with a relationship between them? Should the identities table have two fields, one for username (whatever that's called in the abstract), and another for password?
• Integrating with identities from other systems: not sure how you'd tie credentials from an LDAP directory into this.

We might need to be able to associate an organisation with a range of identity_types at a later date, but for now we'll keep it simple.

As for addresses, we could try to follow vCard for now. For the addresses I'm thinking about, we could use the v:Address class specified in the RDF model for vCards, e.g.

• street_address
• locality (e.g. city or town)
• postal_code
• region
• country-name

And then have a table connecting the two, actors_addresses:

• actor_id
• address_id
• active_from
• active_to

(Another comment: this kind of sprawling unstructured data would be an ideal application of Talis' Platform for RDF... For now, we'll put it into the strait-jacket of an RDBMS.)

Older thoughts

As a first pass, let's go with three tables:

actors:

• id int
• created_at

actor_attributes

• id int
• actor_id int
• source_id int
• attribute_name string
• value_int int
• value_string string
• value_text text
• created_at
• updated_at

actor_addresses

• id int
• actor_id int
• address_type (int|string) #
• street string
• street2 string
• city string
• state string
• country string
• postal_code string

Ok, now let me explain the rationale here. It's difficult to tell exactly the fields that may be associated with a borrower in a given system. Some may use barcodes, or usernames, or social security numbers or all three (although you should start seeing fewer and fewer ssns for ID). Same goes for names (one string? First, last, middle? Latin American style with first last name/second last name?). To add to this, different systems may have different policies for this sort of data: the Voyager ILS, for instance, allows for more than one barcode to be associated with a patron.

What would then happen is the institution would very simply map their local attributes to a 'standard' Jangle borrower (however they see fit -- id == barcode | username) with the option to return a response that includes whatever fields they want.

I am open to other ideas regarding this (or gaping holes in my logic).

I also thought we may want another field in the 'actors' table pointing back to attribute that defines the canonical that an institution would use to identify a user (or just include that field in actors, which is probably even smarter).

Borrower schemas from other ILSs

TalisSOA

'Borrowers' have the following attributes:

• id
• barcode
• institutiondIdNumber
• homeSiteId
• pinNumber
• surname
• firstNames
• dateOfBirth
• contacts

'contacts' is one or more sets of contact details for a borrower, including the dates for when those details apply. This might include a borrower's old addresses as well as their current one.

Voyager

'Patrons' have the following attributes:

• first name
• middle name
• last name
• title
• social security number
• pin
• institution ID
• barcodes (multiple can be assigned to a patron)
• phones (multiple)
• addresses (which include email)
• notes
• groups (roughly borrower type)

Koha

From http://www.kohadocs.org/usersguide/apas02.html

Evergreen

Note this includes ILS-specific data (card, barred), system data (deleted, super_user), and address data.