Category: Linked data

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:

“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.

In the previous blog I discussed Low-hanging MARC fruit in the MARC21 fixed-length data fields 006, 007, and 008. These fields also contain useful data that hangs slightly higher up, but can be reached with a short ladder. The ladder rungs are constructed using the RDF Schema subPropertyOf property. This is an ontological property which takes the RDF class Property as its domain and range; in other words, it links instances of two properties:

P1 rdfs:subPropertyOf P2 – where P1 and P2 are specific properties.

The subPropertyOf property contains the inference rule or entailment that:

If P1 rdfs:subPropertyOf P2, and X P1 Y, then X P2 Y

That is, if property P1 is a sub-property of property P2, then a machine can entail a triple using property P2 with the same subject and object as any triple using property P1.

There is a lot of semantic overlap in the MARC21 fields. For example, field 006 positions 01-17 relate to positions 18-34 in one of the field 008 configurations; they use the same values. 006 is used in cases when an item has multiple characteristics that cannot be coded in field 008. There is no semantic difference between the 006 and 008 data – a multi-component item may be catalogued as a whole using 008 for the main component and 006 for other components, or each component may be catalogued separately with its own 008 field.

We can aggregate this data by declaring sub-property relationships between corresponding 006 and 008 “level 0” properties and a new common super-property:

E.g. Create a new property M00Aud with label “Target audience”, and declare M006a05 (“Target audience of Language material”), M006t05 (“Target audience of Manuscript language material”) and M008BK22 (“Target audience of Books”) as sub-properties:

@prefix m2100x: <http://marc21rdf.info/elements/00X/>.
@prefix m21plus: <http://marc21rdf.info/elements/.../>.
m21plus:M00Aud rdfs:label "Target audience" .
m2100x:M006a05 rdfs:subPropertyOf m21plus:M00Aud .
m2100x:M006t05 rdfs:subPropertyOf m21plus:M00Aud .
m2100x:M008BK22 rdfs:subPropertyOf m21plus:M00Aud .

A machine can use this RDF graph to entail new triples from existing data:

ex:1 m2100x:M006a05 m21terms:commonaud#j .
=> ex:1 m21plus:M00Aud m21terms:commonaud#j .
ex:2 m2100x:M006t05 m21terms:commonaud#e .
=> ex:2 m21plus:M00Aud m21terms:commonaud#e .
ex:3 m2100x:M008BK22 m21terms:commonaud#g .
=> ex:3 m21plus:M00Aud m21terms:commonaud#g .

Here, three different resources (ex:1, ex:2, ex:3) have target audience data stored in three different MARC21 fixed-length fields. The entailed triples store the data using a common property that encompasses the semantic of the level 0 properties by discarding their differences, which are the material categories. Each entailed triple states “This resource has target audience …”, dropping the distinction of material category which is unnecessary for this metadata attribute.

Using the entailed triples, we only need to process the higher-level property to create, for example, a “Target audience” index for a set of MARC21 records, rather than having to gather the data from the level 0 properties every time.

We can go further. The same value vocabulary for Target audience is used for other categories of material:

• M006c05 (“Target audience of Notated music”)
• M006d05 (“Target audience of Manuscript notated music”)
• M006g05 (“Target audience of Projected medium”)
• M006i05 (“Target audience of Nonmusical sound recording”)
• M006j05 (“Target audience of Musical sound recording”)
• M006k05 (“Target audience of Two-dimensional nonprojectable graphic”)
• M006m05 (“Target audience of Computer file or Electronic resource”)
• M006o05 (“Target audience of Kit”)
• M006r05 (“Target audience of Three-dimensional artifact or naturally occurring object”)
• M008CF22 (“Target audience of Computer Files”)
• M008MU22 (“Target audience of Music”)
• M008VM22 (“Target audience of Visual Materials”)

So we can declare sub-property relationships between each of these level 0 properties and the higher-level “Target audience” property, and generate the entailed triples.

Note that we could create an intermediary rung on our ladder, say M00BKAud “Target audience (Language material)”, to aggregate data at the material category level, and then declare a sub-property relationship with M00Aud to aggregate to the category-free level. There is no specific use-case for this at the moment. If the need arises, this can be done without affecting the existing sub-property relationships and entailments, because the subPropertyOf property is transitive: P1 rdfs:subPropertyOf P2 and P2 rdfs:subPropertyOf P3 entails P1 rdfs:subPropertyOf P3.

Our ladder “dumbs-up” the level 0 data; each sub-property entailment uses a higher-level property that is broader in semantic than the last. The ladders merge at each stage and are just one rung in length, so what we get is more like a climbing net to get to the higher-hanging fruit.

Applications can now deal with just one attribute property for Target audience and avoid the messiness at level 0. And there is just one property to align and map to corresponding properties from other bibliographic metadata schemas …

It’s been six months since Diane Hillmann, Jon Phipps, and I published a “level 0” set of RDF elements (all properties) and value vocabularies based on the MARC21 format. That was largely a mechanical process, as we created a separate property for every combination of tag, two indicators, and subfield for most (but not yet all) tags in MARC Bibliographic. I hear this was well-received at the MARC Formats Interest Group session at ALA Midwinter in Dallas in January, with questions like “When are you going to do the same for MARC Holdings or MARC Authority?” Well, we’re thinking about it …

