RS-910 : mockup
RS-911 : implementation

Introduction

This is a simple mockup of RForms for BM data. It is a data mapping that shows the set of fields, their sequence and grouping.

• TODO BM: review data grouping and label wording
• TODO BM, Anna: BM RForms Test with some objects
• The forms are fashioned after BM Collections Online (COL), but the implementation won't try to mimic the COL look & feel.
• It is not a graphic design. Various UI looks can be found in Data Display Discussion, but this was not finalized and we have no time in RS3.5 to implement a different look.

Production Notes

Production notes for BM RForm:

• took the BM RDFer generation script (config.xml, 154Kb) and all auxiliary scripts
  (bibliography-config.xml biography-config.xml config-nocomment.xml dimensionunit-config.xml flat-config.xml image-config.xml inline-thesauri-config.xml thesaurus-config.xml)
• wrote script BM-properties.pl to extract used classes and properties to BM-properties.xls.
  Analyzed for potential leaks (eg object->collection->all other objects).
  Made decisions which BM props to use, and which to
• removed commented-out statements (117Kb)

  perl -e "$/ = undef; $_ = <>; s{<!--.*?-->}{}sg; print" config.xml > config-nocomment.xml

• wrote script BM-rform.pl to extract all triples from config-nocomment.xml (25.6Kb, 527 URIs+triples)
• added options to discard some uninteresting triples (16.6Kb, 368 URIs+triples)

  -p discard statements about mus_obj_parts
  -d discard display_wraps
  

• grouped statements (eg all statements that generate P1_is_identified_by are grouped together)
• reduce further by abstracting a bit more (150 triples)
• post bugs throughout (sprinkled in footnotes throughout the page)

Reference for BMO Documentation

I have fairly good confidence that this page covers all intricacies of the mapping, and covers all property paths.

• The BMO documentation RS-695
  should be checked against the prop paths (left column) listed below.
• Note that for some paths we use CRM prop instead of specific BMO subprops, but I think that I've mentioned all BMO subprops in footnotes
• This is complete re Objects, but not complete re Terms (we use only the prefLabel of each term; additional term info such as Person profession, nationality and dates is not covered)

Notation and Punctuation

The first column of BM RForm below defines the data

• ">>" indicates the level of nesting of data
• We use numerous footnotes ({footnote} macro) that are printed at the end of each section ({display-footnotes} macro)

The other columns give some examples, including:

• section headers: hard-coded labels
  • TODO Jana: How to skip these headers when there is no data?
• subsubsubsection headers: used only to ease comprehension and provide hyperlink anchor: not displayed on the form!
• rdfs:labels of properties, as explained in Labels
• which fields to combine in one line
• what punctuation to use (eg table cell, colon or parentheses)
  • Punctuation is subject to discussion and optimization
  • TODO Jana: How to skip the punctuation when there is no data?

In many cases I've mixed & matched data from several objects, so don't expect the data to make full business sense

Annotation Points

• Dominic dislikes that there are too many Annotation Points (APs) in the RKD forms. If a reduced set as decided here works out ok, we'll go back to RKD forms and reduce the APs there as well.
  • Currently the RForms generate an AP for every statement. But as you can see below, there are many statements with compacted or no visual representation at all.
    TODO Jana: discuss with Dominic
• Unless and until BM implements BM Association Mapping#Association Terms and Concept Schemes, users won't be able to propose New Values consistent with the old values
  • Watch RS-716 for status
  • See in particular this comment for details
• Vlado suggests to have one AP per "line" in the examples below (i.e. at the incoming property of every important node)
• When decided, put a below for every AP

Redundancy Removal

The data about an object is fetched with Inferred triples (rdfs:subPropertyOf and owl:inverseOf reasoning).
So the forms don't use all BM extension properties: when the corresponding CRM super-property does the same job.
This also means the repository returns some redundant data, which is handled by Complete Museum Object#Remove Redundant Triples:

• Remove inferred superproperties of explicitly stated and requested subproperty.
  Eg if P48_has_preferred_identifier (subproperty) is requested, the same identifier value is not returned as P1_is_identified_by (superproperty)
