-
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
Use case(s) for WEMI classes #95
Comments
One answer to this can be found in FaBiO. WEMI is used there to organize the description of academic documents (and their associated files). Rather than directly assigning WEMI as classes, the general types of documents are subclassed to W (biography), more specific are subclassed to E (chapter), and physical formats are subclassed to M (analog, digital). This is obviously VERY different to FRBR, but it seems to work for them. I think there is more value in using classes to define vocabularies than using them in instance data. In particular, I think this makes for easier data creation. A cataloger has a book that has an author and there is no reason for the cataloger to worry about whether the author belongs to the W or E or M, and what class the translator is a member of. So although they can be used in type arcs, I really see their value in vocabulary creation. Once the data is created, the class membership can be useful in searching and subsequent display. I see classes as more related to semantics than node structure. And I agree that any one node may have properties that infer multiple classes for the node. |
I've been re-reading some library FRBR writings (mainly the essays in Patrick Le Boeuf's book) and what strikes me in those, and in the usage with legal documents, is that many communities struggle with managing duplicate and near duplicate "stuff". For them, WEMI becomes an organizing principle for managing these. WEMI is often viewed as a hierarchy with one work having multiple expressions and each of those having multiple manifestations, and multiple items per manifestation. This doesn't mean that WEMI cannot be used for unique items, but the problem of managing what would be overwhelming duplication seems inherent. The legal document example is especially interesting because it is a work flow with specific information attached to each step (first draft, draft after committee X consideration, modifications after chamber discussion, etc.). The Work in this case is an identifier attached to the document, the expressions are the stages of the various texts, the manifestations the texts themselves. Looking at the area of manufacturing, which is very process oriented, I can see how WEMI could be one small part in a much larger workflow that is less focused on the creation than it is in all of the processes that go into making it. If you think of something like automobile manufacturing, a manager could have very little interest in the design process, which takes place in another area of a very large organization. But for car aficionados and all of the online sites, magazines, and sales reps, the details of manufacturing are of little interest, but the creative elements are paramount. So we should probably have a sentence or two that acknowledges that WEMI may well be a segment of a larger vocabulary. |
How are WEMI classes intended to be used in data?
I do not personally believe in Ws, Es, Ms, etc, as reified things, even on a conceptual level. Rather, as I say in other threads, I see them as views on creations at different levels of abstraction. Accordingly, I cannot imagine why one would want or need to infer that a given resource were an instance of Expression (what would that really tell you?) or why OpenWEMI would want to support such inference, beyond simple inference based on the domains and ranges of the properties that relate WEMI things among themselves.
I have assumed that WEMI classes would serve primarily as objects of type arcs in a graphs of statements about things (ie, as "discriminator" triples). Discriminator triples can provide distinguishing features as hooks for matching data shapes (ie, application profiles) against subgraphs in a sea of interconnected graphs and triples.
In other words, I was picturing that Work, or to use an example from OpenWEMI, a MusicalWork, would serve, in a pragmatic sense, to provide a hook to match a subgraph about some musical creation with some data shape. Typing a resource as a MusicalWork would also in effect hint that a data consumer expect that resource to be described with properties typically used for describing musical works - properties that would be enumerated with more precision in a data shape. No more, but no less.
Properties such as "realizes" and "instantiates", accordingly, would simply serve to link two sets of statements (subgraphs), not to reveal anything essential about the nature of the resource described.
This is also why I see no reason why a given resource could not be described with combinations of, say, two WEMI type arcs. This would simply amount to two hints about the nature of statements to be found in a graph.
Are there any other big use cases for WEMI classes that I am missing? Or are my assumptions out of step with what the group is thinking?
The text was updated successfully, but these errors were encountered: