Child pages
  • Service-Oriented Levels of Metadata Adoption

This space has moved to IU's Confluence.
It is located at https://uisapp2.iu.edu/confluence-prd/display/iulDLFAquifer/

Skip to end of metadata
Go to start of metadata

Service-Oriented Levels of Metadata Adoption

The current draft of services tied to the metadata levels of adoption seem to be an afterthought, brainstormed as way to have the MODS encoding guidelines be less burdensome. Some areas of concern from a service-oriented perspective:

  • Can't I browse on subject, language, date, or typeOfResource?
  • Can't I limit searches/filter on genre, name/role, or more specific subject sub-elements?
  • Do I really need all level 5 elements to effectively evaluate a resource?
  • Etc.

The draft below attempts to start from the users service-oriented perspective in the spirit of creating a dialog between SWG and MWG.

Whatever finalized guidelines/requirements emerge, it is important to note that Aquifer has invested a tremendous amount of effort into the creation of MODS encoding guidelines and levels of adoption. It is important that the portal user interface take advantage of this work and that Aquifer's assessment determine if these encoding guidelines and levels of adoption are useful to scholars. Evidence-based guidelines that are ground-tested by actual end-users in an interface of a live service, are more compelling than those developed in the abstract.

Level A. A user is able to identify a resource (to reference, for future re-discovery)

Simple search

Simple search should just be a single search box with no limits at all, like Google.

For this index, should we index entire record or should this be a superset of each separate fielded index? Is there anything in the record that shouldn't be indexed?

Results display

Display Label

Brief Display Notes

XPath

Comments

URL

Do not display the value; make it the target for the hyperlinked Title

/mods/location/url[@usage="primary"]

 

Title

Hyperlink with the URL

/mods/titleInfo/title

 

[Thumbnail image]

Resize x and y with HTML?

In Asset Action? Also in MODS?

Only required for images/video

Date

Show one date only

/mods/originInfo/dateCreated/*

Date that the original object was created; not necessarily machine readable

For alternative approches for the minimal fields required for identification, see:

Level B. A user is able to find resources through a process (search and/or browse) that offers a modest amount of precision.

  • Not yet clear if browse is possible.
  • Are there some data elements that we should suppress (not display at all)?

Display Label

Expose on Advanced Search Form?

Expose as Browse Facet?

XPath

Comments

URL

No

No

/mods/location/url[@usage="primary"]

 

Title

Yes

No

/mods/titleInfo/title

 

Date [Created]

Yes, with constrained options

Yes, if date normalization yields good results. Can these be hierarchical? Era, then Decade, then Year

/mods/originInfo/dateCreated[@keyDate="yes" and encoding="w3cdtf"]
/mods/originInfo/dateIssued[@keyDate="yes" and encoding="w3cdtf"]
/mods/originInfo/copyrightDate[@keyDate="yes" and encoding="w3cdtf"]

Date that the original object was created only (or copyright date); other dates (dataCaptured, dateValid, dateModified, dateOther) seem irrelevant for searching (and display?)

Creator

Yes

Yes

/mods/name/*

 

Terms and Conditions of Use

Checkbox for unrestricted

Yes

/mods/accessCondition/*

 

Subject

Yes

Only if meaningful; probably requires enhancement

/mods/subject/*

 

Geographic Coverage

Yes

Only if meaningful; probably requires enhancement

/mods/subject/geographic/*
/mods/subject/geographicCode/*
/mods/subject/hierarchicalGeographic/*
/mods/subject/cartographics/*

 

Coverage Date (what to call this?)

Yes

Only if meaningful; probably requires enhancment

/mods/subject/temporal/*

 

Level C. Everything else. These fields allow users to perform searches with a high degree of precision, browse winnowing, and disambiguation between related resources.

Not yet finished

Required MODS

Display Label

Expose on Advanced Search Form?

Expose as Browse Facet?

Expose on Full Record Display?

XPath

Comments

URL

No

No

Hyperlink this

/mods/location/url[@usage="primary"]

 

Title

Yes

No

Render as is

/mods/titleInfo/title

 

Date [Created]

Yes, with constrained options

Yes, if date normalization yields good results. Can these be hierarchical? Era, then Decade, then Year

Show raw date, not normalized dates

/mods/originInfo/dateCreated[@keyDate="yes" and encoding="w3cdtf"]
/mods/originInfo/dateIssued[@keyDate="yes" and encoding="w3cdtf"]
/mods/originInfo/copyrightDate[@keyDate="yes" and encoding="w3cdtf"]

Date that the original object was created only (or copyright date); other dates (dataCaptured, dateValid, dateModified, dateOther) seem irrelevant for searching (and display?)

Creator

Yes

Yes

Need specs for the how to format all the different elements in here.

/mods/name/*

 

Terms and Conditions of Use

Checkbox for unrestricted

Yes

Needs specs for how to render multiple elements

/mods/accessCondition/*

 

Subject

 

 

 

 

Language

 

 

 

 

Genre

 

 

 

 

Format

 

 

 

 

Genre

 

 

 

 

Genre of original item

Subject

 

 

 

 

 

Language

 

 

 

 

 

Collection

 

 

 

 

 

Geographic Location

 

*Country/State
*City

 

 

 

Recommended MODS

Display Label

Expose on Advanced Search Form?

Expose as Browse Facet?

Expose on Full Record Display?

XPath

Comments

  • No labels