Skip to end of metadata
Go to start of metadata

This page is a temporary holding place for notes on the ID Service until the Description and Assumptions page is unfrozen, following its 2009 review.

ID Service Scope

There are three types of IDs being considered for the ID Service:

In Scope

As Anastasia wrote on 2009-06-08:

The ID service generates "Museum IDs" which are IDs that follow patterns that have been set up by a specific museum (e.g. accession numbers).

Some examples of categories of these "museum IDs" (or "collections IDs," "catalog IDs," "object IDs," or any other terms that may be used for these museum-issued IDs) that are in scope for the ID Service include:

  • Permanent or temporary IDs given to collection objects that are accepted, but are not (or at least not yet) accessioned.
  • Accession numbers.
  • Any other IDs that may be applied to a collection object by a museum.
  • Any other IDs assigned by a museum to identify other types of entities or to identity specific instances of activities (e.g. loan numbers, used to identify specific loans).

Samples of several of these "museum IDs" are nicely captured in Object Entry Use Cases.

In Scope Later

There is a second category of IDs that are not generated or assigned by a museum, but that we nonetheless currently believe are in scope for the ID Service, although its implementation release (0.2, by 1.0, beyond 1.0) is still to be determined:

These consist of IDs programmatically retrieved from sources external to a CollectionSpace system. Examples include:

  • GenBank IDs, representing genetic sequences.
  • Barcode of Life descriptors (BoLDs), representing DNA barcodes.
Icon
  • ATS: Might this also include number generated by a piece of equipment (a camera, scanner, etc.)?

Out of Scope

"Other" Numbers

The ID Service does not provide or interact in any way with IDs that are are not used as a primary identifier by a museum or similar institution that is running a deployed instance of CollectionSpace:

  • "Previous" or "original" numbers, some of which may have come from earlier manual or computerized collections management systems run by the museum or its predecessors.
  • Numbers that come into the museum, accompanying collection objects or otherwise:
    • From donors, collectors, etc., such as field collection numbers.
    • From other museums, reflecting their own IDs for collection objects, loan numbers, etc.

These numbers are:

  • Typically entered into an "Other Number" field (as defined in SPECTRUM procedures) or a similar field.
  • Usually treated as opaque free text.
  • Not associated with patterns managed by the ID Service, and thus, are neither generated or validated by the ID Service.
Icon

ATS: I get that we might not want an ID service to deal with numbers considered "out of service" or "not currently in use" but are we saying that the ID Service only deals with numbers it has generated? That's what it sounds like here but, I'm not sure why?

