Print

Print


Perhaps I could have phrased this thought more clearly:
> The semantics behind MARC is based on reality
> 
How about this instead:

Reality can be inferred from MARC descriptions.


> On Jan 31, 2015, at 12:07 PM, Simon Spero <[log in to unmask]> wrote:
> 
> On Jan 30, 2015 10:25 PM, "Jeff Young" <[log in to unmask]> wrote:
> > The semantics behind MARC is based on reality. MARC cares (may) too much about which names and codes should be used in various structural positions, but there are real things lurking behind those.
> 
> [Very large asterisk, made up of all the superfluous asterisks bought by Pats haters before they discovered that astrophysicists may forget that the Earth has an atmosphere]
> 
> The things described by most (but not all) types of MARC records are abstract, not concrete. Most are closely  Youngian real world objects (which differ from ARK types).
> 
> 1. Marc record types which *do* describe tangible things, contrasted with records describing related but abstract things.
> 
> Consider an individual described by a MARC Community record.
> 
> A marc community record describing an individual human being named "Stanley Kirk Burrell" is a physical, tangible thing.
> 
> By contrast a MARC Authority record for "MC Hammer" describes a literary identity- a name bearer to which one or more works can be attributed.
> 
> A name is obviously an abstract, intangible thing; you can't touch "MC Hammer".
> 
> It is not quite as obvious that the literary identity is itself an abstract entity. One way of looking this is to consider an individual who creates works using multiple literary identities, using a different LI for different genres.
> 
> Before his death, could you touch the LI "Lewis Carroll" without simultaneously touching the LI "Charles Lutwidge Dodgson"? Can you show me where on the doll you did the touching?
> 
> Individual FRBR Items are tangible things. In some cases it may not be a good idea to touch them, so don't start taking apart your hard drive, but there is always a distinct  physical thing for each distinct item.
> 
> For those of you used to using Version Control Systems like subversion or git, you might think of items as a particular copy of a specific version, of a specific file, in a specific format, sitting in a specific folder on a hard drive.
> 
> 2. Most MARC bibliographic records describe an abstract thing.
> 
> Most bib records describe something roughly equivalent to a FRBR Manifestation. Despite some confusing wording, Manifestations aren't physical things; they are equivalence classes defining the common characteristics that are shared by all the items that are undamaged instances of the Manifestation.
> 
> A particular Item may differ in some respects from the description in the Manifestation, but these differences are signs that the item is abnormal in some way - a CD-ROM may be missing, or the item may be signed and numbered, but these differences are exceptional and noteworthy.
> 
> A MARC bibliographic record that has embedded holdings information can be thought of as a record describing two different things - a Manifestation, and an Item that is an instance of that Manifestation.
> 
> A Manifestation might be thought of as the set of all copies of a specific version, of a specific file, in a specific format, regardless of where the files are located.
> 
> One can take the Version Control System metaphor further. 
> 
> An Expression can be thought of as the set of all Manifestations of a specific version of a specific file, regardless of format, or as all the items that are instances of that version of that file.
> 
> Similarly, a Work might be thought of (loosely) as the set of all versions of the specified file, or the set of all copies of all versions.
> 
> 3. Descriptions of things are things; just not the thing being described. If you confuse the two, Leonard Cohen will laugh at you.
> 
> 4. It is important to have a strong grasp of the foundations of cataloging and of applied formal ontology before attempting to define an ontology of cataloging. It is also useful to consider the sorts of problem that the ontology is meant to be help solve.
> 
> 5. An efficient implementation of the wrong model is rarely part of the initial requirements documents. 
> It is a common part of a OIG / GAO / Lessons Identified reports.
> 
> Simon