TNS Internal:NDR/API/2.0/implementationDetails/Metadata Records

From NSDLWiki

Return to NDR/API 2.0 Requests By Object

Contents [hide] 1 NDR API Implementation Details - Metadata Records 2 Current Functioning 2.1 General Characteristics 2.1.1 properties 2.1.2 relationships 2.1.3 datastreams 2.2 Usage by Applications 2.2.1 Harvest Ingest 2.2.2 NCS 2.2.3 WFI 3 Proposed Implementation 4 Differences Between Existing Model and Proposed Model 4.1 New Property: externalIdentifier 4.1.1 General Behavior: 4.1.2 Option 1: 4.1.2.1 Implementation: 4.1.2.2 Impact: 4.1.3 Option 2: 4.1.3.1 Implementation: 4.1.3.2 Impact: 4.1.4 Option 3: 4.1.4.1 Implementation: 4.1.4.2 Impact: 4.1.5 Option 4: 4.1.5.1 Implementation: 4.1.5.2 Impact: 4.2 API Links: 4.3 Additional Links Related to This Call:

Under Construction
Proposed method for inclusion in NDR/API 2.0.

Please provide feedback and comments using the Discussion tab on this page.

NDR API Implementation Details - Metadata Records

Create a collection for aggregating objects providing provenience that identifies the provider(s) of metadata and information stored as a part of this collection. See Community:NCore/Model/CompositeObjects/Collection. Diagram repeated here for clarity.

Current Functioning

addMetadata v1.0

General Characteristics

Metadata objects in the current NDR model...

properties

• uniqueID - unique to a MetadataProvider
• itemId - required if metadata is exposed in the OAI feed produced by NDR; otherwise, optional

relationships

• metadataFor - metadata object being described by this metadata
• metadataProvidedBy - source of this metadata

datastreams

• store metadata in multiple formats,
• each format is stored in a separate datastream
• each format requires an additional info datastream that holds information that is exposed in the OAI feed produced by NDR

Questions & Assessment:

• properties
  • uniqueID is similar in concept to the proposed externalIdentifier - see description below
  • itemId is not exposed in the proposed v2.0 addMetadataRecord request. Should it be?
• relationships
  • metadataFor and metadataProvidedBy are handled under the covers, so we're ok here
• datastreams
  • the current proposal does not provide a means for saving multiple formats of metadata
  • the current proposal does not provide a means for adding the info datastream
    • will we still be producing PUBLIC_OAI and SEARCH_OAI?

Usage by Applications

The v1.0 addMetadata request is used by Harvest Ingest, NCS, and WFI. Each uses addMetadata in the following ways.

Harvest Ingest

from email by Tim

"Harvests from OAI sources are always transformed into nsdl_dc. The original metadata format (even nsdl_dc) is retained as a separate datastream along with the nsdl_dc that is created by the harvest/ingest process.

There is a bit of data clean-up and normalization attempted for all incoming OAI-harvested data. Date values and URL values, for example, are normalized and identified with the appropriate qualifications (if possible) and the result becomes part of the transformed nsdl_dc.

The transformed nsdl_dc is what the served OAI records use as a source."

NCS

WFI

Currently does not use metadata; WFI/FeedEater stores all of its information within MetadataProvider objects.

Proposed Implementation

The implementation for the concept of Metadata Records is basically the same as the existing concepts in the NDR Metadata Object. The API will hide the structure of the metadata object, but ultimately produces the same object structure.

Differences Between Existing Model and Proposed Model

New Property: externalIdentifier

externalIdentifier (optional) - Application determines the value.

General Behavior:

externalIdentifier is optional externalIdentifier is required to be unique (see options for scope of uniqueness)

Option 1:

Implementation:

Validation confirm uniqueness - fail API request if not unique within Metadata Provider's scope Implement as NDR property in RELS-EXT passed in value would be stored in the NDR property externalIdentifier

Impact: uniqueID is deprecated existing uniqueID values are left unchanged All existing metadata objects would need to have current uniqueID value copied into externalIdentifier

Option 2:

Implementation:

Validation confirm uniqueness - fail API request if not unique within NDR Implement as NDR property in RELS-EXT passed in value would be stored in the NDR property externalIdentifier

Impact: uniqueID is deprecated existing uniqueID values are left unchanged All existing metadata objects would need to have current uniqueID value copied into externalIdentifier How to handle the situation where the uniqueID value is not unique within all NDR?

Option 3:

Implementation:

Validation confirm uniqueness - fail API request if not unique within NDR Implement as NDR property in RELS-EXT passed in value would be stored in the NDR property uniqueID

Impact: Validate uniqueness of uniqueID within NDR for all existing metadata objects How to handle the situation where the uniqueID value is not unique within all NDR?

Option 4:

Implementation:

Validation confirm uniqueness - fail API request if not unique within Metadata Provider's scope Implement as NDR property in RELS-EXT passed in value would be stored in the NDR property uniqueID

Impact: NONE - No impact on existing objects in the NDR

API Links:

• Conceptual Framework (2.0 philosophy)
• APIBasics
• ObjectTypes
• Encoding
• APIRequestsByObject v1.0
• APIRequestsAlphabetical v1.0
• APIRequestsByObject v2.0

Additional Links Related to This Call:

addMetadataRecord	[ Implementation | Specification ]
getMetadataRecord	[ Implementation | Specification ]
modifyMetadataRecord	[ Implementation | Specification ]
deleteMetadataRecord	[ Implementation | Specification ]
listMetadataRecords	[ Implementation | Specification ]
listMetadataIdentifiers	[ Implementation | Specification ]