Meanwhile, I’ve been looking to see what low-hanging fruit can be plucked from the MARC tree of knowledge. The obvious place to start was the fixed-length data fields tagged as 006, 007, and 008. These have the least complicated mix of syntax and semantic, with no indicators or repeatable subfields to worry about. And there are value vocabularies associated with the coded content, so linked data triples with object URIs are a possibility.

The main complication is the dependency of the codes on the category of material, recorded in the MARC21 record Leader. This introduces a decision node in the process of recasting legacy metadata as RDF triples; it determines which code sets, and therefore value vocabularies, are being used. For all level 0 elements, the property URI is constructed mechanically from the MARC21 coding, so the decision only affects the choice of value vocabulary to be used as the object of the data triple.

The results are encouraging. Here’s a simple example from the record for “Legacy” by Roderick Buchanan, taken from the main catalogue of the National Library of Scotland. It has just a single 008 tag:

@prefix m2100x: <http://marc21rdf.info/elements/00X/>.
@prefix m21terms: <http://marc21rdf.info/terms/>.
ex:1
m2100x:M00806 m21terms:alltyp#s ;
m2100x:M00807-10 "2011" ;
m2100x:M00815-17 <http://id.loc.gov/vocabulary/countries/enk> ;
m2100x:M008BK29 "0" ;
m2100x:M008BK30 "0" ;
m2100x:M008BK31 "0" ;
m2100x:M008BK33 m21terms:booklit#0
m2100x:M00835-37 <http://id.loc.gov/vocabulary/languages/eng> .

Extending the object URIs to their labels gives the RDF graph:

A more complicated example is the CD version of Abbey Road by The Beatles, with one 006, two 007, and one 008 tags in a record from OCLC WorldCat:

@prefix m2100x: <http://marc21rdf.info/elements/00X/>.
@prefix m21terms: <http://marc21rdf.info/terms/>.
ex:5
m2100x:M00600 m21terms:formofmaterial#m ;
m2100x:M006m09 m21terms:computertyp#u ;
m2100x:M00700 m21terms:cat#s ;
m2100x:M00700 m21terms:cat#c ;
m2100x:M007c01 m21terms:electrosmd#o ;
m2100x:M007c03 m21terms:electrocol#c ;
m2100x:M007c04 m21terms:electrodim#g ;
m2100x:M007c05 m21terms:electrodsnd#a ;
m2100x:M007s01 m21terms:soundrecordingsmd#d ;
m2100x:M007s03 m21terms:soundrecordingspd#f ;
m2100x:M007s04 m21terms:soundrecordingcpc#s ;
m2100x:M007s05 m21terms:soundrecordinggro#n ;
m2100x:M007s06 m21terms:soundrecordingdim#g ;
m2100x:M007s07 m21terms:soundrecordingwid#n ;
m2100x:M007s08 m21terms:soundrecordingtap#n ;
m2100x:M007s09 m21terms:soundrecordingkin#m ;
m2100x:M007s10 m21terms:soundrecordingmat#m ;
m2100x:M007s11 m21terms:soundrecordingcut#n ;
m2100x:M007s12 m21terms:soundrecordingspc#e ;
m2100x:M007s13 m21terms:soundrecordingcap#e ;
m2100x:M00806 m21terms:alltyp#r ;
m2100x:M00807-10 "2009" ;
m2100x:M00811-14 "1969" ;
m2100x:M00815-17 <http://id.loc.gov/vocabulary/countries/cau> ;
m2100x:M008MU18-19 m21terms:musicfoc#rc ;
m2100x:M008MU20 m21terms:musicfom#n ;
m2100x:M008MU21 m21terms:musicpar#n ;
m2100x:M008MU33 m21terms:musictra#n ;
m2100x:M00835-37 <http://id.loc.gov/vocabulary/languages/eng> .

This yields the (partial) extended RDF graph:

The MARC Bibliographic manual says “Coded data elements are potentially useful for retrieval and data management purposes“. Any graph connecting to these examples can use them for retrieval, provided the resources URIs ex:1 and ex:5 are linked to the location of one or more copies. For open online resources this might be sufficient, because the resource is a “link” away. For physical resources, more information is required to get access (retrieve), including basic human identification attributes such as title, author, and edition. That additional data is usually present in the MARC21 variable data fields, and I’ll discuss it in a future blog post, but it doesn’t have to come from there. So what we need are stable URIs for the resources ex:1 and ex:5, and some triples containing location information for copies. OCLC has a lot of that data in one place. Next most helpful are standard identifiers such as ISBN and ISSN, because they will help to link to graphs from the publishing, bookselling, and reading communities. Then some title, author, and edition information would be nice …

It would be very useful if national, regional, or international cataloguing agencies could get it together to put this on their agendas, soon.

Finally, notice the “0” values in ex:1 and the “not applicable” value in ex:5. The MARC21 fixed-length data fields support theOpen World Assumption, unlike the MARC/AACR record as a whole, which definitely uses the Closed World Assumption, for example by not recording a first-edition statement.