Aron: Might it be the case that the ID service might only generate 'new' numbers - those matching the current patterns - but also provide at least some services around any numbers - old and new - whose patterns it knows about? Example: a museum used an old accession number format, those numbers were imported 'as is' from the old CMS, and now it uses a newer format for those numbers. The museum might want to set up patterns for both types of numbers, so that, for example, someone could still add an item to an acquisition from 1988, and the ID Service could a) validate that number against pattern and possibly b) identify if the new proposed number is already in use (assuming that's the responsibility of the ID Service, and not, say, of a direct call to the CollectionObject service)?

(The wording in "'Other' Numbers," above, has been changed somewhat to attempt to reflect Angela's comment.)

CollectionSpace IDs (CSIDs)

CollectionSpace IDs (CSIDs) are IDs that uniquely identify entities within a single deployed instance of a CollectionSpace system.

CSIDs are currently out of scope for the ID Service. More generally, all types of Universally- or Globally-Unique Identifiers (UUIDs or GUIDs), for uniquely identifying entities within a deployed instance of a CollectionSpace system, are currently out of scope for the ID service.

In large part, this is because the framework we're initially using automatically generates these UUIDs to identify each new document created, without requiring (or allowing) that any UUIDs be provided beforehand. These Nuxeo-generated UUIDs will be used as the initial CollectionSpace IDs (CSIDs).

Icon

At present, the Nuxeo framework is assigning type 4 UUIDs generated by java.util.UUID.randomUUID() to its documents. These use 122 random or pseudorandom bits, and are apparently extremely unlikely ever to collide in normal use.

However, as Richard Millet wrote on 2009-06-08, CSIDs are "opaque" and no assumptions about their nature - other than uniqueness within a single deployed instance of a CollectionSpace system - should be made:

From a service consumer's point of view, the CSIDs are of opaque type and unique with each deployment of CollectionSpace. Our current implementation of CSID just happens to be passing along the Nuxeo generated UUID as-is. However, we reserve the right to change this and consumers/clients should NOT assume (CSID == Nuxeo UUID).

If at some future point, it becomes necessary for the ID Service to generate UUIDs, that functionality can be rather easily added, either via java.util.UUID, Apache Commons Id's UUID Generator, or a similar UUID provider.

Update: as of the 0.3 Venus release, one of the "out of the box" generators for the ID Service generates type 4 UUIDs.

Development Notes

See Apache Commons Id for some interesting classes and a framework for adding additional Generators:

Commons Id is a component used to generate identifiers. Several identifier-generation algorithms are supported by Generators included with the package. The framework is extensible to support additional implementations. A utility class, IdentifierUtils, provides access to singleton generators and methods to generate identifiers without explicitly creating a Generator.

Reviewers' Notes

Michael Black and Jesse Martinez - Raw, unedited notes 2009-06-05
Raw, unedited notes from a discussion and review of the ID Service
with Michael Black of PAHMA and Jesse Martinez of MMI on 2009-06-05:
Knowing there might be gaps in sequence is a disincentive to request
IDs; one workaround are temporary records

Another might be some way to reuse or reissue unused numbers; or an
"oops, I didn't use these, these IDs can be re-used."

Exhibits generally don't have IDs

Search:
When retrieve by ID, might also retrieve sub-object records
"Would love to not have to know the suffix (e.g. sub-object) to find it."

Or CAN go directly to sub-object

"Other numbers"
- Original
- Field
- Previous
- Alternate
Free text, repeating

Ranges - all sorts of issues
- If an item in a range is forked off into its own new record, it may
literallly be referred to in two places

- Search is problematic: you might in many cases know the *exact* range;
e.g. a-g, to retrieve an object

Likes:
TMS's space padding of numeric values in another field, facilitates
sorting without having to do zero padding

Open Collection
can set policy over whether IDs with duplicate records can be stored
One policy: allow but warn - after leave ID field, before saving

MMI
Start with temporary IDs
Just gets replaced with an accession number
Uses standards-based pattern

PAHMA
In minority
Has an object number, persistent
separate from accession number

duplicate object numbers are usu. a function of legacy

when detected, pahma creates new object record with "objnum.dup"

mmi may have an "interim" accession number, what we imagine it will be

records always kept
even if "retired"
deaccessioned
returned loan
returned to donor for some other reason

destroyed
stolen
lost
with status indicator

VERY handy to show this next to records "inline" in search

Search should show object relationships where it matches a parent object

automatic system-generated numbers are a fantastic idea

search w/leading zeroes in open collection frustrating
have to have the right number of them or search fails 0017 <> 017 <> 17

a somewhat older version of opencollection, in any case earlier than
collectiveaccess

pahma older system
cat designation, item number
variously referred to as catalog number, museum number, object number

two large collections in the past, one kelly collection (sp?), so many
objects, kept original object numbers

any preliminary or temporary numbers are almost arbitrary

(note to self, support spectrum, chin id standards out of the box, via
pre-configuration; allow renaming of patterns)
Jesse Martinez - Follow-up email 2009-06-05
Follow-up email from Jesse Martinez of MMI on 2009-06-05:

[Regarding the] distinction between objects made of discrete and
non-discrete parts. Using Megan's example, an object with discrete parts
would be a set of 6 action figures. This object number would be
something like 2009.001.0006.1-6  A record for an individual object in
this group would be, in MMI's policy, 2009.001.0006.2 although it's
perfectly fine to no have independent sub-object records. An example of
an object made of non-discrete parts would be a teapot and lid. This
object number would be 2009.002.0001a-b (note the lack of whitespace and
a period between the last number and the first alpha character - MMI
syntax.) The teapot lid would have an object number, if needed, as such:
2009.002.0001a

[Regarding the] assumption in how parts of the sub-object get numbered
independent from their parent record. It *does* maintain the parent
object record number sans suffix, as seen in the examples above.

I also asked Megan to clarify the need to allowing duplicate
object/accession numbers. This would be the case for legacy records
which may not have been properly set, or mislabeled and not yet
corrected. There could be a case where early object records from a
particular accession weren't given independent object numbers and all
share the same accession number prefix as its object number.
CollectionSpace should allow for these kinds of cases where there is a
legitimate reason to support non-standard number assignations due to
mal-formed record numbers and/or misused policy.

Also, I asked Megan about our accession process. An object officially
gets an accession number once the deed of gift is approved and signed
off by our director. At times, because the deed of gift is fairly
certain to be signed but just hasn't gone through the director's busy
schedule, Megan will assign an accession number to the object anyway.
This isn't official policy but it aids in preventing a bottle neck in
where it could take months before the deed of gift is approved and
signed. The interim number used as the pre-accession number isn't
typically saved in the subsequent accession/object record but could be
saved within the "Other Number" field.

Here's a question I have for you, Aron. As we had discussed on the
phone, there is a level of ire when searching in OC/CA for
accession/object numbers and the search system doesn't treat 2006.001
and 2006.01 and 2006.0001 as similar numbers. They are in fact different
numbers in a literal sense, but for a layperson they may be identical.
While it would be proper to follow a set standard, for instance a
mandatory minimum three digit number segment in the accession/object
number, sometimes this may not be the case, especially for legacy
records. Could this be a concern for the ID service development?
Megan Forbes - Raw, unedited notes 2009-06-08
Raw, unedited notes from an IRC chat with Megan Forbes of MMI on 2009-06-08:

In response to her emailed question:

My question - will some service, if not the ID service, recognize numbers
imported from a legacy database? This may be a non-issue, but the use case
I have in mind is a user adding a new item to an accession created long
before adoption of CSpace (not an uncommon occurrence). If ID's pulled
in from a legacy system are treated as text, will the system be able to
recognize if, for example, a duplicate item number is being created?

[3:15pm] mmiforbes: Did my question make any sense?
[3:15pm] aronr: yes
[3:16pm] aronr: is the idea that some older records
[3:16pm] aronr: for collection objects
[3:16pm] aronr: might have a different, older style of accession number?
[3:16pm] aronr: perhaps after an import from an older cms?
[3:16pm] mmiforbes: no, not necessarily
[3:16pm] mmiforbes: Let me explain the scenario a little better...
[3:16pm] aronr: ok ... thanks!
[3:16pm] mmiforbes: Say we have an accession from 1983, with the
accession number 1983.1
[3:17pm] aronr: ok
[3:17pm] mmiforbes: At some point, maybe records for item numbers
1983.1.1 through 1983.1.87 were added to the system.
[3:17pm] aronr: and now someone wants to add 1983.1.88?
[3:18pm] aronr: (or carelessly or inadvertently wants to re-add
1983.1.86?)
[3:19pm] mmiforbes: It's the 1983.1.86 that interests me. It could
happen, if it's a large, old donation, the odds that when the items were
physically numbered there were some inadvertent duplicates are decent.
Maybe all the items weren't entered into the CMS before for some reason,
and now someone's going back and adding things.
[3:19pm] aronr: ok ... i think we've covered that (maybe not well
[3:19pm] aronr: on the current, frozen id service description and
assumptions page
[3:19pm] aronr: this is a generic case of "how do we ensure uniqueness
...
[3:19pm] aronr: for some important ID that we're assuming, and wanting"
[3:20pm] aronr: will be unique for every record of a certain type (e.g.
collectionobject, loan)
[3:20pm] aronr: within a deployed collectionspace instance
[3:20pm] aronr: On the ID Service Description and Assumptions page
[3:21pm] aronr: there's a subhead (also linked from the TOC at top)
[3:21pm] aronr: "Uniqueness of IDs Throughout a CollectionSpace System"
[3:21pm] aronr: And an expandable arrow (borrowed from your Functional
Requirements page - thanks!)
[3:21pm] aronr: "There are several ways in which the CollectionSpace
system might handle the requirement to ensure that only unique values
are stored in a specified ID field, for any particular entity. Only one
of these involves the ID Service, and in that, only in a peripheral
capacity. Among these: ..."
[3:22pm] mmiforbes: ok, so existing id numbers brought in from legacy
systems could be stored in indexes (indices?) that could be searched by
the id service before it creates a new number?
[3:22pm] aronr: That's what I'm assuming
[3:23pm] aronr: If the 'old' records from legacy systems are imported in
that way
[3:23pm] aronr: if we just stuff them into an 'other number' (or a
repeating 'other number') field
[3:23pm] mmiforbes: Gotcha
[3:23pm] aronr: that wouldn't work, however
[3:23pm] aronr: a lot of this depends on some care and intelligence in
the import process
[3:24pm] mmiforbes: To the end user, numbers created pre-Cspace and
post-CSpace should be more or less indistinguishable
[3:24pm] mmiforbes: So much hinges on the import!
[3:24pm] aronr: hmm ... do you mean if they're the same types of numbers
... like yyyy.accession_lot_number.item_number
[3:24pm] aronr: ?
[3:25pm] mmiforbes: It's a little daunting...I've still got errors in
OpenCollection that I'm trying to figure out how to avoid bringing over
into CSpace!
[3:25pm] aronr: [3:25pm] aronr: if they're truly different sequences,
this might be challenging
[3:25pm] mmiforbes: Not if they're truly different sequences
[3:25pm] aronr: but in the 'standard-based' examples you gave
[3:26pm] aronr: where there might be an 1988.1.87 and now we have
2009.1.45 ...
[3:26pm] mmiforbes: But for example, if I import accession numbers
pre-2009 into CSpace, and then create 2010 records, say if I were to
export them, or sort, or search, or manipulate, or whatever, the 2010
numbers should behave the same.
[3:26pm] aronr: and all of these are stored in a single accession number
field
[3:26pm] aronr: yes
[3:26pm] aronr: 1988 and 2010 records should behave the same, so long as
the patterns are the same, or can be reliably converted at import from
the old format to new
[3:27pm] aronr: (old *pattern* to new)
[3:27pm] mmiforbes: Yes, all would be stored in a single accession
number field. There may be some crazies out there who want to move their
old accession numbers to a legacy field and then re-number their
collections, but they'll be few and far between.
[3:27pm] aronr: so might there yet be two patterns, old and new, in this
single accession number field?
[3:28pm] mmiforbes: Hmm...I don't think I understand your last question.
[3:28pm] aronr: ah ... let's say in the past there were two digit years
and leading zeros; e.g.
[3:28pm] aronr: 88.001.0003
[3:29pm] aronr: and now the new pattern might be 1988.1.3
[3:29pm] aronr: for that same item
[3:29pm] mmiforbes: It's possible, but pretty unlikely. Most folks just
pick a date to start using a new pattern, and then they leave old things
alone.
[3:29pm] aronr: ok
[3:30pm] aronr: would accession numbers from both patterns be present in
the same accession number field?
[3:30pm] aronr: old pattern and new pattern?
[3:30pm] mmiforbes: In general, there would be one "active" number (the
new pattern) and one "legacy" number (the old pattern)
[3:30pm] mmiforbes: So the old number would no longer appear in the main
accession number field.
[3:30pm] aronr: so what should happen at import?
[3:31pm] aronr: if an old record had, say (and this is a hokey example,
admittedly)
[3:31pm] aronr: 88.001.0003
[3:31pm] aronr: and it was imported
[3:31pm] aronr: should '88.001.0003' go into some 'previous' or
'original' or 'legacy' field
[3:31pm] aronr: (an instance of "other number", perhaps?)
[3:32pm] aronr: and a converted-to-new-pattern instance, '88.1.3', go
into the
[3:32pm] aronr: accession number field?
[3:32pm] aronr: that is, "ideally"?  and assuming that's readily
feasible during import
[3:32pm] aronr: (not all cases might be as clear-cut as this one)
[3:32pm] aronr: especially if there were several patterns used over the
years ...
[3:33pm] mmiforbes: Yep, that's how it could work. Again, this is a
pretty far out scenario, most folks will just keep the old ones, and try
to be better in the future.
[3:33pm] aronr: so when an old record is imported
[3:34pm] aronr: what's most likely to happen to the 'old' number?  does
it a) go into an 'other' number field and if so, what goes into the
'accession number' field for that object?) or b) go into the 'accession
number' field, where there will now be numbers from two patterns, old
and new?
[3:34pm] aronr: sorry for asking what may be a repetitive question - i'm
still trying to understand
[3:35pm] mmiforbes: In 99/100 cases, the old number will be imported
into the accession number field, and that will be that.
[3:35pm] aronr: if there *isn't* some sort of conversion
[3:35pm] aronr: ok - so there *will* be numbers matching two patterns,
then, in that field
[3:35pm] aronr: and in this scenario
[3:36pm] aronr: that's still ok - so long as the field is indexed, or
more likely indexed unique (which it will probably will be), any of the
methods of preventing a duplicate should still work
[3:36pm] aronr: jesse told me last friday that opencollection has a
feature where
[3:36pm] aronr: when someone's doing data entry of a new collection
object record
[3:37pm] aronr: if they manually enter a new accession number (or any
object number?)
[3:37pm] aronr: when they leave that field, OC can - depending on policy
- check whether that number is unique and warn if not
[3:37pm] mmiforbes: yep, OC lets you know if a number exists
[3:37pm] mmiforbes: And if so, how many other records are using that
number
[3:37pm] aronr: that's something we could implement; it would be in the
UI layer, and it would depend on a call to either the collectionobject
service or the id service
[3:38pm] mmiforbes: If you click on the warning, it takes you to a
search of that number
[3:38pm] aronr: most likely the former
[3:38pm] aronr: that's handled really nicely in OC
[3:38pm] aronr: there's a lot to like in that system!
[3:38pm] mmiforbes: I know ... a lot of what we did was really innovative!
[3:38pm] aronr: in essence, Toronto's UI layer would call
/collectionobjects/{id}
[3:38pm] aronr: and if it received any 'hit(s)'
[3:39pm] aronr: i.e. not a 404 Not Found error
[3:39pm] aronr: a collection object with that ID would already exist
[3:39pm] aronr: what we'll need to work out is what {id} is
[3:39pm] aronr: right now, it'd be our long, CollectionSpace IDs
[3:39pm] aronr: which are universally unique identifiers, but don't
correspond to any museum numbers
[3:40pm] mmiforbes: I'm always happy to talk OC, so let me know if you
have any questiosn
[3:40pm] aronr: cool
Robin Dowden, Nate Solas - Walker Art Center - Raw, unedited notes 2009-06-11
Raw, unedited notes from a phone interview with Robin Dowden and Nate Solas of the Walker Art Center on 2009-06-08:

