Thesaurus labels, FR Names, relation between FRs and Thesauri
Do not edit this page in Rich Text mode, only in Wiki mode

Meta-thesaurus

Introduction

"Meta-thesaurus" is a fancy name for a thesaurus that describes each thesaurus in RS

Iconclass                                           << meta-thesaurus
  Susanna bathing, usually in or near a fountain... << thesaurus value
RKD Keywords                                        << meta-thesaurus
  Old testament & apocryphal                        << thesaurus value

Included information

The meta-thesaurus includes the following info:

• rdf:type: always skos:ConceptScheme
• rso:hasDomain: a specific CRM class (see BMX Issues#Thesaurus Requirements for details) used to make connection to FRs (see below):
  crm:E39_Actor (including crm:E21_Person, crm:E74_Group, crm:E40_Legal_Body),
  crm:E53_Place,
  crm:E4_Period (a named event; BM has such thesauri though we do not yet relate to them in RS3.4),
  crm:E55_Type (excluding the more specific classes below),
  crm:E57_Material,
  rso:E55_Technique,
  crm:E58_Measurement_Unit (though there are no FRs for it)
• rso:isSearchable (0,1, denoted as s in the table below): Although FRs drill deep and wide into the object, some thesauri are not applicable to FC70_Thing, so they are not searchable
  RS-1017
• rso:isTag (0,1, denoted as t in the table below): Whether the thesaurus is "interesting enough" to be used as a source of tags. Tags are general categories to be used for categorization of research questions and comments, see Tags Spec
• rdfs:label shown in the UI (after the term in FR search).
  • Includes the data source, so the user can distinguish one thesaurus from another, eg:

    RKD Artist, RKD Person, BM Person/Institution, RKD Object, BM Object

  • Terms are printed like this (during and after auto-completion):

    Rembrandt [RKD Artist, BM Person/Institution], Bredius [RKD Person], Painting [RKD Object], Painting [BM Object]

    The thesaurus name in brackets indicates the dataset that the term comes from, and can find objects from.
    Coreferenced terms show both thesauri, indicating that objects from both datasets can be found with this one term.

• rdfs:comment including examples and a link where appropriate (not currently used by the system)

Example:

Meta-thesaurus table

https://svn.ontotext.com/svn/researchspace/trunk/data/thesauri-meta.ttl

• Click on the headings to sort the table.
• The actual meta-thesaurus is generated from the table below using Emacs macros.
  All hail Emacs!

6-Feb-2017: broken into subsections for easier external linking.

BM Thesaurus

See https://github.com/findsorguk/bmThesauri for CSV download and BM-thes-count.txt for counts.

YCBA Thesaurus

Other Thesauri

Term Coreference using sameAs

TODO Vlado to expand
If a term is co-referenced between two thesauri (using owl:sameAs) then both labels are printed, so the user knows he will search across two data sources, eg:

Rembrandt [RKD Artist, BM Person/Institution]

Lucikly, whenever two terms are declared sameAs, their respective thesauri are equivalent with respect to rso:hasDomain.
Otherwise we'd get a messup with regards to FR compatibility.
This is another reason why rkd-person cannot be mapped to crm:Person, it has to be mapped to the same as bm-person-institution (which is crm:Agent). See last section

Using a Thesaurus as a Value

In a few cases, a thesaurus itself is used as a value to indicate the "super-type" of something, followed by a term type:

Trailing Slash

We use a trailing slash at the end of thesaurus URIs, so that term URIs use them as a prefix

• A couple of people didn't like a qualified name with an empty local name, though it is valid syntax
• Mitac: rkd-research:; sounds unusual, better use rkd:research;
• Dido: a W3C recommendation is not to have "/" at the end of URIs
• Vlado: an advantage of the present notation is that it textually relates the thesaurus type (rkd-research:) to thesaurus values (rkd-research:X-radiography)

FR Names

FR Implementation defines a number of FR (CRM Search) relations, and the meta-thesaurus describes the following info about them:

• rso:hasRange is the class applicable to the FR
• rso:hasOrder determines FR ordering and default (see FR Enhancements#Preferred FRs)
• rdfs:label: label appearing in the search sentence. It's short because the following term includes the thesaurus name, eg:

  from Amsterdam [RKD Place] and from Rembrandt [RKD Artist] and is Painting [RKD Object] and Vertical rectangle [RKD Shape]

• rdfs:comment: long description appearing in a tooltip

FR Names Table

Please edit this descriptive info, but don't change the meaning. The full meaning is described and depicted precisely in diagrams at FR Implementation (started from FRthing.docx by M.Doerr and K.Tzompanaki)

rso:FR32_used_technique uses an extension sub-class rso:E55_Technique, so as to obtain more precision (see next section)

Special FRs

The last 4 FRs in the table above are special. Jana: how will you handle them?

• hasRange: rdfs:Literal and xsd:boolean are not used in the Compatibility query described in the next section.
• hasOrder: although returned in this order by the backend, the default FR is determined by the UI, see FR Enhancements#Keyword-Date-Identifier Search
• Unlike all other FRs, these FRs are not fully defined in FR Implementation-old. The FR name is still used by the frontend to request it from the backend, but the backend use some special processing:
  • luc:myIndex stands for "FTS using Lucene, using a FTS index named myIndex". It is not but through the OWLIM Lucene FTS mechanism
  • rso:FR108i_82_produced_within is defined at Date Search
  • rso:FR1_identified_by is defined as an FR, but leads to a literal (all others lead to a term node)
  • rso:FR138i_has_representation is defined at FR Enhancements#Objects with Images

Thesaurus to FR Compatibility

When the user auto-completes a term in FR search, the system:

• determines all FRs applicable to that term (eg the FRs applicable to Amsterdam [RKD Place] are "about", "from" and "located in")
• then determines all thesauri compatible with those FRs (eg in the above case they are [RKD Place] and [BM Place])

The compatibility relation between Thesauri and FRs is many-to-many, and is determined from the following triples:

Thesaurus --rso:hasDomain-> Class <-rso:hasRange-- FR

eg

Given a term selected by the user, the set of compatible thesauri and FRs is determined by this query (! indicates a query param):

The UI mockup showed each thesaurus class with different color, but the color was removed in the final design.

Why Custom Domain and Range

• We use property rso:hasRange that is unrelated to rdfs:range, because we don't want FRs go generate spurious class assertions
• We use property rso:hasDomain (at thesaurus level) instead of rdfs:domain (at term level):
  • For greater flexibility: though often the same is repeated at term level, sometimes it is not
  • To avoid subclass inferencing.
    The currently searchable classes are highlighted below. To avoid mixing E55_Type with E55_Technique and E57_Material, we'd need to find the lowest class related to the FR, which would complicate the query