One of the higher level entities is “nomen” which was first seen in FRSAD. The term means “name” in Latin (there’s nothing friendlier to a modern audience than using Latin terms!). Nomen is s subclass of “Res” (Latin for “thing”). Here’s how they are defined:
“Res includes both material or physical things and conceptual objects. Everything considered relevant to the bibliographic universe, the universe of discourse in this case, is included. Res is a superclass of all the other entities that are explicitly defined, as well as of any other entities not specifically labeled.”
If you have experience with OWL you will recognize that Res is very similar to owl:Thing, which is defined: “Every individual in the OWL world is a member of the class owl:Thing. Thus each user-defined class is implicitly a subclass of owl:Thing.” owl:Thing also includes physical and conceptual objects; in fact, it includes everything that is not owl:Nothing.
Nomen, is an entity at the same logical level as Work, Expression, etc., and Person. All are subclasses of Res. Nomen is defined as “Whatever appellation is used to refer to any entity found in the bibliographic universe.” Then it goes on to say:
“Depending on the context of use, the same sequence of symbols can be assigned as a nomen of different entities in the real world even within the same language (polysemy and homonymy). Conversely, the same entity can be referred to by any number of nomens (synonymy). The association of nomens to entities is in general many-to-many.” (p. 20)
We recognize this as the ambiguity of natural language that humans navigate rather well in real life, but that causes us great problems when we need greater precision. Because machines do not have the intelligence to work within the complex information context that humans occupy, we resort to the creation of unambiguous identifiers to solve the precision problem.
However, FRBR-LRM considers identifiers to also be nomen, and this is in contradiction to to the concept of and use of identifiers in any community that I have encountered. By considering that identifiers, as nomens, can be many-to-many the LRM eliminates any notion of unique identification, making functioning with data to be essentially logically impossible. As examples of identifiers as nomen they use an ISBN and an ISNI. Here’s what ISNI.org says about the role of its identifiers:
“The mission of the ISNI International Authority (ISNI-IA) is to assign to the public name(s) of a researcher, inventor, writer, artist, performer, publisher, etc. a persistent unique identifying number in order to resolve the problem of name ambiguity in search and discovery…” (emphasis in original)
“Unique” – that’s the key. Identifiers are identifiers because they are unique. Mixing unique identifiers and non-unique names in a single entity ignores the vital importance of identifiers. Names can vary; you can have full names, short names, nicknames, terms in various languages – all of those are names and we accept that, while they communicate to human beings are do not carry the precision needed for data processing. Identifiers must identify, something that names do not do. Names and identifiers are not the same thing. Period.
Oh, and the irony is that they have assigned unique identifiers to the LRM entities. Why? “Every element in the model is numbered for unambiguous reference.” (p.11)
FRBR Open Comments 
Pingback: World-wide review of the FRBR-Library Reference Model, a consolidation of the FRBR, FRAD and FRSAD conceptual models | FRBR Open Comments
ISBNs are not unique for items. First names are unique if you look at siblings within a family. I fairly have to admit that I do not have a clear definition for “identifiers” but I can follow a line of argument where general character sequences (“strings”) /become/ identifiers in a given context. As far as I know the context is given by a) fixing the domain (e.g. manifestations) and b) the “kind” or class of identifier has to be stated (IMHO stating “195531823 is an identifier for K.C” or “http://viaf.org/viaf/195531823 is an identifier for K.C.” does not make sense, one /must/ say “195531823 is the/a VIAF identifier for K.C.” or “http://viaf.org/viaf/195531823 is an URI for K.C.”
The question remains, in which way are nomens different from ordinary strings, k nwon as as “labels”. The scope note for LRM-E9 states that musical notations and the graphical notations for chemical compunds are also considered nomens, (and e.g. “stringifying” these by some convention in turn yields a different nomen). But for something to be turned into a nomen a necessary condition is “… assigned to be an appellation for something in some context”.
I think for recording this “context” (and specifically the assigning agency for “formally assigned” nomens like authorized headings) the “labels” have to be blown up into entities. Again I see parallels here to the labours we encountered in the Bibframe context when trying to model “identifiers”.
LikeLike
Thomas, perhaps I should have added a good definition of identifier, since there seems to be some confusion, but I didn’t find one I liked. Yes, as defined in most definitions I would consider well-thought out, identifiers are unique within a context. An IRI (URL) is unique within the context of the Internet, while ISBNs (which are not identifiers for items but for products) are unique within the publishing sales context. My California driver’s license number is unique within that system, and my social security number unique within that one, but neither can guarantee to be unique if separated from its context. In addition, I believe it was John Kunze whose definition of identifiers was something like “the relationship between a string and a thing based on someone’s commitment to that relationship.” This latter is very important to our concept of “authority” and to the linked data concept of “provenance” — that is, who is making this statement that X identifies Y. We have significant faith in VIAF identifiers because we believe that OCLC is a stable organization that meets its commitments regarding identification and that will be around for a while longer. Whether or not an IRI alone suffices also depends on the context, and there is some argument on whether one should rely on domain names (e.g. viaf.org) or whether provenance information is always needed. I don’t think that discussion is terribly relevant to the issues here.
LikeLike
Karen, I think this is highly relevant. I’m addressing you as “Karen”, since I have significant faith that your yesterday’s name also is your name today and it is sufficiently uniique within the context of this blog post and its comments. What I perceive is the nomen entity of FRBR-LRM is intended to be a generalization of the identifier concept otherwere.
LikeLike
Identifier as a nomen.
Actually, this is correct. The Entity Relationship model accommodates it. A mandatory n:n relationship between Res and Nomen means two things: 1) ‘a Res must have one or more Nomens’ (meaning: at least one Nomen), 2) ‘a Nomen must refer to one or more Res’ (meaning: at least to one Res). The second statement does not mean that any Nomen must refer to multiple Res. Some Nomens do, some Nomens only refer to one Res. ‘Many-to-many’ is not prescriptive. ‘John Smith’ can refer to multiple people, but a unique name like ‘Qwrastyujk Ghloiytrces’ will refer to only one person. Similarly, unique identifiers, as Nomens, will each refer to only one Res.
Of course the implementation will be more complex, because you need specific database and or software constraints to prevent external unique identifiers to refer to multiple things. So it would probably be better to distinguish between ordinary names and identifiers in the conceptual model in some way.
LikeLike
“So it would probably be better to distinguish between ordinary names and identifiers in the conceptual model in some way.” Yes, definitely.
LikeLike
We should always keep in mind that byr LRM-R13 the relation between res and nomen is 1:n. So /no/ nomen can refer to multiple res.
The first sentence of the scope note reads a bit apologetic, as if only the restrictiveness of the “particular library system” would prevent implementation of the “general … many-to-many [relationship]”. I think this is inconsistent: Libraries have to deal with appellations like “Age of Enlightenment” (as designation of a time-span or of probably many books or book chapters) or “2015-03” or “Music” or “780” (a number or a notation in DDC and probably about any classification system) or “1936 Phalguna 10” (I first took that for a postal address) or “123456789X” (an and any of the defined attributes category, scheme, audience, context, reference source actually depends on the relation of the nomen to a specific res.
If “in theory” a nomen would allow n:m relationships to res, it also would amass many conflicting values for these attributes, Meaning ‘”780″ is_a number /and/ (inclusively) a notation and is used for counting and for shelving and …” These cannot even be clustered (e.g. associating a reference source with a context) to turn it into an encyclopedic article about “780”.
My conclusion is, for the “nomen” entity defined as in FRBR-LRM the 1:n relationship with res is essential and not just a mere technicality. “Essential” perhaps only in the sense that the ER-approach in itself is the limiting factor here, but that’s quite “essential” too. A “u-nomen” entitiy allowing n:m relationships would either have to qualify the individual /relations/ (so the attributes are relation-specific, not entity-specific) or develop some internal compatimentalization to tie corresponding values of the attributes. But then the relations to res could/shout be confined to a single of these compartments and at this stage the LRM “nomen” entities with their 1:n relation would have been reinvented.
LikeLike
Thomas, you are right, it’s a 1:n relationship. My fault. I reacted to Karen’s comment without reading the original description correctly.
LikeLike
In natural language we say “the DDC number of this is 780” or more tersely “084 $a 780 $2 ddc” (ignoring for the moment that just for DDC there is a dedicated MARC field 082) which I perceive that in fact we are qualifying or contextualizing) the relation by “DDC” (a nomen by itself, outside the library community this acronym surely has other meanings). So it *is* natural for us to restrict the scope of a relation (“780” as an appelation of the /general/ number 780 or string “780”) to a certain domain of application (“DDC” as an appelation for that). But actually we want to establish a relation with a certain DDC class which is very different from the entity 780-as-a-number by means of apellations (any communication has to rely on “symbols”) and I’m not sure how the “natural” approach deals with it: Perhaps the number 780 is a metaphor which we are able to resolve to a concept after having fixed the context?
With the ER model and specifically with RDF applications in mind we unfortunately are not allowed to take this “natural” approach of qualifying a relation by attributes: Either there exists an explicitly defined sub-property or we have to collect the necessary qualifiers in form of additional statements at one or the other end of the originally “simple” edge. We could read
(084 $2 ddc) $a 780 meaning ‘”780″ is the value of the “ddc” subproperty of 084’ or (084 $a 780) $2 ddc meaning ‘”780″ is the classification number and “ddc” the context for that’ or 084 ($a 780 $2 ddc) meaning ‘this is classified as DDC-780″‘.and these three solutions would transform into an (anonymous) subgraph within the description of the “this” object and one asks oneself whether this subgraph has an identity of its own (yes: as a nomen entity for the DDC class we are interested in!). One could evade this by consequently creating just a link to a suitable resource representing the DDC class (with “label” 780, and revealing enough about itself that we can infer that we indeed have hit a DDC class), but there may be cases (like recording who assigned the notation and for what purpose) where a direct reference to the DDC class entity might not be sufficient and a “nomen” entity has to be “coupled in”.
LikeLike
Thomas, couldn’t this be solved by the use of identifiers? “780” itself is meaningless without “DDC”, but there is (was, it was taken down, but presumably will return) an RDF vocabulary for DDC with URIs such that “780” becomes http://dewey.org/%5Bvolume%5D/%5Blanguage%5D/780. (Or something like that). Since this would resolve to a description of DDC 780, plus labels and other information, nothing else should be needed. So
X hasClassNo http://dewey.org/%5Bvolume%5D/%5Blanguage%5D/780
or
X hasClassNo http://id.loc.gov/authorities/classification/NK1
and only one property, hasClassNo, is needed.
LikeLike
Sure, equivalently to 084 with $a and $2 we could use 084 $0(uri)… Then it would be the target resource’s responsibility to describe the context in a way the source “record” can understand, since “syntactic inspection” of URLs is not permitted (or is only permitted if you take it as a nomen built up from smaller nomen..) and there simply must be a place somewhere connecting the concept linked to with the “scheme” (DDC) and other important information (we’d have to expect that all target schemes equip /their/ RDF descriptions with such metadata according to one or only a handful of schemes /we/ can understand). We also have the usual sublte distinction between the uri as nomen for the RW resource and the same uri as nomen for the information resource providing us with statements about the RW resource and thirdly as a nomen for the address of that information resource)
I think this driven to the extreme might be as unwieldly as introducing a datatype of its own for every scheme (think of it: in an e.g. ISBN datatype all the dashed/blanked/undashed forms and the ISBN-10/ISBN-13 conversions would be “built in” *and* it’s always clear that we are dealing with an ISBN)
Honestly, we won’t get rid of “780” bearing significance in many different contexts and even when we design systems (and we should do that) heavily relying on simple (unqualified) relations (to target descriptions necessarily rich on meta data) we always have a) to take into account the interaction between humans and these systems and b) our expressed need ($2 and $5 are real!) to state and control “context”. The implementation may work along the lines specific URIs, annotation resrouces, and/or dedicated identifier classes, but I don’t think we can totally get rid of a concept in the abstract model representing the symbols we use to communicate about the res.
LikeLike