Mapping to BIBFRAME properties with a different rfd:type

[frosterus]

The National Library of Finland is creating a BIBFRAME-based data model for the Finnish national metadata repository. One of the biggest deviations from basic BIBFRAME for us is our extensive use of controlled vocabularies for rdfs:range values. This is in part due to the two official cataloguing languages (Finnish and Swedish) as well as our adherence to RDA and wish to present the cataloguer a set list of possible values.

For example, we want to take the possible values for bf:degree from our Metadata Vocabulary and therefore we wish to make our own version of the property, with a range referring to our vocabulary.

However, this changes the rdf:type of the property (bf:degree in this case) from rdfs:DatatypeProperty into rdfs:ObjectProperty. This precludes us from using rdfs:subPropertyOf in mapping back to the original BIBFRAME property. On the other hand, rdfs:seeAlso seems like a very weak connection when the purpose of the properties is the same.

Some other examples of BIBFRAME properties where we have similar challenges include: bf:noteType, bf:variantType, bf:instrumentalType, bf:ensembleType, bf:musicKey, and bf:voiceType.

What would be the most appropriate way to map back to BIBFRAME in these sorts of cases? Alternatively, is there a way that BIBFRAME could accommodate these types of property type differences?

[niklasl]

In our work with Libris XL at the National Library of Sweden we have also encountered this. We find datatype properties such as bf:degree limited since they cannot be used with reusable concepts/terms. We want to facilitate controlled terms with clear definitions and to leverage internationalization and concept mappings wherever possible.

In this case, it would be useful to define a new object property for this:

bf:hasDegree a owl:ObjectProperty ;
    rdfs:range bf:Degree .

For the existing simple property, which might be all you need in a local context, it is reasonable to define these as “shorthand properties” of the corresponding object property, where the shorthand represents the label of an implied referenced resource. This could be done like so:

bf:degree a owl:DatatypeProperty ;
   owl:propertyChainAxiom ( kbv:hasDegree :label )  .

(Note: Since owl:propertyChainAxiom expects a rdf:List of owl:ObjectProperty values, it can only be used with owl:DatatypeProperty values in OWL Full, where these are not disjoint with owl:ObjectProperty. In KBV we use this pattern in some cases, mostly to facilitate mapping of complex, qualified value properties to flat shorthand properties, which we in turn can map to simpler vocabularies, e.g. Dublin Core terms.)

If BIBFRAME was still a draft design we would recommend redefining the existing ones, but as it is a published and already used vocabulary by now, such redefinition would be a breaking semantic change.

[kefo]

This is only a partial response, but does our response here help?

#109

Also, for what it is worth, we are trying to move away from the *Type properties ourselves, but still have some work to do and probably won't be able to get away from them entirely. But when we do want to use a defined Class, we just use rdf:type. You can see that in the related link above.

[azaroth42]

Just get rid of all domains and ranges and make everything rdf:Resource, per #19 and similar ;) Problem "solved"!