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):

Class: Person

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

Class: Name

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


3 Responses to “About the model: Question 11”

  1. marthamyee Says:

    In trying to think through how to provide users access in multiple languages, scripts and transliteration methods, I formulated the following question: What is the best way to model variant names for entities (works, expressions, persons, corporate bodies, concepts, objects, genre/forms, disciplines, etc.) in different languages, scripts and/or transliteration schemes than those being used by the catalog such that users who prefer a different language, script and/or transliteration scheme can use these variant names as their preferred forms (with a computer automatically switching from the default preferred form to the new preferred form in every place where a name for an entity must display)? Should “variant title for a work in a different language” be treated as a property of work, for example? Or should “language of variant” be treated as a property of a property? And should “preferred form for speaker of language X” be treated as a property of a property of a property? This is getting quite complex! Can RDF handle this degree of complexity? (Or is there a simpler and more elegant way of handling this in RDF that I am missing?)

    I realize that this may be at least a partial explanation for the three class approach taken by FRAD (person/name/controlled access point) as described above. But that seems rather complex, too, and not intuitive.

  2. marthamyee Says:

    Actually, with the addition of key identifier (discussed in Question 12 below), FRAD has taken a four class approach!

  3. Bruce D'Arcus Says:

    If you look at SKOS, they have properties like prefLabel and alLabel. If you couple that with the ability to assign a language to a property, this is a really simple solution that goes a long way. I’d say another triple that indicates the original source language of the resource would add still more value, since you can then assume that, say, a dc:title property with a language value of “en” for a resource that is a translation of a resource with another language is, in fact, a translated title.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: