Can BIBFRAME use openWEMI?

[kcoyle]

How would this work? Is it necessary?

[HughP]

I don't think that BIBFRAME and WEMI are compatible... WEMI is a four tier model while BIBFRAME is a three tier model.

In what ways were you thinking that they might work?

[kcoyle]

@HughP It undoubtedly needs more explaining, but the basics are this: in RDF, classes are semantic. There are times when they are also structure, but that is often a holdover from object-oriented classes. In RDF, a property (not a structure) can be associated with a class. So you can have properties within a shape with arcs that belong to different classes. It isn't the number of structural tiers that matters but the class semantics of the properties. And note that if the classes are not disjoint, any property can be a member of more than one class.

It undoubtedly needs more explaining...

[kcoyle]

Here are some examples of how, in my thinking, BIBFRAME could make use of openWEMI. openWEMI classes would need to be defined as rdf:domain values on BIBFRAME properties. My understanding is that adding these properties would not interfere with the use of BIBFRAME qua BIBFRAME, but the BIBFRAME community would need to decide to use openWEMI.

Note that it would not be sufficient to subclass BIBFRAME classes to openWEMI. A primary reason is that BIBFRAME Work may combine openWEMI Work and Expression. The other reason is that BIBFRAME does not include domains for all of its properties so using subclassing would be an incomplete solution.

This property has a domain of .../bibframe/Work:

<owl:DatatypeProperty rdf:about="http://id.loc.gov/ontologies/bibframe/musicOpusNumber">
<rdfs:domain rdf:resource="http://id.loc.gov/ontologies/bibframe/Work"/>
<rdfs:range rdf:resource="http://www.w3.org/2000/01/rdf-schema#Literal"/>
<skos:definition>
Numeric designation of a musical work assigned by a composer, publisher, or a musicologist.
</skos:definition>
<rdfs:label>Music opus number</rdfs:label>
<dcterms:modified>2016-04-21 (New)</dcterms:modified>
</owl:DatatypeProperty>

It could also have a domain of .../openwemi/work and this would mean that the property confers both classes on its subject:

<owl:DatatypeProperty rdf:about="http://id.loc.gov/ontologies/bibframe/musicOpusNumber">
<rdfs:domain rdf:resource="http://id.loc.gov/ontologies/bibframe/Work"/>
<rdfs:domain rdf:resource="http://example.com/openwemi/Work"/>
<rdfs:range rdf:resource="http://www.w3.org/2000/01/rdf-schema#Literal"/>
<skos:definition>
Numeric designation of a musical work assigned by a composer, publisher, or a musicologist.
</skos:definition>
<rdfs:label>Music opus number</rdfs:label>
<dcterms:modified>2016-04-21 (New)</dcterms:modified>
</owl:DatatypeProperty>

BIBFRAME "carrier" could have the domain of ...openwemi/Manifestation:

<owl:Class rdf:about="http://id.loc.gov/ontologies/bibframe/Carrier">
<rdfs:label>Carrier type</rdfs:label>
<rdfs:domain rdf:resource="http://example.com/openwemi/Manifestation"/>
<skos:definition>
Categorization reflecting the format of the storage medium and housing of a carrier.
</skos:definition>
<dcterms:modified>2016-04-21 (New)</dcterms:modified>
</owl:Class>

BIBFRAME "illustrativeContent" is suggested to be used with either bf:Work or bf:Instance, but is generally considered to be FRBR Expression information.

<owl:ObjectProperty rdf:about="http://id.loc.gov/ontologies/bibframe/illustrativeContent">
<rdfs:range rdf:resource="http://id.loc.gov/ontologies/bibframe/Illustration"/>
<rdfs:domain rdf:resource="http://example.com/openwemi/Expression"/>
<skos:definition>
</skos:definition>
<rdfs:comment>Suggested use - With Work or Instance</rdfs:comment>
<rdfs:label>Illustrative content information</rdfs:label>
<dcterms:modified>2016-04-21 (New)</dcterms:modified>
</owl:ObjectProperty>

[niklasl]

It could work, given that they are both open models (with no disjoint classes nor any closed domains or ranges).

Consider a case "in the wild", which could map to openWEMI for reasons of interoperability. The KBV application vocabulary which we've defined at the National Library of Sweden (KB) contains mappings to many other ontologies, with a focus on BIBFRAME, but also to Schema.org, Dublin Core, the PREMIS "intellectual entity", and the (now deprecated) FRBR Entities for RDA. (Since the latter uses disjoint classes we only used SKOS matches to those.)

See kbv:Endeavour, which is the "WEMI root" here, from which you can navigate down to Work, Instance and Item (kbv:Work and kbv:Instance are subclasses of a common "abstract" kbv:Creation class, and kbv:Instance and kbv:Item are subclasses of kbv:Embodiment).

