ADN Framework Overview A Collaboration of ADEPT, DLESE and NASA (2002 Nov. 19)

2 Meeting Purpose Provide the technical overview of ADN. Raise issues or concerns on how ADN will affect DLESE systems. Presentation covers: Constructing the framework XML schema development Metadata use concepts Overview (semantically and technically) of framework categories

3 Framework Purpose Capture resource information in a structured format for discovery emphasizing : Plug-n-play vocabs and framework components Enforcement of vocabs and required metadata Geospatial, time, educational standards, concepts and new educational elements The ability to handle offline resources The use of XML schemas for use with OAI

4 Constructing the Framework Framework is wrapped by 1 overarching schema Framework is broken into 11 category schemas with each defining distinct metadata fields Framework uses ~35 vocabulary schemas An instance document (metadata record) validates against the overarching schema (NOTE: plug-n-play feature of the framework and vocab schemas is used in other DLESE frameworks… e.g. the collection framework uses the metaMetadata section)

5 The XML of the Framework Overarching schema: record.xsd calls general.xsd (mandatory) - general characteristics like title descrp. lifecycle.xsd (optional) - who created the resource metaMetadata.xsd (mandatory) - who cataloged the resource and status technical.xsd (mandatory) - computer and browser requirements educational.xsd (mandatory) - audience, learning goals, standards rights.xsd (mandatory) - copyright relations.xsd (optional) - relationships to other resources geospatial.xsd (optional) - spatial data (boundinb box coordinates) temporal.xsd (optional) - temporal data (time past, present & future) space.xsd (optional) - astronomy data commonfields.xsd (does not appear; used by the above schemas)

6 XML Schema Development 1 Namespaces Uses chameleon approach Means only record.xsd has an explicit target namespace. (aside: NSDL has 4 namespaces) Category schemas use the namespace of any schema that calls them (record.xsd here). Root element Is and is ADNmetadataType

7 XML Schema Development 2 Approach Uses the Venetian Blind approach… means… Fields are defined as built-in, complex or simple types (facilitates for re-use) Elements occuring more than once use wrapper tags ( is wrapped by ) Elements and Attributes Schema elements are generally ADN fields Attributes are used for required additional information or if two bits of info. are required

8 XML Schema Development 3 Controlled Vocabularies Hierarchal vocabularies appear as colon separated text (e.g. DLESE:Forestry) Some elements use fixed vocabs Multiple vocabs must use a simple type element commonfields.xsd Used when metadata fields (elements or attributes) appear in multiple schemas. E.g., title is in general.xsd & relations.xsd; so title defined commonfields.xsd

9 Metadata Use Concepts 1 Required metadata w/o contr. vocabs Element must appear Content must be present and valid Required metadata with contr. vocabs Element must appear with a vocab choice OR Allows the use of a default value like ‘DLESE:To be supplied’ in order to facilitate validation Tag content cannot be null (empty)

10 Metadata Use Concepts 2 Non-required w contr vocabs Element only appears if it has content The content must be from the authorized controlled vocabs is not required. But if vertical info, is entered then becomes required Non-required w/o a contr vocab Element only appears if it has content Generic description field for all categories

11 Fields: tag set Subjects: Required metadata from vocabs Keywords: Non-required, free text terms Concepts: Non-required metadata from vocabs supported by a schema at the DPC OtherTerms: Non-required metadata from a vocab house elsewhere; provide service name, URL and ID # and terms Simple Place & Time: defer to geospatial CatalogEntries: Other classifications

12 Fields: tag set Person info Name (first, last, middle) Institutional name and department Primary and alternate Reference number (if one) to an LDAP directory Organization info Institutional name and department Institutional URL or generic Reference number (if one) to an LDAP directory

13 Fields: CatalogEntries: Required record number Date Info: created, accessioned, modified (and deaccessioned) created and modified are required Status: accessioned etc. and an optional description Scheme, copyright, use, language: All required of the metadata

14 Fields: tag set Online Primary url and mirror urls Medium (mime type) Size, Duration Browser and other requirements Offline Description Access information Object type (rock, book, videotape)

15 Fields: tag set Expanded audience Uses GEM vocabs (toolFor, beneficiary, teaching methods) Educational standards (content, process, and teaching) that are from NSES, NCGE, NCTM Interactivity level and type Old learning context is now gradeRange Audience repeats while gradeRange is the only required audience field

16 Fields: tag set IdEntry: when an ID is known; must be in the same catalog record number set as the item being cataloged URLEntry: when only a URL is known; will include title and description Can these be the same or do we need to keep separate to differentiate ID vs. URL?

17 Fields: tag set 1 big bounding box with multiple detailed geometries Separate place and events now More required elements Use simple place and event when bounding box coordinates are unknown

18 Fields tag set Completely independent of geospatial Each timeAndPeriod allows 1 time value but multiple period names; tag can repeat Choose between timeAD timeBC timeRelative- 30 days ago, 100 million years ago Use simple temporal when time range is non-numeric (e.g. day, fall, morning)

19 Issues Serialization of vocabs: Does it work? Geospatial: NSDL wants us to write: City: Denver, CO, United States Region: Great Plains, United States State: Colorado, United States Relation: can I make identry and urlentry the same? Or keep separate? Namespaces: ADN only has 1 but NSDL annotation will have 4