Associating dimensions depending on physical state/layout

[anarchivist]

Hoping this is a reasonable place for a question (if not, I'm happy to post to the Google Group instead!). I'm hoping to understand how Linked.art could describe dimensions of in an object that has one or more physical states.

Context: I'm part of the Joint Task Force for the Art and Rare Materials BIBFRAME Extension, and we are currently looking at measurement to update the proposals from the LD4P2 ARM work. We've been looking at properties and way to describe "arrangement", which relates to specific physical states that an object can be in (e.g. a map can be folded or unfolded). We'd like to describe things like dimensions in some cases for each arrangement (e.g. dimensions for a map when folded/when unfolded).

I'll also note we're looking for a specific candidate property to denote "arrangement," and that "arrangement" itself is unfortunately overloaded as it means something else specific in archives.

[SamiNorling]

I'm not sure if the model at this stage has an explicit pattern for representing information about an object within a specific "state". The closest thing that comes to my mind is the pattern for identifiers within a specific context (e.g., another museum's temporary registration number for our artwork loaned for an exhibition, which is the context for that identifier). But that pattern looks like it may have been removed from the model since my notes on that pattern indicated it could be found at https://linked.art/model/object/identity/, which is now a more general Names and Identifiers section in the Baseline Patterns page, and it doesn't include context-specific identifiers.

Because we have many complicated dimensions scenarios and conventions for capturing them in our CMS, I have included a DimesionsObjectSample.xml file in my working files to make sure I address every possible IMA dimensions scenario in my transformation to JSON-LD. The in-progress JSON-LD file for this dimensions data set is at https://github.com/IMAmuseum/LinkedArt/blob/master/JSON/DimensionObjectsSample.json. It may provide some fodder and/or illustration for this conversation, as an example of the current model for dimensions applied to various dimension scenarios.

Documentation of our various Dimension types that we catalog is also included in the repo - https://github.com/IMAmuseum/LinkedArt/blob/master/Documentation/LAB_EMu_Catalogue_DimensionTypes_2019-04.txt.

I would be interested to read others' thoughts on how best to represent the "state" or context of an object in relation to certain assertions (i.e., its dimensions). From our dimension types, the following would be possible states of our works that aren't currently represented in the in-progress JSON-LD, apart from in the _labels for the dimensions:

• Hanging Height
• Installed Dimensions
• Rolled Dimensions
• Dimensions Closed
• Dimensions Opened

Perhaps a way to type these states would be a solution, if not an explicit pattern for states, or information within a certain context.

[azaroth42]

The current proposal around "State" is to use a temporal entity representing the timeframe during which the related entity had some property.

Examples:

• Box is open
• Map is unfolded
• Person identifies as female
• Building is used as a place of religion
• and similar

See #179 and #180

[scossu]

While the physical state of an object, which is a great way to group measurements, is definitely tied to time, it seems to me that physical state changes in relation to time are less relevant and much complicated to track than the examples in #180 .

I would consider the "folded" and "unfolded" states of a map as potential and intrinsic to the object. Therefore, could the time factor be considered optional?

[natuk]

I agree, while the discussion around States is important, for dimensions perhaps it is enough to type them and look at them independently of state.

[scossu]

On a second thought, to echo @natuk , even states may not be always relevant to multiple measurements. E.g. parts of an object that one does not want to model as separate components, but are still important to measure separately (the pinhole diameter of a pinhole camera, for example).

A "measurement object" could carry a set of measurements, classifiers and/or annotations, and be related either directly to an object, or to a temporary state, giving the highest flexibility with relative simplicity.

[azaroth42]

Options discussed on call 2020-04-08:

Object has_dimension dim ; dim p2 has type dim2 p2 has type

Object has state state has type state has dimension

has type has type Object has_dimension dim dim has type width dim was assigned by assignment used specific technique

[azaroth42]

The last option would be consistent with the measurement pattern: https://linked.art/model/object/physical/#measurements-of-dimensions

And would just add one more property to the AttributeAssignment ... either technique referring to a Type, or specific_technique referring to a DesignOrProcedure.

My preference would be for just technique, as there isn't necessarily anything specific, just a general process that was followed (of opening the object before measuring).

Thus:

{
  "@context": "https://linked.art/ns/v1/linked-art.json",
  "id": "http://lod.example.org/museum/Dimension/0",
  "type": "Dimension",
  "assigned_by": [
    {
      "id": "http://lod.example.org/museum/AttributeAssignment/0",
      "type": "AttributeAssignment",
      "technique": [
        {
          "id": "http://vocab.org/measuring-while-open",
          "type": "Type"
        }
      ]
    }
  ]
}

[azaroth42]

Discussion on call of 2020-09-23: Possible to have a classification on the Dimension itself, which would be simpler, but that classification is a little bit strange ("open-ness" ?) instead of a technique on the Attribute Assignment. General consensus was that the technique is clearer if a longer path, but that the attribute assignment node gives us a lot of other opportunities for description, and we have it anyway for the measurement activity.

So decision was to use technique on attribute assignment.

[beaudet]

Would it be appropriate to use the 4 existing AAT terms for extent designation as the technique? Those are: common, general, overall, and particular? or should I instead just mint our own identifiers or use the "element" name as a Name somehow. Can an AttributeAssignment activity be named?