Definition of Object-Oriented frbr

2.2. Naming Conventions

All the classes declared were given both a name and an identifier constructed according to the conventions used in the CIDOC CRM model. For classes, that identifier consists of the letter F followed by a number. Resulting properties were also given a name and an identifier, constructed according to the same conventions. That identifier consists of the letter R followed by a number, which in turn is followed by the letter “i” every time the property is mentioned in its “inverted” form, i.e., from target to domain. “F” and “R” are to be understood as the first two letters of “FRBR” and do not have any other meaning. They correspond respectively to letters “E” and “P” in the CIDOC CRM naming conventions, where “E” originally meant “entity” (although the CIDOC CRM “entities” are now consistently called “classes”), and “P” means “property”. Whenever CIDOC CRM classes are used in FRBR_OO, they are named by the name they have in the original CIDOC CRM. A number of properties are identified by the letters “CLP” and a number; “CLP” stands for “Class Property” and such properties are taken from Meta-CRM; all of them have F3 Manifestation Product Type as domain, and they indicate that all the exemplars of a given publication “are supposed to” or “should” display the features of the publication they belong to. The publication itself, being an abstract notion, cannot have physical qualities such as, for instance, a given number of pages, but meta-properties are a mechanism borrowed from CIDOC CRM and Meta-CRM that makes it possible to express that a publication is characterised by the number of pages that all of its exemplars, under “ideal” conditions, “should have.”

All classes and properties that were borrowed directly from the CIDOC CRM are named as in CIDOC CRM, i.e., with an identifier beginning with either “E” if it is a class, or “P” if it is a property, and with the original appellation for the class or property in CIDOC CRM.
The choice of the domain of properties, and hence the order of their names, are established in accordance with the following priority list:

• 
  Temporal Entity and its subclasses
  
• 
  Thing and its subclasses
  
• 
  Actor and its subclasses
  
• 
  Other
  

2.3. Property Quantifiers

Quantifiers for properties are provided for the purpose of semantic clarification only, and should not be treated as implementation recommendations. Therefore the term “cardinality constraints” is avoided here, as it typically pertains to implementations.
The following table lists all possible property quantifiers occurring in this document by their notation, together with an explanation in plain words. In order to provide optimal clarity, two widely accepted notations are used redundantly in this document, a verbal and a numeric one. The verbal notation uses phrases such as “one to many”, and the numeric one, expressions such as “(0,n:0,1)”. While the terms “one”, “many” and “necessary” are quite intuitive, the term “dependent” denotes a situation where a range instance cannot exist without an instance of the respective property. In other words, the property is “necessary” for its range.

many to many (0,n:0,n)	Unconstrained: An individual domain instance and range instance of this property can have zero, one or more instances of this property. In other words, this property is optional and repeatable for its domain and range.
one to many (0,n:0,1)	An individual domain instance of this property can have zero, one or more instances of this property, but an individual range instance cannot be referenced by more than one instance of this property. In other words, this property is optional for its domain and range, but repeatable for its domain only. In some contexts this situation is called a “fan-out”.
many to one (0,1:0,n)	An individual domain instance of this property can have zero or one instance of this property, but an individual range instance can be referenced by zero, one or more instances of this property. In other words, this property is optional for its domain and range, but repeatable for its range only. In some contexts this situation is called a “fan-in”.
many to many, necessary (1,n:0,n)	An individual domain instance of this property can have one or more instances of this property, but an individual range instance can have zero, one or more instances of this property. In other words, this property is necessary and repeatable for its domain, and optional and repeatable for its range.
one to many, necessary (1,n:0,1)	An individual domain instance of this property can have one or more instances of this property, but an individual range instance cannot be referenced by more than one instance of this property. In other words, this property is necessary and repeatable for its domain, and optional but not repeatable for its range. In some contexts this situation is called a “fan-out”.
many to one, necessary (1,1:0,n)	An individual domain instance of this property must have exactly one instance of this property, but an individual range instance can be referenced by zero, one or more instances of this property. In other words, this property is necessary and not repeatable for its domain, and optional and repeatable for its range. In some contexts this situation is called a “fan-in”.
one to many, dependent (0,n:1,1)	An individual domain instance of this property can have zero, one or more instances of this property, but an individual range instance must be referenced by exactly one instance of this property. In other words, this property is optional and repeatable for its domain, but necessary and not repeatable for its range. In some contexts this situation is called a “fan-out”.
one to many, necessary, dependent (1,n:1,1)	An individual domain instance of this property can have one or more instances of this property, but an individual range instance must be referenced by exactly one instance of this property. In other words, this property is necessary and repeatable for its domain, and necessary but not repeatable for its range. In some contexts this situation is called a “fan-out”.
many to one, necessary, dependent (1,1:1,n)	An individual domain instance of this property must have exactly one instance of this property, but an individual range instance can be referenced by one or more instances of this property. In other words, this property is necessary and not repeatable for its domain, and necessary and repeatable for its range. In some contexts this situation is called a “fan-in”.
many to many, necessary, dependent (1,n:1,n)	Both an individual domain instance of this property and an individual range instance can have one or more instances of this property. In other words, this property is necessary and repeatable for both its domain and its range.
one to one (1,1:1,1)	An individual domain instance and range instance of this property must have exactly one instance of this property. In other words, this property is necessary and not repeatable for its domain and for its range.
many to two (2,n:0,n)	An individual domain instance of this property must have at least two instances of this property, but an individual range instance can be referenced by zero, one or more instances of this property.

Some properties are defined as being necessary for their domain or as being dependent from their range, following the definitions in the table above. Note that if such a property is not specified for an instance of the respective domain or range, it means that the property exists, but the value on one side of the property is unknown. In the case of optional properties, the methodology proposed by the FRBR_OO does not distinguish between a value being unknown or the property not being applicable at all.