• Remove direct (shortcut) property if there is longcut path through EX_Association (see BM Association Mapping#Code In Reified Association), eg:

  <obj/acquisition> a E8_Acquisition;
    P23_transferred_title_from <person>;
    P140i_was_attributed_by [a bmo:EX_Association;
      P141_assigned <person>;
      bmo:PX_property P23_transferred_title_from;
      P2_has_type <thesaurus/acquisition/bequeathed_by>].
  

  will return the statements in EX_Association but not the direct statement P23, since the association has the P23 info plus more (P2)

Display Wrap

PX_display_wrap is a redundant note including " :: " separators. All the text there is supposed to be represented in structured properties.
But it's very useful to display while in "debug mode", in order to check for omissions and inconsistencies (in data or in RS)

• "debug mode": PX_display_wrap missing from properties.txt (0 in BM-properties.xls) =>
  RS fetches the literal through superprop P3_has_note and prints it amongst the other P3_has_note.
• "release mode": PX_display_wrap present in properties.txt (1 in BM-properties.xls) =>
  RS fetches PX_display_wrap, but doesn't display it anywhere in the rform below, so it suppresses the literal
• TODO Vlado: add P3_has_note in some more nodes, to benefit from this

Examples:

• Acquisition date :: 1876 ::
• Object type :: buckle ::
• Consists of :: bronze ::

TODO Anna: check whether structured representation of this is present in PPA44216.

• Print made by :: Cari, Godisart de ::
• Published by :: Martinet, Aaron ::
• Bibliograpic reference :: De Vinck 10531 ::
• Bibliograpic reference :: IFF 9 ::
• Subject :: satire ::
• Component of series :: Musee Grotesque ::

Property Labels

The examples show the labels of which properties to show

• Print the rdfs:label of most properties (eg P7_took_place_at->"took place at")
  • CRM and RSO have them in data/rdfs-labels.ttl:
    RS-322
  • BMO is still missing some:
    RS-1135
• Eg the notation "P7_took_place_at/skos:prefLabel" means to print:

  took place at: Paris, France

  • Print the rdfs:label of P7_took_place_at (assumed!)
  • Go through P7_took_place_at to a Place thesaurus node, and print its skos:prefLabel
• Do not print the labels of:
  • Generic properties: P1_is_identified_by, P2_has_type, P3_has_note
  • Properties that traverse known "empty" nodes (only required by the CRM model, have no useful info)

Class Labels

• Each object has many rdf:type's due to inheritance. It's hard to pick the most specific ones, unless we implement a third kind of Redundancy Removal
• So we prefer to print property names, and the application-specific P2_has_type

Newlines

Some BM fields have newlines in them. E.g. in this object:

• Curator's comments is a whole story.
  It's mapped to bmo:PX_curatorial_comment (uses \r\r\n as newline)
• Exhibition History is a list using dashes.
  It's mapped to bmo:PX_exhibition_history (uses \r\n as newline)
• PX_physical_description sometimes includes an itemized description (eg all 50 folios included in a folder)
• General notes might sometimes also include newlines.
  They are mapped to P3_has_note (and PX_curatorial_comment is also accessed through this property).

Replace all consecutive newlines [\r\n]+ in all text fields with a single "<br/>\r\n" on output. RForms displays <br/> as a newline.
RS-1152

BM RForm

Title & Description

Images of the Object

Images are displayed in:

• separate panel (Images, to be renamed from "Related Content") as thumbnails
• separate tab (Images, to be renamed from "Relations") in bigger size and with additional info: RS-1267

Problems with asset descriptions (image notes): RS-772 #8:

• When a user attaches an asset in the BM database, the object's PX_physical_description is copied to the image note.
  Then it can be edited by the user, but most often is not, so often the asset descriptions are the same as PX_physical_description (i.e. useless)
  • Alternative1: Josh to suppress image notes equals to PX_physical_description
  • Alternative2: Mitac to skip image notes equal to PX_physical_description
  • Alternative3: RForm to skip the note of P138i_has_representation and show only the note of PX_main_representation.
    This is the best solution for tab Images, since it's useful to see PX_physical_description there
• Some of the notes are very long (whole sagas), eg description of 50 folios
  • Jana to replace multiple consecutive newlines with a single newline
  • Option: Jana to find a collapsible component, display only the first 1000 chars, and add JS link "More" to show the rest
• These examples are from PRN COC231583, codexid 3152931)

bmo:PX_has_main_representation 2 >P3_has_note >P48_has_preferred_identifier >>P2_has_type/skos:prefLabel >>rdfs:label	Full: Front Asset ID: 544708
P138i_has_representation >P3_has_note >P48_has_preferred_identifier >>P2_has_type/skos:prefLabel >>rdfs:label	Full: Back Asset ID: 544695

Identifiers

Owners, Keepers, Location

Bibliographic References

Types

Materials

Production & Techniques

All info about one Production node should be on one line, see BM Association Mapping#Uncorrelated Events Display.
 New mapping: Production details are now found in subevent nodes: P108i_was_produced_by (single production node) -> P9_consists_of (production1, production2, etc)

Made Part

Repaired

Original From

Inscriptions & Images on Object

• Print one group for each P65_shows_visual_item. Below are depicted two groups, separated with an empty row
• Some examples: EAF121893 (inscriptions), RFI42020 (images)
• Skip the label not only of P65_shows_visual_item, but also P14_carried_out_by and P138_represents since the corresponding P2_has_type is always present and more informative

Aspects

Aspects are used mostly for Coins. Print each aspect on one line

rdfs:label duplicates P2_has_type so we skip it. RS-1163

Dimensions

Print each Dimension node on one line:

• <type>: <min>-<max> <unit> (<note>)

where <type> is in a separate cell, <min>-<max> are separated by dash, <unit> is separated by space, and <note> is in parentheses

Notes

P3_has_note includes PX_curatorial_comment and (in "debug mode") PX_display_wrap

About (things Depicted, Referred)

Acquisition

Print one line for each "business property" of the acquisition (P11, P17, P23, P28, P2, P4):

• property: <thesauruscTerm> (<type>)
• type: <type>
• time-span: <dates>

Events, Made For

Print 1 row of 4 columns per Made For or Event:

1. P2_has_type, else rdfs:label of property
2. P14_carried_out_by, else skos:prefLabel of thesaurus term
3. P7_took_place_at or none
4. P4_has_time-span or none

Collection, Series, Type Series