FRSAD Functional Requirements for Subject Authority Data model

  • 2,100 views
Uploaded on

Presentation on the modeling approach of the FRSAD (Functional Requirements for Subject Authority Data) model; the entities, attributes, and relationships defined. Discussions of the implications of …

Presentation on the modeling approach of the FRSAD (Functional Requirements for Subject Authority Data) model; the entities, attributes, and relationships defined. Discussions of the implications of the FRSAD model for interoperability and future R&D considered. Presented for the ALCTS CCS Subject Analysis Committee, ALA 2010 Annual Conference, Washington, D.C. June 28, 2010

More in: Technology , Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,100
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
4

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • a subject authority system ensures consistency in subject representation may also record established semantic relationships among subject concepts and/or their labels. Data in a subject authority system are connected through semantic relationships, which may be expressed in subject authority records or generated according to specific needs in printed or online displays of thesauri, subject headings lists, classification schemes, and other subject authority systems. Such systems have been referred to as "controlled vocabularies", "structured vocabularies," "concept schemes," "encoding schemes", and "knowledge organization systems" interchangeably depending on their function and structure, as well as according to the communities that use them. Given the purpose of this report, the discussions about subject authority data apply to all systems and structures referred to by these terms. The study follows FRBR's approach in that it makes no priori assumption about the physical structure or storage of authority data.
  • Over 800 answered questionnaires. Find one or more subjects and/or their appellations, that correspond(s) to the user’s stated criteria, using attributes and relationships;   Identify a subject and/or its appellation based on its attributes or relationships (i.e., to distinguish between two or more subjects or appellations with similar characteristics and to confirm that the appropriate subject or appellation has been found);   Select a subject and/or its appellation appropriate to the user’s needs (i.e., to choose or reject based on the user's requirements and needs);   Explore relationships between subjects and/or their appellations (e.g., to explore relationships in order to understand the structure of a subject domain and its terminology).
  • *Attributes marked with an asterisk represent additions to those identified in Functional Requirements for Bibliographic Records.
  • http://dbpedia.org/page/John_Forbes_Nash
  • • Group 1 entities are defined as the products of intellectual or artistic endeavors: work, expression, manifestation, and item • Group 2 entities are actors, those who are responsible for the intellectual or artistic content, the physical production and dissemination, or the custodianship, of Group 1 entities: person, corporate body • Group 3 entities are the subjects of works, intellectual or artistic endeavor Within the FRBR framework, thema includes existing Group 1 and Group 2 entities and, in addition, all others that serve as the subjects of w orks (i.e., Group 3)
  • This model also proposes a new relationship: THEMA has appellation NOMEN / NOMEN is appellation of THEMA NOMEN = any sign or sequence of signs (alphanumeric characters, symbols, sound, etc.) that a thema is known by, referred to or addressed as .
  • http://www.cas.org/ASSETS/93FD034A0502489FA2474DFC0EE03284/usan.pdf
  • Gorden Dunsire email: The distinction between Thema and Nomen is crucial, and it is essential to retain the entity Thema; it is not too high a level of abstraction, it is abstraction itself. The RDF model is careful to make the same distinction: a URI is a machine-processable identifier for the abstraction of a class, instance of a class, or property, and everything else refines the abstraction. In SKOS, the URI of a concept is equivalent to defining a Thema, while the label of a concept is equivalent to a Nomen.
  • This is why nomen (in general) has to be an entity, not an attribute of thema. In a particular implementation the relationship between a thema and nomen can be compressed into the nomen becoming an attribute of thema Equivalence of nomen is a very important notion in subject access. Two nomens are equivalent if they are appellations of the same thema . The equivalence relationships in a monolingual controlled vocabulary can be found in five general situations: , the nomen s are synonyms the nomen s are near or quasi-synonyms the nomen s have lexical variants a nomen is regarded as unnecessarily specific and it is represented by another nomen with broader scope a nomen is regarded as unnecessarily specific and it is represented by a combination of two or more terms (known as “compound equivalence”). ISO. (2009). ISO/CD 25964-1. op. cit. NISO. (2005). Z39.19-2005. op.cit.  
  • In conclusion, the FRSAD model is developed with the goal to assist in an assessment of the potential for international sharing and use of subject authority data both within the library sector and beyond. The FRSAD model and other models developed along with the progress of the Semantic Web during the recent years enable the consideration of the functions of subject authority data and concept schemes at a higher level that is independent of any implementation, system, or specific context, and will allow us to focus on the semantics, structures, and interoperability of subject authority data. Putting the subject authority data in the context of the Semantic Web developments, especially in the perspective of Linked Data, subject authority data that are modeled based on FRSAD and encoded in SKOS and OWL will be able to become part of the Linked Data and contribute to the development of the Semantic Web.

Transcript

  • 1. FRSAD Functional Requirements for Subject Authority Data Marcia Zeng Based on the work of the IFLA FRSAR WG SAC Meeting, ALA, 2010-06-28
  • 2.
    • Today’s talk
    • Background
    • Current state
    • User tasks and the modeling approaches
    • The model --entities, attributes, relationships
    • Relationships with FRBR and FRAD
    • Implications for interoperability
  • 3. Report available at:
    • FRSAR: Functional Requirements for Subject Authority Data (FRSAD)
      • http://nkos.slis.kent.edu/FRSAR/
    • Working Group: Leda Bultrini, Lois Mai Chan, Jonathan Furner, Edward O’Neill, Gerhard Riesthuis, Athena Salaba, Diane Vizine-Goetz, Ekaterina Zaytseva, Marcia Lei Zeng, and Maja Zumer.
    • Advisory Group: Victoria Francu, Hemalata Iyer, Dorothy McGarry, David Miller, Päivi Pekkarinen, and Barbara Tillett.
  • 4. “ subject authority data”
    • Subject authority systems
    • Given the purpose of this report, the discussions about subject authority data apply to all systems and structures referred to by these terms.
    • The study follows FRBR's approach in that it makes no priori assumption about the physical structure or storage of authority data.
    • are referred to as
    • "controlled vocabularies”
    • "structured vocabularies"
    • "concept schemes”
    • "encoding schemes”
    • "knowledge organization systems”
    • … …
    1. Background
  • 5. frad. Extension of FRBR Figure 3.3 "Group 3 entities and 'subject' relationships"
  • 6. FRSAR Working Group FRSAR = Functional Requirements for Subject Authority Records
    • Terms of Reference
      • to build a conceptual model of Group 3 entities within the FRBR framework as they relate to the aboutness of works,
      • to provide a clearly defined, structured frame of reference for relating the data that are recorded in subject authority records to the needs of the users of those records, and
      • to assist in an assessment of the potential for international sharing and use of subject authority data both within the library sector and beyond.
  • 7. The “FRBR family”
    • FRBR : the original framework
      • All entities, focusing on Group 1 entities
    • FRAD : Functional Requirements for Authority Data
      • Focusing on Group 2 entities
      • Published in June 2009
    • FRSAD: Functional Requirements for Subject Authority Data
      • Focusing on Group3 entities
      • FRSAR WG established in 2005
      • Draft Report on World wide review 2009 June-July
      • Final Report submitted 2010 May
    2. Current state
  • 8. End-Users & Subject Authority Data Creators Subject Authority Data Intermediaries Metadata Creators 3. User tasks and the modeling approaches
  • 9. Metadata Creators Title: A beautiful mind : a biography of John Forbes Nash, Jr., winner of the Nobel Prize in economics, 1994 / Author: Sylvia Nasar Publisher: New York, NY : Simon & Schuster, ©1998. Subjects: Nash, John F., -- 1928- Mathematicians -- United States -- Biography. Schizophrenics -- United States -- Biography. Call Number: 510.92 Nas-N Different ways of modeling – [1] -- FRAD, p.44 * represent additions to those identified in FRBR work Author = … Publisher = … Subject = …
  • 10. [email_address] [email_address] entry-terms [email_address] [email_address] alternative-notations appellations notes Subject Authority Data Creators Different ways of modeling – [2] Nash, John F., -- 1928- Nash, John F. 1928- (Mathematicians--United States) John Forbes Nash, Jr. Mathematicians United States American Mathematicians 20 th Century Mathematicians Schizophrenics People With Schizophrenia Mentally ill 510.92 QA29.N25 Nobel Laureates In Economics Game Theorists Board Game Designers … … [any]thing Concept URI [email_address] [email_address] entry-terms [email_address] [email_address] alternative-notations labels notes Concept URI [email_address] [email_address] entry-terms [email_address] [email_address] alternative-notations labels notes Concept URI [email_address] [email_address] entry-terms [email_address] [email_address] alternative-notations labels notes work has as subject has as subject [any] thing
  • 11. work has as subject Different ways of modeling [any] thing work Author = … Publisher = … Subject = …
  • 12. FRSAD’s entities within the FRBR framework Within the FRBR framework, thema includes existing Group 1 and Group 2 entities and, in addition, all others that serve as the subjects of w orks (i.e., Group 3) frad. 4. The model --entities, attributes, relationships
  • 13. FRSAD Conceptual Model WORK has as subject THEMA / THEMA is subject of WORK . Thema = “any entity used as a subject of a work ".
  • 14. Different ways of modeling (cont.) has appellation SN = … alternative label = … term @ fr = … caption @ zh = … time of validity = … Term /code of [any] thing [any] thing any sign or sequence of signs
  • 15. FRSAD Conceptual Model (cont.) THEMA has appellation NOMEN / NOMEN is appellation of THEMA .
    • a new relationship
    • NOMEN = any sign or sequence of signs (alphanumeric characters, symbols, sound, etc.) that a thema is known by, referred to or addressed as .
    • In a given controlled vocabulary and within a domain, a nomen should be an appellation of only one thema ,
  • 16.
      • NOMEN = any sign or sequence of signs (alphanumeric characters, symbols,
      • sound, etc.) that a thema is known by, referred to or addressed as .
    Source: STN Database Summary Sheet: USAN (The USP Dictionary of U.S. Adopted Names and International Drug Names) Example: one thema, many nomens different types of nomens
  • 17. The importance of the THEMA-NOMEN model to the subject authority data
    • Separating what are usually called concepts (or topics , subjects, classes [of concepts] ) from what they are known by, referred to, or addressed as
    • A general abstract model, not limited to any particular domain or implementation
    • Potential for interoperability within the library field and beyond
  • 18. thema –thema relations place as thema nomens nomen –nomen relations Entities have their own attributes and relationships thema types (place-specific)
  • 19. http://aims.fao.org/en/pages/382/sub Interoperability efforts may focus on different entities. e.g., making a multilingual thesaurus focusing on nomens vs. mapping/integrating vocabularies based on themas
  • 20. Knowledge Organization Systems use different kinds of elements to represent themas Page
    • thesauri:
    • classification schemes:
    • subject heading systems:
    • taxonomies:
    • ontologies:
    • picklists:
    • … …
    terms ( preferred & non-preferred) notations terms of pre-coordinated strings category labels (w or w/t notations) terms or identifiers terms … … themas represented by:
  • 21. Attributes
    • Some general attributes of thema and nomen are proposed
      • thema : type of thema, scope note
      • nomen : various attributes
    • In an implementation additional attributes may be recorded
    4. The model --entities, attributes, relationships
  • 22. thema types
    • In an implementation themas can be organized based on category, kind, or type.
    • This report does not suggest specific types, because they may differ depending on the implementation.
    • There seems to be no universal categorization of themas.
    • e.g., models: e.g., implementations:
      • Original FRBR entities -- AAT’s seven facets
      • Original FRBR entities + time -- FAST’s seven subject facets
      • Ranganathan’s PMEST -- UMLS’ physical & conceptual
      • entities + events
          • Any attempt to declare one universal categorisation of themas would necessarily limit the usability of a general model.
  • 23. Nomen attributes and relationships with other entities (include but not limited to)
      • Type of nomen (identifier, controlled name, …)*
      • Scheme (LCSH, DDC, UDC, ULAN, ISO 8601…)
      • Reference Source of nomen (Encyclopedia Britannica…)
      • Representation of nomen (alphanumeric, sound, visual,...)
      • Language of nomen (English, Japanese, Slovenian,…)
      • Script of nomen (Cyrillic, Thai, Chinese-simplified,…)
      • Script conversion (Pinyin, ISO 3601, Romanisation of Japanese…)
      • Form of nomen (full name, abbreviation, formula…)
      • Time of validity of nomen (until xxxx, after xxxx, from… to …)
      • Audience (English-speaking users, scientists, children …)
      • Status of nomen (provisional, accepted, official,...)
      • *note: examples of attribute values in parenthesis
    Page
  • 24. Source: Getty Thesaurus of Geographic Names Online. http://www.getty.edu/research/conducting_research/vocabularies/tgn/ Record reprinted with permission. nomen type=“ID” scheme=“TGN” thema –thema relations nomen language=“French” … nomen audience=“English-P” … nomen status=“historical” time of validity=“1924-1991” .. nomen status=“historical” script=“other” … nomen status=“historical” script=“vernacular” time of validity=“1914-1923” … nomen source =“ .. “ nomen type=“controlled name” script=“vernacular” status=“both current and historical” time of validity=“18 th century-1914, reinstated in 1991” nomen form=“abbreviation” … thema types (place-specific) place as thema nomens
  • 25. Thema- to -thema relationships
  • 26. Nomen- to -nomen relationships
    • Partitive
      • A nomen may have components (parts).
    • Equivalence
      • a) the nomens are synonyms
      • b) the nomens are near or quasi-synonyms
      • c) the nomens have lexical variants
      • d) a nomen is regarded as unnecessarily specific and it is represented by another nomen with broader scope
      • a nomen is regarded as unnecessarily specific and it is represented by a combination of two or more terms (known as “compound equivalence”).
    • The equivalence relationships of nomens can be specified further, e.g.,
      • Replaces/Is replaced by
        • [e.g., “integrated plant control” is replaced by “centralized control”]
      • Has variant form/Is variant form
      • Has acronym/is acronym for
        • [e.g., “VS” is acronym for “virtual storage”]
      • Has abbreviation/Is abbreviation of
      • Has transliterated form/Is transliteration of
    - based on ISO/CD 25964-1 and NISO Z39.19-2005 .
  • 27. Relationship of FRSAD with FRBR
    • The FRSAR Working Group follows FRBR in the methodology, specification, and presentation of entities and relationships.
    • The “has as subject” (many-to-many) relationship is kept in its entirety in FRSAD.
    • The WG also starts with a user tasks analysis and follows with the establishment of appropriate entities and relationships.
          • Thema is introduced as a superclass of all entities that can be subjects of a work.
          • Attributes and relationships of thema are presented ;
          • No entities are explicitly predefined in Group 3;
          • Nomen is introduced (including attributes and relationships) and is defined as a separate entity instead of an attribute .
    5. Relationships with FRBR and FRAD
  • 28. Relationship of FRSAD with FRAD
    • Independent parallel development; no hierarchical relationship between the two models;
    • FRAD was published when FRSAD was in the world-wide review;
    • • User tasks: “ Contextualise ” and “ Justify ” in FRAD vs. “Explore” in FRSAD;
    • • Name in FRAD vs. Nomen in FRSAD ;
      • • Name, Identifier and Controlled access point as separate entities in FRAD vs. values of the attribute “Type of Nomen” in FRSAD;
    • • Rules and Agency as new entities in FRAD and not explicitly modelled in FRSAD.
  • 29. The future: harmonization of the FRBR family
    • A new working group under the umbrella of the FRBR RG will have to develop a new model, taking FRAD and FRSAD into account
  • 30. 6. Implications for interoperability
  • 31. A few additional slides
    • Our decisions
      • Should we treat SUBJECT as an abstract model? --Yes.
      • Should we be talking about different types of subject ‘stuff’? – No. Systems or implementations can have their own types.
      • Should we go ahead to identify nomen as a separate thing from thema? – Yes.
  • 32.
    • Implications considered and future R&D
      • FRSAD in the FRBR family
      • FRSAD in the IFLA namespace project
      • FRSAD mapping to SKOS
      • FRBR family entities for metadata domain models based on Dublin Core Application Profiles requirements
      • FRSAD for interoperability approaches
        • with legacy authority systems
          • Nomen-based, or transferring into thema-nomen model
        • with thema-nomen ready systems
        • within a unified system (  e.g., FAO’s authority system)
        • across subject authority systems (  e.g., INSPEC, LCSH-LCC)
        • for different types of KOS (  e.g., classification, thesaurus, geographic name thesaurus, digital gazetteer, picklists, agents in FOAF, corporate body in FOAF)
        • for application or implementation needs (e.g., RDA, art & architecture, biomedical, education, business…)