Semantic Mapping

In specifying ASF interfaces, it is necessary to have a way to communicate what metadata tags are considered semantically equivalent. For example, a crawler gathers HTML Meta tags in Danish intending to make them searchable through a GILS-compliant search engine. This requires a cross-walk of metadata elements from some particular metadata tagging syntax to whatever semantic mapping functions the search engine supports.

So, what if one wants to connect "anybody's crawler" with "anybody's GILS-compliant search engine"? Obviously, there must exist some mechanism to communicate the information needed for the semantic cross-walk.

What might be termed a semantic mapping function is quite common with search engine software, though it is typically handled by configuration files, set-up modules, embedded tables, or other implementation-specific mechanisms. In the Advanced Search Facility open architecture, this function needs to be exposed as a standard interface.

Such an interface ought to be machine-processable and fairly independent of particular implementations. It should also be readily extensible. An example of how such an interface might be expressed in XML is available.

Note that this discussion of semantic mapping as a message-passing mechanism anticipates and will merge into the ongoing work on Metadata Registries as these become widely supported. XML Tag Names are selected to evoke the corresponding object properties given in the ISO 11179 Metamodel. The naming ideas used here are explained in a brief discussion of Data Element Naming as envisioned in ISO 11179, written by Judy Newton of NIST and available.

Here's a bit of explanation about the example XML interface, which has about 300 metadata elements in it.

Each metadata element is regarded as a data element within the semantic map. Conceptual characteristics can be inherited through object classes, e.g., from the most general to the most specific. The representation characteristic is a non-inheritable property. For example, a semantic unit in the ISO11179-BSR context identified as "InformationResource.Originator.Name" has the conceptual semantics of the Object Class "InformationResource.Originator" and has the representation semantics of the Representation Class "name". (The names of semantic components in the Basic Semantic Registry use a dot notation to show the levels of abstraction. So, the semantic unit "InformationResource.Originator" in the ISO11179-BSR context itself inherits from the conceptual Object Class "InformationResource".)

A data element may be apprehended in one or more name contexts. A name context for a data element distinguishes a specific domain of concepts from other domains. Having multiple name contexts for a given data element implies that the semantics are equivalent for the purposes of this particular semantic map. For example, the data element tagged "InformationResource.Originator" in the ISO11179-BSR name context is asserted to be semantically equivalent to tag "710$a" in the MARC name context.

A data element in a name context can be characterized with various attributes in addition to its designation name (also known as a "tag name") and its definition text.