The key idea here seeems to be that attributes are stored in a separate table, and tacked onto borrowers (actors, or "users" in NCIP) as required.

Here are a couple of thoughts on that:

1. I'm not sure about having three value fields for each attribute, as two of them will always be empty. Plus there are many other data types an attribute could take: datetime springs to mind. I'd say we don't want a separate field in the actor_attributes database table for each potential attribute type.
2. This gives a lot of flexibility, but adds to the complexity. Should we just do a very plain borrower implementation to start with, without customisable attributes? Something very close to what you'd get in an NCIP LookupUserResponse??
3. Similarly for the idea of pulling attributes from multiple sources: we might want this eventually, but for now I think we should just mandate a set of platonic attributes. Developers can work out how to map to that set, and let us know if we've missed anything.
4. Another way to enable institutions to layer their own attributes on top of our platonic borrower would be to create a new table which references the Jangle default (table inheritance?). Rails supports this kind of thing as part of ActiveRecord?, so in Ruby you could extend the appropriate model to present these attributes.

On addresses:

1. Are addresses generic enough so that we can have a single table for every type of address, rather than a separate actor_addresses table?
2. Eventually, we'll need a many-to-many relationship between actors and addresses, with dates specifying the period for which the address is valid (on the join table). Also, two people could share an address, so we should only store each address in one place.

I agree with your comments. My proposal was trying to address the somewhat overwhelming array of options libraries might want to include to identify a person. After a good night's sleep and then your thoughts on the matter, I also don't think this flexibility is a good approach (right now, at least).

Regardless of how we store the data in the local store, we need some concept of the Actor/User/Borrower 'model' which needs to be versatile enough to account for how different places might identify somebody (barcode, username, SSN, all of the above, etc.) and how they store their data (namely personal names, dates and what data elements are necessary for 'business' to their local development). I note NCIP completely punts on this and only specifies an identifier and visible identifier, as well as bunch of unspecified user attributes (much like my original concept).

Here are the data elements Evergreen uses to define an actor

Here is Koha

Voyager defines 'Patrons' with these elements:

• 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)

So, those are just some cross-sections of the sorts of data we can expect to find.

I think the idea of 'actor' maps pretty well to FOAF: http://xmlns.com/foaf/spec/#sec-glance and making such a mapping available would be attractive from a hackability perspective.

vCard also would fit this bill pretty nicely: http://www.w3.org/2006/vcard/ns and we could probably use a combination of FOAF and vCard (since FOAF doesn't address the concept of phones or physical addresses and vCard deals with electronic identity fairly kludgily, IMHO).

If we had to choose one, I would definitely go with vCard as a more swiss-army knife approach.

Oh, and I totally agree with you on addresses being neutral enough to not be directly associated with actors.

How about we come up with a canonical list of attributes we want as a minimal actor? (I'm happy with that term.) First off, missing out relationships to other resources. Then a single relationship to addresses - ignoring other relationships for now, like institutions, groups, loans, requests, reservations etc.

FOAF is a decent way to cover the actor attributes.

vCard would fit in with address info. (so we can defer that in the first instance while we get a base borrower with no address info.).

I think I'll rejig this page so we can see the borrower schema (without addresses) at the top of the page.