(Aside: these classes, in particular kbv:Creation and kbv:Embodiment, are defined specifically to guide our search and editing services (and to avoid owl:unionOf in favour of ("abstract") superclasses in a set of terms we are in full control of). They might be beneficial in general, but in the case of openWEMI I would approach that conservatively, avoiding the "power of OWL" to ensure openness "at the top"; which I believe is in its design.)

KBV is an "application vocabulary", in the sense that it is designed for our specific datasets and applications upon those; and drives the search and cataloguing interfaces (controls which terms belong to what, labelling, and so forth). Of interest for openWEMI though, is that it is, through its mappings to other vocabularies, used with the Target Vocabulary Maps mechanism to provide Profile Negotiation for some predefined target selections of the mapped terms. (I believe this can be further evolved to drive the progress of practical, automated linked data interoperability.)

For instance, here is our description of "Catcher in the Rye" in source form plus three "dialects":

• Catcher in the Rye described using Just KBV
• Catcher in the Rye described using mostly BIBFRAME
• Catcher in the Rye described using mostly Schema.org
• Catcher in the Rye described using a mix of DC terms, BIBO and other classical vocabularies.

The last example could include openWEMI in its selection of terms (as concrete rdf:type objects, or perhaps usingdc:type, depending on what is needed in a paricular exchange for reuse (cf. #5, #6)).

It is certainly true that BIBFRAME is rather unconstrained. This is why we in KBV have additional axioms, among other things the kbv:Creation and kbv:Embodiment classes, in order to control what properties (also mapped to BIBFRAME where possible), belong to which classes. It could certainly be modelled less directly (using e.g. SHACL or ShEx), but since our application must still do further reasoning (but only as much as we need) to utilize our axioms, and since it (KBV) intentionally imposes our particular world view (as gnarly as it may be in the corners, due to legacy data), we're not expecting BIBFRAME in general to necessarily agree on our choices and narrowing. (I may prefer to align more, to make interoperability more precise, but it comes at the cost of excluding other interpretations.)

I believe openWEMI could also be used (as base classes), in some of the other "bibliographic dialects"—BIBFRAME in particular—rather than us relying on KBV as the sole intermediary for interoperability. In practise that would mean that the other vocabularies would map "up" to openWEMI (which I believe is intended to be, akin to DC terms, a top-level, unrestricted set of pivotal vocabulary symbols to align against). This would be much more judicious, and not carry as much conceptual exclusion as a full application ontology intentionally represents.

To ask for other, "general" vocabularies to add these mappings is not necessary, as the above approach exemplifies. It comes down to what a particular ontology is designed for; i.e. what kind of context it intends to be used in, how bounded it is, and its inherent level of precision. The more precise it is, the more power it has to drive concrete applications. But as just mentioned, that comes with idioms, beliefs, and, really, a "restriction of the world" that the defined terms are capable of describing (or "depicting"). The needs for explicit agreements about this increases for each "specificity".

So the question is at what level openWEMI can be used within this interoperability framework, and whether BIBFRAME is above, next to or below that in terms of specificity and bounded context. It may be below it, as in being a bit more concrete in application. If that would be the consensus, it should map to openWEMI to benefit a wider audience. If not, application vocabularies such as KBV can, hopefully, still leverage the intersection of these designs to further automated interoperability during data exchange.

[kcoyle]

@niklasl Thanks for the detailed description. I like the idea of giving a unifying classes of creation and embodiment. I'm not sure how those intermediate classes can be squared with openWEMI but will see if others have ideas. The question is how to insert a class between Work and Endeavor, when Work has already been defined with Endeavor as its super-class. I presume this means one would end up with multiple superclasses for WEMI, e.g. Work would be a subclass of Creation and of Endeavor, and Creation would also be a subclass of Endeavor.

flowchart BT
A((kb:Endeavor))
B((kb:Creation))-->A
D((kb:Work))-->B
E((ow:Work))-->F
F((ow:Endeavor))
A-->F
D-->E

This looks complicated to me, and I wonder if there isn't a better solution.

Without openWEMI, I think your design looks like this, although you've given some different names to WEMI, if I understand correctly:

flowchart BT
A((Endeavor))
B((Creation))--> A
C((Embodiment))--> A
D((Work))--> B
E((Expression))--> B
F((Manifestation))--> C
G((Item))--> C

[lagbolt]

Here's a diagram of the KBV classes and subclasses:

I included the left hand side and "Serial Edition" for completeness, although they're not required for WEMI.

Writing "ow" for OpenWEMI, is this the correct mapping:

ow:Work = kbv:Work ow:Expression = kbv:Instance ow:Manifestation = kbv:Item ow:Item = kbv:Representation

-- Graeme

[lagbolt]

Two diagrams showing explicit mappings between OpenWEMI and KBV. The first diagram shows all classes separate; the second shows the case where openwemi:Endeavor is the same as kbv:Endeavour.

[kcoyle]

Here's a diagram of openWEMI and BIBFRAME:

You could define Bibframe Work as a subclass of openWEMI Work and Expression, Bibframe Instance as a subclass of openWEMI Manifestation, and Bibframe Item a subclass of openWEMI Item.

There might be more that could be done using domains on property definitions, but it looks to me like Bibframe isn't making much use of domain declarations on properties. The RDF/XML uses bf:Work like this:

<rdf:RDF>
<bf:Work rdf:about="http://id.loc.gov/resources/works/6487526">
<bflc:aap>
Melville, Herman, 1819-1891. story of Moby Dick, the white whale
</bflc:aap>

I don't really know how to interpret this. The JSON version (a bit hard to include here) seems closer to what I'm used to seeing. It lists bf:Work as a JSON @type with the ID of the Work as its object. There doesn't seem to be anything in the Work data that would connect to any specific properties to an Expression.

[HughP]

Is each ow: class a sub-class directly of ow:Endeavor or are they nested within a parent class? Do bf: classes overlap 100% or only partially with ow: classes?

Hugh

On Sun, Jul 16, 2023 at 12:42 PM Karen Coyle @.***> wrote:

Here's a diagram of openWEMI and BIBFRAME: [image: Screenshot 2023-07-16 at 9 22 11 AM] https://user-images.githubusercontent.com/1564129/253816144-00b59851-2013-46d3-9262-0abdab145f1f.png

— Reply to this email directly, view it on GitHub https://github.com/dcmi/openwemi/issues/7#issuecomment-1637135376, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAJ2JXKS6PH7Y6NROBX5MDXQQKYHANCNFSM565X5OAA . You are receiving this because you were mentioned.Message ID: @.***>

-- All the best, -Hugh

Sent from my iPhone

[kcoyle]

@HughP The openWEMI classes are each subclasses of Endeavor. The Swedish national library has added an intermediary class between the WEMI classes and Endeavor. We think this can still work with openWEMI, as per the diagram above, assuming that their Endeavor class is subclassed to openWEMI:Endeavor. I'm less clear about the question of subclassing their WEMI to openWEMI, and I think we need more discussion about that.

As for BIBFRAME, I think that's an open question. BIBFRAME vocabulary does not always make use of domains that would make it possible to connect properties in the vocabulary to WEMI or BF upper classes (bf:Work, Instance, Item). (This is how it looks to me, anyway.) There are some properties that look like:

<owl:DatatypeProperty rdf:about="http://id.loc.gov/ontologies/bibframe/musicKey">
    <rdfs:domain rdf:resource="http://id.loc.gov/ontologies/bibframe/Work"/>

but others are:

<owl:ObjectProperty rdf:about="http://id.loc.gov/ontologies/bibframe/geographicCoverage">
    <rdfs:domain rdf:resource="http://www.w3.org/2000/01/rdf-schema#Resource"/>

or:

<owl:DatatypeProperty rdf:about="http://id.loc.gov/ontologies/bibframe/mainTitle">
    <rdfs:domain rdf:resource="http://id.loc.gov/ontologies/bibframe/Title"/>

And I do not know why or what is intended. However, if we were to (theoretically) subclass bf:Work to ow:Work AND ow:Expression then when musicKey is used in instance data you would infer that the subject is a member of three classes: bf:Work, ow:Work, and ow:Expression. rdf-schema#Resource is a kind of default, and would be SUPER openWEMI so there is no connection that we can make there.

BIBFRAME also has properties with a kind of internal class membership, like bf:Title, which unites all of the title properties, but which is not associated with any of the BF upper classes. The "upper" classes are used in instance data to define what some call "shapes." That is, the work "shape" is given a class of Work, but many of the properties used with Work do not have Work as a domain. I assume that somewhere there is a document or discussion that explains this, and if anyone can bring clarity to this, I would love to hear it!

[lagbolt]

Well, here's my attempt at making sense ...

(I hope you appreciate my attempt at white-out!)

[kcoyle]

What all of this brings up for me is that the defined vocabulary and the instance data are not one and the same. And that is definitely true if you concede that most applications are not making use of inferencing, therefore the instance data has its own structure. I think we need to make sure that the openWEMI vocabulary works both with and without inferencing, and that it doesn't interfere with the creation and validation of actual data. That's a big requirement, but worth thinking through.