-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can BIBFRAME use openWEMI? #7
Comments
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? |
@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... |
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:
It could also have a domain of .../openwemi/work and this would mean that the property confers both classes on its subject:
BIBFRAME "carrier" could have the domain of ...openwemi/Manifestation:
BIBFRAME "illustrativeContent" is suggested to be used with either bf:Work or bf:Instance, but is generally considered to be FRBR Expression information.
|
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 ( (Aside: these classes, in particular 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":
The last example could include openWEMI in its selection of terms (as concrete It is certainly true that BIBFRAME is rather unconstrained. This is why we in KBV have additional axioms, among other things the 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. |
@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
|
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 -- Graeme |
Here's a diagram of openWEMI and BIBFRAME: 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:
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. |
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
<#7 (comment)>, 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
|
@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:
but others are:
or:
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! |
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. |
How would this work? Is it necessary?
The text was updated successfully, but these errors were encountered: