Getting to higher MARC branches showed how the RDFS subPropertyOf property can be used to entail, or infer, RDF data triples with a broader semantic or meaning than the original, to “dumb-up” or aggregate data based on level 0 properties. Only the property or predicate part of the triple is different; the subject URI and object URI or literal remain unchanged.

The Target audience example represents one of several categories we have identified for the level 0 properties for the fixed-length data fields in MARC. This one is characterized as two or more properties with the same definition using the same Vocabulary Encoding Scheme (VES).

A more complex category is characterized as two or more properties with the same definition using the same VES where the underlying attribute allows  more than one value and the order of values is significant. An example is the 008 attribute Relief of maps:

RDF graph of MARC21 Relief of maps ontology (partial)

RDF graph of MARC21 Relief of maps ontology (partial)

“sP” in the graph stands for rdfs:subPropertyOf. The graph does not show the level 0 properties for Relief (2), (3), and (4).

This ontology separates the semantics of the order of the data from the type of data while preserving the data values. It offers any application a property for the most important relief type specified on the item being described (m21plus:M00Rel1 “Relief (1)”), a property for the second most important relief type (m21plus:M00Rel2 “Relief (2)”), etc., a property for the relief type regardless of importance (m21plus:M008MP18-21 “Relief of Maps”), etc., and a property for the relief type regardless of importance or category of material (m21plus:M00Rel “Relief”).

Target audience and Relief are, of course, at the level of attribute or relationship found in many other schemas. The rdfs:subPropertyOf property can be used to establish mappings as semantic relationships between similar properties in multiple namespaces, as described in our paper A reconsideration of mapping in a semantic world.

While properties may be similar in different namespaces, care has to be taken to avoid semantic incoherency and the inadvertent addition of false information into entailed triples. This has been  easy with the level 0 properties because the basic definitions are identical, and none of the properties is bound by a domain or range. The situation changes when properties from other namespaces are considered. Definitions may be the same in meaning, or broader or narrower. For example, the definition of m21plus:M00Aud, “The intellectual level of the target audience for which the material is intended”, is clearly narrower than the definition of the corresponding RDA property, “The class of user for which the content of a resource is intended, or for whom the content is considered suitable, as defined by age group (e.g., children, young adults, adults, etc.), educational level (e.g., primary, secondary, etc.), type of disability, or other categorization”. If the RDA property is declared a sub-property of the MARC21 property, resulting entailments will give values which are out of scope, for example type of disability, even if the constraint of the MARC21 VES for target audience is ignored. Conversely, declaring the MARC21 property as a sub-property of the RDA property does not lead to such problems, as RDA can accommodate the VES URIs within its scope and range.

However, it turns out we are on risky ground if we do this, because the RDA property has the FRBR class Work as its domain. This means that in any entailed triple, the URI of the MARC21 resource which is the subject of the original triple is inferred to be a work (a member of the class Work). But unless the MARC21 data has been pre-FRBRized, other triples with the same subject URI will entail triples stating the same resource is also a manifestation, etc., which breaks the FRBR model. Even though the RDA namespace is currently using its own “weak” version of the FRBR classes, there is no guarantee that it won’t link to the FRBR namespace in the future. The situation is therefore best avoided, and what is required is a version of the RDA property that does not have a domain. Fortunately, this was anticipated by the DCMI/RDA Task Group (now the DCMI Bibliographic Metadata Task Group), and “unconstrained” versions of all the RDA properties were added when the namespace was created, as described in our paper RDA vocabularies: process, outcome, use.

As a general procedure, then, a MARC21 high-level property can be mapped out to another namespace by using sub-property relationships, when the target property completely encompasses the MARC21 property and has no domain or range, or is completely encompassed by the MARC21 property and has no range (to avoid the VES issue). The entailed triples produced by the mappings allow maximum interoperability of MARC21 data with that from other schemas without transforming the data values.

By Gordon Dunsire, April 20, 2012, 9:39 am (UTC-5)

Add your own comment or set a trackback

Currently no comments

  1. No comment yet

Add your own comment

Follow comments according to this article through a RSS 2.0 feed