hyphenated range stuff

id patterns and sub objects
hierarchy of ids
too specific
didn't need to be called out
where the parts go left to right
everything is a hierarchy

parent-child
whole-part relationship
so complicated
how dealing with physicality
separateness
own object record
but can't be broken apart
three panels of triptych

a book
manuscript
want to catalog every page in the manuscript
technically could be taken apart
but wouldn't

diff than portfoliio

i want not to make it part of the problem of identifiers
the ability t ocount things

identifiers have properties and purposes about identifying
at least in accesion number scheme
often a representation of physicality
one piece of paper, two pieces of paper

there are patterns
everybody does differently

i'm advocating whether the issues of separate or part
or are identifiers
two different problems
may need to be a representation in

may be correlated or not

tieing object count
the record represents what
15 things, 10 things

identifier is a separate problem from
parent-child relationship
counting separate from record
90% separate
some times where one record represents 5 objects

email address
what is the full scope of an identifier

impressed with the amount of detail, work gone into this

gist of it
agree with you
that ranges don't belong as accession numbers
if it's 1-5
should be broken up,
each should have its own

cultural thing at various institutions
complicated to change, extra overhead

wireframes
create from existing
would make fairly easy

mileage on discourage

accession number
should be unique
but may not be enforceable

i don't know if we can force onto an end user

year locked number
alpha prefix followed by number
defined a long time ago
reassigned yet another numbering scheme

the old legacy number
can't be b57s
not a reflection of the reality of how that object was identified over
its history

maybe a current accession number
maybe of old accession numbers ...

in theory should be

unique in system
but representing a single object
is what i (nate) envision

nate and i start to get into
tryptich
1, 2, and 3
cover record
applies to full thing
exhibition history
unified history
how appears on reports

would never list those separately

maybe satisfied in notions of groups

1600 objects in database not very big
with hyphens that represent gropus of things

in walker's case, some things at lower levels
filemaker dbs created by host of people

notion of "elements" - break collective objects out in other spaces
part 1 ... part 4

add-on databases
1 file is related to the other

created these things called elements
umbrella-ed under 1 record
work of art database
xxx1-5

accommodation

as long as some mechanism for grouping
or parent-child relationship

to talk about them as one piece
but recognize they're not the same thing

if some way - can automatically generate .1 gthrough .5
but also creates the grouping mechanism

******!

also depends on maintaining accession number history

wouldn't necessarily have a problem with breaking out

if want to put portfolio on the list
don't want 93 records on the list
just want one
the cover record, the group record

reporting element, other dimensions there

like the notion of a wall label
the triptych  1 label
accession number

why break out - if not separate
because they're three physical things

my history from the national gallery for art
and here
registration will look at the separateness of something
the left panel could go to conservation
could walk away
while the two others could stay
will want to break out
yet will almost always look at this as the unified whole

build me dummy records for all 96
seed values for each

moving forward, if they actually are created,
some concept of referring to them as a single thing

if have this umbrella record, the "cover record"
track as being separate
e.g. size, location

smaller and more specific

going forward, as we finish these descriptions
use us as a place

technologist

we have grand ideas about our ability to implement sooner
All-Team Meeting - Raw, unedited notes 2009-06-15
Raw, unedited notes from the review of the ID Service at the project All-Team Meeting in Toronto, 2009-06-15:

scope
  generation
  validation

mult levels
accession for aqc record
first two parts give me next
or next available item number

at whatever point you're working
ever change a part value in the middle?
no
can't jump fields
sequence (not hierarchy)

patterns
  may need to know type of objects that pattern is for
  accession numbers related to activity of acquisition/accession
  may need to relate to activities (see above) not objects
  re validation
  "this is a pattern that should be applied to loans" - talk to Patrick
  start w/spectrum ID recommendations 'out of the box'

Generation unique?
  Check with relevant service ...
  out of the box - app may believe or not in uniqueness
  will be institution-specific
  if in importing, allow and flag duplicate
  baseline when creating new number, auto-generate always unique

id pattern parts
constants
dynamic
  numeric
  alpha
  enumeration ...

change accession number after the fact
- validation/in-use
- then access control

optional elements
  give optional

provisionally
  new patterns for optional sub-elements
  such as suffixes for parts
  will do user testing, see if we need to implement in single patterns
  arbitrarily deep

some sub-parts aren't sub-parts in numbers to the parent
folios initially cataloged by folio
acc number for ms
different for book

patrick: model relationship among patterns
this is a pattern for generating this
all fields that match in the parent should become constant
a sub-part of this ... the only patterns that should be legal here
are those that match a parent, plus a suffix
in ui, can't edit from parent number

what does the id service care about
only numbers it generated?
all previous?

at the time of import
if defined those patterns
is there a fallback, which is just "string"?
do we need to check against all existing records
even those matching the pattern "string"?
YES

carl h
200 duplicate records
added "/DUPLICATE" after all

PAHMA keep around
mark with ".DUP"
create new record
old record may have been used in publication

megan: use case
intern first 500
could it tell her that 501 already exists

should id service manage this
should it flag if looks like a loan number?

angela: we can point in direction of best practice

patrick: if we detect dups, we need to know 
we may not be able to count on other services
need reservation case

dan:
stores a whole set of strings it can't allocate again
(unless released?)
stores patterns
pattern associated to activity or object (opaquely)

