Inverse Relationships for common* series

[HughP]

Greetings,

I am modeling with openWEMI using OAI-PMH which dictates an XML syntax. One of the things that became evident very quickly was that we have manifestations which are not from the same Expression, but are from the same work. Since our existing records are manifestation oriented, we would have to infer each Expression record which may or may not be a viable approach. We would like a way to say that two manifestations are NOT from the same Expression. With the current ontology we can't overtly declare that.

Manifestation A does not have a common Expression with Manifestation B.

A notCommonExpression B.

[kcoyle]

I can think of a couple of ways to do that, but there surely would be many more. Since a work can have many expressions, and if you have useful information for an expression, you can define two different expressions for manifestations A and B. As you say, this requires you to "infer" that they do not have a common Expression. If you have a specific need to say "A notCommonExpression B" then you can define a property with that meaning. It might be a subproperty of openwemi:relatedManifestation which has openwemi:Manifestation as both its domain and its range. Note, too, that you are not required to have an Expression for each Manifestation; you can link Manifestations directly to the Work. You can even link Manifestations directly to both the Expression and the Work if those are efficient paths for you.

Does this help? If I've misunderstood your use case you might need to provide an example of your XML or data diagram.

[HughP]

Yes. I see the direct connection between a manifestation and a work. This direct connection is different from the IFLA-LRM WEMI structure. I wonder how people will overcome modeling headaches in the future if they try to reconcile these two models with similar lables, but don't have the intermittent network nodes. I'll circle back and post a diagram and some XML within a few days.

[kcoyle]

The purpose of OpenWEMI is to provide some concepts that people can adapt to their own needs. If you must interact in a detailed way with IFLA LRM, then you are probably going to have to structure your data to match theirs. You can recreate IFLA LRM as a subclass/subproperty of OpenWEMI or simply use IFLA LRM directly. OpenWEMI is not aimed at the library community per se but for people who need. more flexibility than LRM provides. I can vaguely imagine a model that overlays LRM over a diverse set of relationships. It sounds hard to do but it might be interesting to mock something up. I'll ruminate on that.