Closed aisaac closed 7 months ago
@aisaac Yes, writing definitions is hard! In openwemi the relationships between the classes are defined in the properties, such as:
openwemi:manifests
a rdf:Property ;
rdfs:label "manifests"@en ;
rdfs:comment "An Endeavor that manifests an Expression or a Work."@en ;
rdfs:isDefinedBy openwemi: ;
rdfs:subPropertyOf dct:relation ;
rdfs:domain openwemi:Manifestation ;
dct:description "A relationship asserted from a Manifestation to an Expression or a Work."@en ;
rdfs:range [
a owl:Class ;
owl:unionOf (
openwemi:Work
openwemi:Expression
)
] .
... but not in the definitions of the classes. Note that the this property has a range of either Expression
or a Work
. If we defined Manifestation
as "The physical embodiment of the Expression" then the property manifests
would seem contradictory. In our model, the presence of an instance of Manifestation
does not imply a real or virtual Expression
as it does in FRBR.
We have gone beyond the relationships in the original FRBR precisely because we consider it possible that not all communities will find a use for all of the classes. (BIBFRAME being a good example.) That is speculation on our part, I admit. I think this becomes rather philosophical and it comes down to what we mean by W, E, M, I, and to what extend we can define them and yet leave them as open as possible. Could the definitions be "too open", leading to uses that are incompatible?
If FRBR things are instances of classes, I'm not sure we can entirely escape calling them "entities". We might conceivably come up with a more satisfying word, but it would surely just be a synonym of instance or entity. Here, I use "something".
My unease with "entity" is metaphysical. I feel uneasy with the notion that we are dealing with things that supposedly are "essentially" Ws, Es, Ms, or Is, perhaps because "essentially" hints at "exclusively", which hints at the disjointness one finds in, say, the FRBR-LRM variant of WEMI, with its "distinct" creations and "distinct" combinations of signs, each associated with a distinct and disjoint set of properties -- a rigidity that OpenWEMI deliberately seeks to avoid.
In the Code4Lib paper, Karen suggests an alternative way to view the entities "as occupying general facets or planes". "Facets", "planes", perhaps "views" -- related to the "levels of abstraction" invoked in (most? all?) WEMI models since 1998 -- is closer to how I see the nature of those entities: as things that one might describe, clumsiness of wording aside, as being "describable on a conceptual (or physical) plane". To define an entity as something describable in terms of a "plane" or "view" feels potentially more inclusive than referring to them more directly as entities (eg, the subject is "a creation" or is "an exemplar).
In describing or referring to something, the terms one uses can be seen as falling somewhere on a continuum from the notional to the physical -- a continuum that can be sliced up into differently defined levels of abstraction as they are perceived and required by different communities. I am reminded of slide 18 in a presentation by Pat Riva where she asks "What is a 'book'?" The answers (with my particular spin):
I share Karen's concern (above) about definitions being possibly 'too open', leading to uses that are incompatible -- so here is a stab at some admittedly awkwardly worded definitions that try to characterize the entities in terms of their describability while trying to characterize a continuum of abstraction levels:
In saying that something is of rdf:type
W, E, M, or I, then, the intention would not be to say that it is something or to reify that something as an entity. Rather, the intention would be merely to say that is is something describable on a plane between the purely notional and the purely physical.
For the sake of rough consensus, then, OpenWEMI would provide URIs for four of those planes, even if we admit that those planes may be interpreted differently according to the worldviews and requirements of different communities. By making a type statement using one of the WEMI classes, one would in effect tag the subject of the statements made in a graph as something describable in terms of one of the four conventional levels of abstraction. Such a type statement would, I hope, serve less to characterize the essential nature of its subject, and even less to support any meaningful sort of formal inference, than to name an intended view on that subject.
@tombaker I fear that the "describable" approach brings up something truly ontological, which is whether the class refers to some reality about the thing being described or whether it refers to the metadata that describes it. I've never been entirely comfortable with the "real world object" of RDF, but I also do not want openwemi to be about the metadata rather than the nature of the created endeavor. I'm pretty sure you didn't intend it to be that way, but using "describable" may set people thinking more about the metadata than the endeavor. It's "describable as" vs. "is" and I think at the openwemi level we need to stick with "is" - downstream uses can of course narrow that.
We might still be able to tighten the definitions.
@kcoyle
but using "describable" may set people thinking more about the metadata than the endeavor.
I do not think that is necessarily a bad thing. When we talk (or write) "about" things, using language, we are in effect vocally emitting a sort of metadata. I do in fact think about WEMI things more in terms of the sorts of statements one might make about them. Part of me thinks that WEMI entities could just as well be defined not as classes, but as data shapes (or application profiles) - ie, as constructs that enumerate conventional or expected sets of statements that, in a given community, one could, should, or must make about things.
I recognize that the WG wants to define concepts that could be used with a wide range of statements depending on different communities' different understanding of musical scores, industrial products, artworks, and the like, so I appreciate the need not to tie the entities to specific sets of recommended properties. But if it doesn't quite work, conceptually, to reify FRBR entities as distinct (or disjoint) things, then the alternative way to view those entities could be in terms of how they might be described.
It occurs to me that I have been assuming that in a practical sense, the primary use of WEMI classes would be as "discriminator" triples - the type arcs that very often are used to characterize the subject of a data shape or application profile. To me, the value of the WEMI framework is less as a model of the world, somehow capturing the true essence of reality, than as a way to organize the description of reality according to levels of abstraction.
In other words, not something intended to be used for inference.
Tom, the working group discussed this and were united in their dislike of using "describable" in the definitions. I agree that WEMI organizes levels of abstraction, but do not know how that relates to inference. There could be inference based on the domains and ranges, and it occurs to me that we should discuss that. I will create an issue.
The working group is proposing these changes in definitions (note, openwemi:Work definition does not change):
Quoting myself
awkwardly worded definitions
To clarify... I had not intended to propose that WEMI things actually be defined using the word "describable", rather to emphasize what I still see as two significantly different ways to think of instances of FRBR classes: 1. As entities that are Ws, Es, Ms, or Is in some "essential" way. Or 2. As views of creative endeavors from standpoints that fall along the continuum from abstract to concrete. As I see it, the re-worded definitions proposed above actually do take a step towards the second option.
So, incorporating the new wordings above, I understand the full (revised) set of definitions to be:
(Minor point: why "perceivable form of the creation" and not "of a creation", for consistency with the other definitions?)
Formally speaking, an RDF class is the identifier one assigns to a putative "class extension" consisting of instances of that class. I'd like to propose a test, whereby one describes an instance of a given class by adding "An instance of":
In my opinion, Instance of Endeavor passes the test, but the others not so much. I readily concede that "describable" is awkward. However, I do think my proposed definitions fare slightly better in the test, for example:
Definitions along these lines lend themselves better to the notion that, without contradiction, an identified subject can be an instance of multiple classes, eg both of a Work and an Expression. Compare:
I will put this on the openwemi meeting agenda for this week:
Wednesday, March 20 UTC 16:00 https://us02web.zoom.us/j/85015662374?pwd=ZnEyOENHczh5dDg3UFJaaTZwN2ZFQT09
To all: Please feel free to join if your schedule permits.
In the Code4Lib paper, Karen suggests an alternative way to view the entities "as occupying general facets or planes"
I've wondered sometimes for Schema.org about having a way to annotate things (entities, items, dohickies etc.) with a property/value pair that addresses FRBR-ish distinctions. In a Schema.org setting we have CreativeWork covering all kinds of levels of abstraction, and it it unlikely we could refact that type hierarchy to fall under WEMI-style exclusive supertypes. Whereas if you could just add a "wemiCode: Work", or "webCode: Item" to something, say a Book or TVSeries or Painting or for that matter a Product, ... it could be taken as a hint as to whether you meant things at the more abstract or the more specific ends of the WEMI spectrum (or something in the middle). Typing seems somehow more grand and serious.
I'm not sure how or whether this generalizes to DC's interest in this area but thought I'd share the idea...
I am in favour of not interpreting WEMI as something absolute but in view of the intent in a metadata scenario -- so: in the moment of creating (or using) metadata for something, what is the aspect the description is focussing on in order to fit the use case? (I think that is what application profiles do?) I have been rereading this paper again: https://asistdl.onlinelibrary.wiley.com/doi/10.1002/meet.1450440248 which you probably all know and I also think I have gotten it here somewhere in the community.
@danbri @annakasprzik Yes, and unlike FRBR, an online bookstore can declare that its metadata represents an openwemi:Manifestation without including separate declarations for Work and Expression, whereas most Goodreads pages are at the Work level. I think this is in the spirit of the Open World Assumption, where you encode the data you have in the view that you need.
I agree that one of the (many) issues with FRBR WEMI is that WEM is abstract and not clearly delineated. FRBR used "attributes" to try to clarify the role of each entity. OpenWEMI doesn't solve that, but at least lets people make use of the concepts however they need.
Sorry for not reacting sooner. I just couldn't dive into the long replies that my issue triggered. Actually my own suggestion was more trivial, and probably badly worded. I was merely asking whether there is a need to re-define the entities/classes/whatever that are close enough in OpenWEMI and FRBR. I agree with @kcoyle , the properties in OpenWEMI are quite different in terms of semantics, they deserve clearly different definitions. But for the classes I'm less convinced. So what I'm going to do (if you don't mind) is to create a new issue, which will ask to come back to whatever the outcome of this discussion here is, and to test whether it's really worth the differences in definitions.
Don't know if this IFLA list entry is of any relevance?
Dear colleagues, As you may know, the ISBD Review Group commissioned the ISBD for Manifestation Task Force in 2019 with the remit to align the ISBD Consolidated edition (2021 update) with the Manifestation entity of the IFLA LRM bibliographic conceptual model. In the remit was also to develop an element set with accompanying stipulations. The ISBD for Manifestation Task Force has completed a first draft of the ISBD for Manifestation (ISBDM) in the form of an online tool, and the review phase which is currently underway will soon arrive at its last step, the Official World-wide Review, planned mid-May until mid-July 2024.
The ISBD Review Group, would like to invite you to a World-wide Review Introductory Webinar 25 April 2024 (preliminary time 3-5 pm CET). This will be a 2 hour webinar, with the first hour dedicated to presentations, and the second hour to questions and comments. If you wish, look at the draft ISBDM ahead of the webinar in order to prepare some questions: https://www.iflastandards.info/ISBDM/ Please save this date at the moment, and further information will follow. Kind regards, Mikael Wetterstrom; Chair, ISBD Review Group
After the March 20 meeting of the group, these are the proposed definitions:
Endeavor: "A creation"
Work: "An abstract notion of an artistic or intellectual endeavor."
Expression: "A perceivable form of an endeavor."
Manifestation: "The vehicle in which the endeavor is communicated."
Item: "An instantiation of an endeavor."
Comments/corrections welcome.
Is the assumption that each of the WEMIs is in the context of one particular endeavour?
On Wed, 20 Mar 2024 at 19:57, Karen Coyle @.***> wrote:
After the March 20 meeting of the group, these are the proposed definitions:
Endeavor: "A creation" Work: "An abstract notion of an artistic or intellectual endeavor." Expression: "A perceivable form of an endeavor." Manifestation: "The vehicle in which the endeavor is communicated." Item: "An instantiation of an endeavor."
Comments/corrections welcome.
— Reply to this email directly, view it on GitHub https://github.com/dcmi/openwemi/issues/87#issuecomment-2010510953, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABJSGIQW63QJ66WWNMAZELYZHS2FAVCNFSM6AAAAABEM7QME2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJQGUYTAOJVGM . You are receiving this because you were mentioned.Message ID: @.***>
Oh, thanks @danbri for throwing THAT wrench into our finely designed product! ;-)
There is no property that is a link between E and WEMI in operational terms - that is, that WEMI are all defined as subclassed to E, but we have not defined properties that would allow you to say: "this Manifestation manifests this Endeavor," just "this manifestation manifests this Expression OR this Work." There are cases (lots of them) in the library/archive world where a manifestation can manifest multiple expressions or multiple works. Given that lack of a WEMI-to-E property, what problems does this create for us?
A note on the discussion: For manifestation we also discussed "transported" instead of "communicated" (possibly with "vessel" instead of "vehicle"). However, parts of us were uncomfortable with the various connotations of those verbs / combinations. Afterwards I thought of another candidate for "communicated" / "transported": how about "conveyed"? That seems fairly neutral?
(And a note about abbreviations: it seems a bit dangerous to shorten "Endeavour" to "E" given that there is already an "E" in "WEMI" ... )
[Disclaimer: Metaphysical reservations, as expressed on yesterday's call, aside...]
Rather than "communicated", I prefer a verb related to "carrier", such as "carried" or "transported". Expressions have to do with communication too - do they not? - but more with the content than with the carrier.
@annakasprzik "Conveyed" is arguably problematic because one often "conveys" an idea.
However, "transported" does not work well with "vehicle" because "vehicle in which... transported" is just asking to be read literally. If it must be "vehicle", then "vehicle by which" is perhaps slightly better.
I share the preference for something away from "communicated".
As I was writing up a more wordy explanation of content/carrier that could be added to the primer, I also thought about "conveyed". But "conveyed" and "vehicle" are a bad match, as per our discussion about trucks. So:
We also talked about "carrier":
I know we didn't like using "physical" but what about:
During our discussion I also noticed but forget to comment on the fact that all other definitions (E,W,E,I) above do not contain a verb at all. I think it is maybe a good idea to do the same for manifestation, so "The physical or digital carrier of the Endeavor." sounds very good to me.
I think we need a verb that works for radio broadcasts and performances of plays/music. "carrier" doesn't work for me.
I quite like "form" for Expression and "format" for Manifestation.
"Romeo and Juliet" [w] in the form [e] of a play, in the format [m] of a book.
Would it be right to say of different manifestations of the same endeavour: <m1> dct:hasFormat <m2>
?
Would it be wrong to say of different expressions <e1> dct:hasFormat <e2>
? (in other words are expressions are "format-less"?)
Also, when you get to manifestation you are not at the point of concreteness of a physical or temporal thing; but are talking about what is available, what is published
So how about
Manifestation: "A format in which the endeavor is available."
@philbarker I like everything about this definition with the exception of "is". "Is" seems to mean "now" and it may be in the past. Unfortunately, I cannot think of a verb that means "was, is, or in the future". Would it be too awkward to say:
Manifestation: "A format in which the Endeavor was, is, or will be available."
Oh, how about "becomes" as in:
Manifestation: "A format in which the Endeavor becomes available."
Does "becomes" get over the tense problem? I guess it is more amenable reading as the historical-present or present-future tenses. Anyway, you are right about the problem with "is", and "becomes" is an improvement.
I can only think of rather ugly formulations like "comes into being". As Tom said on our call about other suggestions, that smacks of catechismal language. I'd like not to evoke airs of thee, thou, doest, or sound like we are replicating any religion's origin story. "Becomes" is dangerously close, but at least this definition doesn't imply that trucks are involved (cf. "vehicle" "conveyed").
I am in favour of not interpreting WEMI as something absolute but in view of the intent in a metadata scenario -- so: in the moment of creating (or using) metadata for something, what is the aspect the description is focussing on in order to fit the use case? (I think that is what application profiles do?) I have been rereading this paper again: https://asistdl.onlinelibrary.wiley.com/doi/10.1002/meet.1450440248 which you probably all know and I also think I have gotten it here somewhere in the community.
We discussed this in the working group, as issue #66. We closed the issue but tend to agree.
OK, now the group has settled on:
Endeavor: "A creation" Work: "An abstract notion of an Endeavor." Expression: "A perceivable form of an Endeavor." Manifestation: "A format in which the Endeavor becomes available." Item: "An instantiation of an Endeavor."
Are these ok? (Please give a thumbs up or down here. Thanks.)
I gave a thumbs up, but did have a question, not really having followed this:
Why the language of "format" for manifestation, instead of (at least what seems to me) the more general FRBR language?
PS - I think I'm on the UB (to represent BIBO), but not super sure.
@bdarcus Thanks. I agree that "format" is a pretty wishy-washy term, but we didn't want to use "physical". FRBR had:
"the physical embodiment of the expression of the work."
We're trying to leave OpenWEMI so open that it could be used to describe non-fixed "stuff" like a performance that isn't recorded. Both "physical" and "embodiment" seem to require a fixed form. That works for libraries because libraries deal only in fixed or recorded creations.
There's more discussion of the differences between the current Library Reference Model (successor to FRBR) in #96. That has this as the definition of Manifestation:
A set of all carriers that are assumed to share the same characteristics as to intellectual or artistic content and aspects of physical form. That set is defined by both the overall content and the production plan for its carrier or carriers
We did talk about using "set" in the definition, but again we want to allow for a "set of one" and we didn't think that would be clear if we used "set". We've also heard some negative response to "carrier" from non-library folks, who don't have that in their lexicon.
If you have other terms I'd love to hear them. It's really hard being concise and clear. We have a field in the vocabulary file for a longer description so once we get a change to the html display program those will also be visible. They are in the ttl (which has not yet been updated with these definitions). Perhaps if we looked at those we could see if the very terse definition and the longer description viewed together make for clarity.
@bdarcus Nice to see you, and thank you for chiming in! You are indeed a member of the Usage Board and most welcome to help us with this review.
If you have other terms I'd love to hear them. It's really hard being concise and clear.
@kcoyle - I do not, and recognize your second point. I don't see a problem proceeding with the current definition; was just curious.
I am sorry I didn't give a thumb up. But I'm still not bought...
In the last call (and at the very top of this issue) I said I am not confortable "perceivable form of an endeavour" for Expression because I think it would apply to fairly all other Ms and Is. Actually @kcoyle's example of performances (I assumed it is about music) makes me think that if a symphony is manifested in a score written in music notation, then a lot of things that are derived from it feels much more "perceivable" to me. And I think it applies to most non-music cases, especially considering the Item level. The point is that we'd have many instances of another class that are more perceivable than instances of a class that is defined based on perceivability...
As for "format", I share @bdarcus' reservation. It sounds quite technical, and actually to me it "format" hints even more to something "fixed" than a "physical" and "embodiment". And I am confused about the mention of the need to "describe non-fixed "stuff" like a performance that isn't recorded". I mean, this is a very valid goal, of course, but why is it relevant for Manifestation? I've quickly researched documents for FRBR in music (for example https://web.library.yale.edu/cataloging/music/frbr-wemi-music), and it seems that in those, a performance is to be represented as an Expression. So a non-recorded performance could be captured in FRBR, whatever semantics is adopted for Manifestation. To me, the main advantage of "format" over "physical embodiment", is it conveys better the fact that a manifestation can be in a digital form (as rightfully hinted in the "longer definition" that @kcoyle mentions above). But it's not a matter of fixed vs non-fixed.
And if the issue is fixed vs non-fixed, then my move would be to rather represent this bluntly in the definition than expressing it with a different "head term". Karen is right when she says it's really hard being concise and clear, and I don't think I could beat others here. So I would try instead to re-use the original FRBR wording, but 'expanding' it in a way that includes the generalization desired, for example something like "the physical embodiment (possibly non-fixed) of the expression of the work". It's not very elegant but it would have the advantage of pinpointing where the generalisation lies, in the semantics of the new class. And if the difference was about physical vs digital, then I would use something like "the physical (or digital) embodiment of the expression of the work"
@aisaac Thanks, Antoine. I don't know what to use in place of "perceivable" and "format". I, too, am not 100% happy with them, but so far I haven't seen anything better offered. Perhaps we should put our energy into longer descriptions and examples.
We do want to go beyond physical and digital. LRMoo defines Manifestation as something concrete and adds classes for "Activity" to cover performances. If openWEMI Manifestation becomes something fixed then we would need to add another class for non-fixed activities. We use "Event" as an example of a class that someone might want to add to their version of openWEMI, but I'm reluctant to begin adding classes to the base set. Also, remember that unlike the GLAM standards openWEMI wants to be useful to describe things like the manufacture of automobiles, space launches, archeology digs, derived datasets.
One view of an unrecorded performance could be that the conceptual essence of the performance could be an Expression and the details like time, place, date, could be the Manifestation. However, we are being as careful as possible not to pre-determine how people will use the classes in openWEMI, which is, again, why we are trying to be as open as possible.
We can't use the FRBR phrase "embodiment of the expression of the work" because we are saying that a manifestation can "manifest" either an expression or a work. That is because we are aiming at an open world model where not all elements are required to be present in the model or in the instance data. This is why each of the classes is defined in relation to Endeavor, not to the more abstract class "above" it. FRBR and LRM are linear, and in those models you cannot have a Manifestation without an Expression. I consider those models to be applied views of openWEMI that serve a specific community.
So our goal is to be as non-prescriptive as possible, but to give people a vocabulary they can subclass and sub-property to.
Can we use this framework to describe HP Laserjet printers? (seriously!)
@danbri Seriously, yes. The exact division of properties between the WEMI classes would depend on the needs of the application this serves, but possibilities are:
Work: the basic concepts relating to a printer design. The "creator" would be either HP or an actual designer (that latter is more likely for things like fashion)
Expression: the blueprints and materials decisions (there can be more than one expression, like if they do them in different colors à la iPhones)
Manifestation: the product line coming off the assembly line (one per expression, so a different manifestation for different colors, etc.) - has UPC code
Item: the printer in my house; items: the inventory at BestBuy
Some more of the design could be attributed to the Work level, or there could be a cascade of expressions from blueprint to materials. For manufacturing, an additional high level class following Expression and preceding Manifestation may be needed to cover details of the manufacture workflow. In the fashion industry metadata these details were not included, but this would be more important for heavier industries, e.g. automobiles.
You can see how there are a huge number of options that we can't anticipate, which is why it's best to leave it to those addressing the needs of an application. Would "iPhone" be one work or would each generation and model be its own work? Would HP have a single printer Work with models as expressions, or would the company want separate works with separate expressions for different models? If we've done this right, all of those options should fit into OpenWEMI, with whatever modifications are needed to accomplish the metadata goals.
@kcoyle thanks and I agree about not considering (sub)classes. Adding activities/event/whatever does make a representation more precise, but it doesn't change the main ontological choices to be made. And for the record I think I am fine with your use of expressions and/or manifestations for the (non-fixed) performance case.
About non-fixed vs fixed. I didn't want to hint that manifestation should be fixed. I was merely trying to understand whether it was the main criterion to define a manifestation, or if the "essence" of the class was elsewhere. And I am very fine if it is elsewhere! This was what was behind the "(possibly non-fixed)" of my proposal ("the physical embodiment (possibly non-fixed) of the expression of the work").
By the way, I am sorry, as I was focused on the 'non-fixed' or 'physical embodiment' aspects of the definition, I completely overlooked in my proposal the required flexibility on the object of the manifestation. This was just not what I wanted to discuss about. But indeed it should have been something like "the physical embodiment (possibly non-fixed) of a work or of an expression of a work"! Or if you would prefer using 'endeavour', it could have been "the physical embodiment (possibly non-fixed) of an endeavour". Basically I would be happy with many things being used as the tail of the definition, provided that the head doesn't use 'format' ;-)
But well, I suppose that in any case we'd probably be better off following your suggestion to put our energy into longer descriptions and examples. Afaic I think this is my last attempt at making a (arguably odd) sort of suggestion for the short definition of Manifestation!
And if I find a better word than 'perceivable' for the expression I'll share it, but I'm not optimistic about it :-(
Some middle of the night thoughts:
"A realization of an Endeavor in physical, digital, or experiential form"
"A realization of an Endeavor that is material, digital or experiential."
I like the first one. I am afraid to start thinking about it, though, because just now I started asking myself if digital is also physical since it does have some physical anchor in the world (0s and 1s or whatever), and if physical and/or digital forms are also something one can experience ...
@annakasprzik You are right that often "digital" is considered "physical" because the ones and zeroes are actually somewhere. But I think it's ok to say "physical, digital" to make it clear that digital can be a form of a manifestation. Anyone reading the definition will probably be reading it quickly and will not stop to contemplate it in depth.
@kcoyle I think "realization" reads better that "format", yes! And the first option sounds better to me, too.
For the record:
Endeavor: "A creation" Work: "An abstract notion of an Endeavor." Expression: "A perceivable form of an Endeavor." Manifestation: "A realization of an Endeavor in physical, digital, or experiential form" Item: "An instantiation of an Endeavor."
The changes have been made to the Primer and the RDF vocabulary as listed above.
Maybe this has been discussed already in the group... I reckon that FRBR definitions like "an expression of a work" hint that there should be a work and this can be a problem if there's no work described anywhere. But is it really mandatory to change them as as been done in the current OpenWEMI spec?
I mean, I myself could live happily with the fact that the original definition still applies, even if the entities mentioned have only a virtual existence. A note on the 'virtuality' of the entities mentioned could be added as a general disclaimer, possibly as a 'tail' to the original definition.
NB: I'm also raising this because minting definitions for such classes is quite tricky. For example Expression is “A perceivable form of the creation” and Manifestation is “The physical embodiment of a creation”. As a 'physical embodiment' can arguably be 'perceived', one could understand that every Manifestation can be seen as an Expression. If we could avoid this sort of painful discussion and just keep defering to the original FRBR proposal, it would be great...