search

eXtensibleCatalog / Metadata-Services-Toolkit

Tools for processing and aggregating metadata
Other
6 stars 3 forks source link

Transformation: Add config file capabilities for embedded holdings #550

Open patrickzurek opened 7 years ago

patrickzurek commented 7 years ago

JIRA issue created by: jbowen Originally opened: 2011-09-06 05:31 PM

Issue body: (nt)

patrickzurek commented 7 years ago

JIRA Coment by user: jbowen JIRA Timestamp: 2011-09-06 05:35 PM

Comment body:

This is a follow-up to Fogbugz 730, where Dave first defined the black list/white list capability. This was handled for the short term by defining the black list in the Normalization config file. We will need both the black list and white list in Transformation 2.0 since records coming out of Aggregation will not have an org code in 003.

Then for the Transformation service (current one) as well as the next-generation transformation service (that will incorporate aggregation features), we will add this feature:

A config file that includes: 1) Whitelist: a list of ORG codes that can be used to hold a MARC Holding record. 2) Blacklist: a list of ORG codes that can be ignored for holding MARC Holding records.

So we will offer the ability for an institution to configure their transformation service to either list all of the ORG codes that will be in their BIB records, or to list all of the ORG codes that are in their holding records, but not in their bib records. It is an error to create a config file that has both a whitelist AND a blacklist configured.

So, for Rochester, we could have a config file like this:

ORG-whitelist: NRU, NRU-A, NRU-Mus, NRU-M

Or, we could have a config file with this line in it:

ORG-blacklist: OCoLC

In both cases, the actual output of the service should be identical.

For a large organization like CARLI, they would be able to use the blacklist feature (to avoid listing 70 ORG codes in their config file).

I noticed that the UR has multiple ORG codes, one for each of the other libraries... do we use these? (NRU-A for memorial art gallery, NRU-Mus for Sibley). If we use these, then the whitelist would be:

ORG-whitelist: NRU, NRU-A, NRU-Mus, NRU-M, NRU-W

patrickzurek commented 7 years ago

JIRA Coment by user: jbowen JIRA Timestamp: 2012-04-06 04:20 PM

Comment body:

Just changed the title. Goes with 766 (Normalization changes)

patrickzurek commented 7 years ago

JIRA Coment by user: rcook JIRA Timestamp: 2012-04-30 05:08 PM

Comment body:

As we prepare to move to Jira tomorrow, I don't want to move any issues assigned to Ben, so moving them all to John (sorry John).

patrickzurek commented 7 years ago

JIRA Coment by user: jbowen JIRA Timestamp: 2012-06-01 04:22 PM

Comment body:

I've now posted the spec for this to Google Docs: https://docs.google.com/document/d/1CUuXH0ULYGwR1wT8OB5iR8eq0qjrKJIXUY947DdcAGs/edit

The trans service config file that I mocked up is also in Google docs and relates to this: https://docs.google.com/document/d/1gOSNSJTAQpQ_SiU0ZbLBtSieecTH99C1ukDYaQNlNo4/edit

patrickzurek commented 7 years ago

JIRA Coment by user: rcook JIRA Timestamp: 2013-01-28 11:04 AM

Comment body:

Chris Delis is in process of releasing the 1.4.1 suite of MST services. He has commented out the incomplete embedded holdings code (http://code.google.com/p/xcmetadataservicestoolkit/source/detail?r=3486 ). This includes the first release of the MARC Aggregation service.

Jennifer's last post in this issue links to her specs to build the correct functionality for embedded holdings.

[~acarot] [~salva]