ID
old and new in same key field

ranges
ID numbers not reflect a count
used frequently
dash not replicated into actual records
comma etc.
a,b
b
both might exist

geology museum
amber samples, 10,000 or so pollen grains
important
nobody has accurate account
allocate 10,000 suffixes
create sub-objects

ranges at the object level
not just sub-object
.9 through .12


sub-objects suffixes
parts or components

gaps
generate numbers for provisional use
carl h
accession registers
have gaps
important 10 objects maintain continuity of numbers together
but no gaps between *those*
can be gaps between blocks of objects
jess: like herbaria at berkeley
patrick: will reserve a bunch, won't use all
given to prof for given collecting expedition
range is significant
carl h: some numbers may be half-given to someone
patrick: some numbers may be hidden, for faculty research
angela: wireframe, those numbers are sparse (not yet completed) records

first i want 10
second i want 5
fhird i want to release 2
with concurrency

deliberate action
for accessions
but for e.g. exhibits? possibly not

numbers are cheap
BUT
"we are professionals"
sequence has some semantics
accession numbers relate to legal transactions
help you literally count
e.g. for a year
for year-end reports

funky place
types in number - validates
need to place a reservation
find about stuff they've lost, might want to add later

don't know which are gaps in collecting expeditions
may yield some numbers
numbers are RESERVED but not created in CMS
reservation as first-order activity
and release


make link to genbank page
related to conservationspace
related to id of other museum, gen link

carl h:
1st: museum-to-museum sharing IDs
2nd out to service

pattern:
pattern to expose regex pattern
simple search box, what kind of a thing is this?
does this ID match ANY pattern?  If so, which?
Export the regex pattern for an ID pattern
so that some other service can use it

dan:
museum ids
and csids
what do we represent in urls
human-friendliness
'impure name' can gather info from it without lookup
'pure name' less human friendly, less likely to make incorrect assumptions

persistence
do we support urls with museum ids in them

patrick:
use urns
name numbering scheme you're using
/collectionobjects/urn:{scheme}:{number}
returns 0-n records (may not be unique)
may have multiple REST paths returned

dan
may create new records, get rid of old ones
csids may go away
records in different stage of workflow for same object

patrick:
thinking of csids to be inviolable
want them to be urns we can make sense of

dan
lecture notes are online at "/{long gobbli-di-goop}"

patrick:
museum policy
this number will be inviolable

some other thing in system
logic about how to provide 'permanent' urls for citation

carl h
a permaurl that is less evident

rest model
not necessarily permaurl
copy/paste, cite
as soon as intelligible, can potentially be wrong

sanjay:
id service
all patterns have to be tenant specific
OR could share
multi-tenancy implications
checking for duplicates or gaps
could also be tenant specific

patrick;
should generally always be tenant-specific
manage as
hash pool

could copy over patterns to new tenant
one-time
  • No labels