About the model: Question 11
11. I notice that the Functional Requirements for Authority Data (http://www.ifla.org/VII/d4/FRANAR-ConceptualModel-2ndReview.pdf) (brought to us by the FRBR folks) has defined the following classes and properties (entities and attributes, in their terminology):
Properties: dates associated with the person, title of person, other designation, gender, place of birth, place of death, country, place of residence, affiliation, address, language of person, field of activity, profession/occupation, biography/history
Properties: type of name (personal, corporate, family, etc.), scope of usage (e.g. fictional genres by that person that use a particular pseudonym), dates of usage, language of name, script of name, transliteration scheme of name
Class: Controlled Access Point
Properties: type of controlled access point (personal, corporate, family, etc.), status (level of establishment, e.g., provisional), designated usage (preferred or non-preferred), whether undifferentiated, language of base access point, language of cataloging, script of base access point, script of cataloging, transliteration scheme of base access point, transliteration scheme of cataloging, source of controlled access point (publication cataloged), base access point (e.g. surname and forename), addition (e.g. birth and death date)
Is that the most elegant way to model the cataloging practice of choosing a preferred form of name for every person, with cross references from all variant names?
“It depends. It works, of course, but it does indeed sound dodgy tohave a class instance Name in a relationship with a class instancePerson, however that might just be a persona preference rather than aflaw per se. In Topic Maps a name is always attached to a Topic; there is noseparation of the entities, as this is in many ways closer to humanthinking. There might be a Topic “the name Fred”, but again, that is aTopic in its own right, and not a separate class instance of thatname. As to general modeling I agree that names shouldn’t be classes justfor the odd chance the name is complex enough to warrant its owninstance, but looking at the definition it’s pretty clear that “name”isn’t a name at all but rather a complex node used for identificationof things. Now that’s all fine and well, but doesn’t sit too well withthe label “name” nor the concept of the Controlled Access Point whichtry to do pretty much the same thing. I’d agree that there’s somethingambiguous about this setup. In fact, why not make names part of theControlled Access Point? The interesting thing here is indeed thenotion of “access”, and one way to access any piece of information isthrough its label name. I’m sure there’s something funky that could
be done here”–October 8, 2007 email from Alexander Johannesen
Is it possible that FRAD chose this model because of the fact that current Anglo-American cataloging practice considers Mark Twain and Samuel Clemens (for example) to be two different authors, and considers a corporate body that has changed its name to be two different corporate bodies?
“Possibly, but it feels counter to the way we humans look at it. Youcould do (in Topic Maps terms) ; Topic 123 name “Samuel Clemens [Mark Twain]” name [pseudonym] “Mark Twain” name [original] “Samuel Clemens” This does what they want. Of course, if they *truly* want the modelingflexibility ; Topic 123 name “Samuel Clemens” Topic 234 name “Mark Twain” Association type “pseudonym” – person 123 – pseudonym 234 The difference between this and the proposed RDF is of course that“Mark Twain” is a *topic* or *subject* in its own right, and *not*just a name. Names should never be class instances in themselves, so I
think I agree with you”–October 8, 2007 email from Alexander Johannesen
What would be the trade-off in treating name as a property of person, with subproperties of preferred form of name, variant form of name, etc.?
“I think the trade-off is the lack of a node to link information too.This is probably why they’ve done it, so that they could treat “MarkTwain” as a node itself. Of course, the notion of “name” is vague (forexample, his writing style when Mark Twain was very different from theSamuel Clemens writing and they might as well be treated as twodifferent people with some pseudonymic relationship between them. I guess we’re coming into implementation land now, but there’s alsothe notion of how software is to use the proposed models. Systemsprobably deal easier with properties, and indeed going back to framestheory, everything is key-value properties in complex formations. Thelabel property of a topic is just a property with certain semanticmeaning. Another possibility for using Name classes could be that it’s easierto work with OWL in inference engines, although I can’t verify this at
this time”–October 8, 2007 email from Alexander Johannesen
DECISION: I have created just the single class Person; preferred form of name is treated as a property as is variant form of name. Bibliographic identities (Mark Twain and Samuel Clemens as two different authors) are not recognized in my rules or my RDF model; for one thing, this will support more standardization internationally and across the Internet.
What would be the most elegant way to allow the preferred form of name to vary based on the preferred language, script and transliteration scheme of a particular user? How would you model this situation (feel free to use topic map form, if you prefer)?
“Well, names and variant names(http://www.isotopicmaps.org/sam/sam-model/#sect-topic-name) arealready part of the Topic Maps standard, so we don’t have to create amodel for it (did I mention how well Topic Maps is suited to thelibrary world? :). Of course, we’re here talking about a properseparation of a person in terms of pseudonyms, so I’ll throw a fewfalse ones into the mix. I’ve also introduced type here like this ;[type], where type is an instance of some other Topic (meaning, if yousee [person] there is a Topic somewhere defined with this identifier)like this ; Topic person name “A person” Topic alternate name “Alternate spelling of a name” Topic nick name “A nick name” Topic 123 [person] name “Samuel Clemens” name [alternate] “Sam Clemens” name [nick] “Sam Clam” Topic 234 [person] name “Mark Twain” name [alternate] “Mr Twain” Association [pseudonym] – [person] 123 – [pseudonym] 234 In Topic Maps a few types of names are defined, such as sort name,display name, and we can use scoping too to further model what thesenames are (such as language, source, bias, etc.) I’d suggest a quickglance at http://www.infoloom.com/tmsample/pep4.htm (search for “topic
names”)”–October 8, 2007 email from Alexander Johannesen