Allow `number_of_parts` on `HumanMadeObject`

[azaroth42]

Brought up on a call, it would be useful to have the number of parts property available for two, somewhat incompatible, use cases:

1. To know that there /are/ parts documented and thus to do the inverse search for those parts (e.g. part1 part_of whole, so if whole knew that there were 6 part records, a UI would know it was valuable to look for them
2. To know that there are parts to the collective record, regardless of whether they are documented or not. For example, partial chess set with 12 pieces remaining might or might not have the individual pieces described, but the number_of_parts as a comparable integer rather than human readable text would be valuable.

[Habennin]

So on the notion discussed in the last meeting that one could use dimension and then just type it, I found this AAT term:

https://www.getty.edu/vow/AATFullDisplay?find=component&logic=AND&note=&subjectid=300241583

components (objects parts) (Components (hierarchy name))

Note: Constituent parts of a larger object. A component differs from an item in that the item can stand alone as an independent work but the component typically cannot or does not stand alone. Examples are a panel of a polyptych or a discrete architectural component such as a dome.

I think it is a pretty good candidate.

[azaroth42]

agree with 241583 and will put into recommended list, with docs to say not to use number of parts.

[azaroth42]

So, it should be:

"dimension": [
  {
    "type": "Dimension",
    "value": 6,
    "unit": {"id": "https://vocab.getty.edu/aat/300055665", "type": "Type", "_label": "Numbers"},
    "classified_as": [
      {"id": "http://vocab.getty.edu/aat/300241583", "type": "Type", "_label": "Number of Parts"}
    ]
  }
]

Right? (There's no unit beyond just counting here, so put in "numbers")

No concern that 300241583 is just the concept of components, rather than number of components?

[cbutcosk]

Making the unit "numbers" when the manner of counting (enumerating/counting, sampling, averaging, estimating, etc) is unexpressed seems like a missed opportunity (less for the HMO case, but plenty of things in CH collections with uncountably-many parts )

[azaroth42]

Sampling, averaging etc would be the technique used on the measurement activity, rather than anything to do with the dimension itself. Dimensions are just structured data to connect the numeric value, the unit to make that value meaningful, and the type of dimension that the value+unit refers to... normally something like "18 inches high". That could also have an AttributeAssignment associated with it that gave "estimating" as the technique, as per the structure in https://linked.art/model/object/physical/#measurements-of-dimensions

So for this case when we're just measuring the number of parts there isn't a really a unit of measurement other than parts but that's more obviously the type and unit is still a required field on the Dimension structure. I guess it could be value: 6, unit: parts, classified_as: number-of-parts

If there's uncountably many parts, there's no dimension as there's no value.

[cbutcosk]

Ah, I definitely see what you mean about Dimension / MeasurementUnit now that I look at MU's scope note in particular -- https://cidoc-crm.org/entity/e58-measurement-unit/version-7.1.1 . So unit is only ranged MU, tough but fair as it goes.

Given that, in property terms your second pattern reads more naturally to me--unit is the thing counted (expressed as a term), classified_as denotes that conjunction's human-legible meaning. value: 2.0, unit: book-volumes, classified_as: count-of-book-volumes, value: 10.0, unit: candy, classified_as: count-of-candy, etc..

At the term level it seems like it would be advantageous to better align with other find-this-classifier-now-unwrap properties in the model. Simple counts are pretty common in real world data sets! If there is a chance other things will be counted it seems like value: 6.0, unit: parts, classified_as: counting would be a useful edit to your second pattern since it doesn't require consumers to know the thing counted before processing. Just a thought!

[beaudet]

All primary school teachers express their appreciation for Charlie's comment

[beaudet]

That said, what is the unit for aspect ratio? "Width/Length"?

[cbutcosk]

Yeah good point --width / height or maybe pixel wide / pixel high ?

[kkdavis14]

LUX has an issue with using 300055665 ("numbers") as our unit, because the front end will render the name of the unit along with the dimension integer for all dimensions. it makes sense when it's "34 cm" , but less sense when it's "4 numbers".

I argue for classified_as: parts or components, dimension: count 300404433, based on the hierarchy of AAT (count being in the dimensions hierarchy along with cm, etc). Rob argues for classified_as: count 300404433, dimension: parts. needs discussion.

[azaroth42]

unit: components -- 300241583 classified_as: count (sum total) -- 300404433

[azaroth42]

When we know the type of the part, I think this still works:

book dimension [{unit: pages, classified_as: count, value: 92}, {unit: chapers, classified_as: count, value: 7}]

Agreed?

[beaudet]

You mean like this? (after adding in a physical measurement corresponding to a physical space dimension for comparison)

Example of Physical Dimension of Book: classified_as: { term for width } value: 3.5 unit: { term for centimeters } possibly also supplemented with?? referred_to_by: {linguistic object classified as physical description of measured element; content: "spine" }

Example of Logical Dimension of Book: classified_as: { term for count } value: 92 unit: { term for pages or pagination} possibly also supplemented with?? referred_to_by: {linguistic object classified as physical description of measured element; content: "page count" }

[azaroth42]

Yep. Like this: https://linked.art/model/document/#pages

Think this one is done :)

[azaroth42]

Ooops, not yet. Need the actual number of physical parts version