[Crm-sig] HW 496 - Recommending Types

Robert Sanderson azaroth42 at gmail.com
Tue Jun 8 20:04:32 EEST 2021


All,

I think my part of the homework for #496 is to describe the Linked Art
requirements, process and decisions.

First - Linked Art is conceived of as an application profile for
art-related descriptions that uses CRM as its core ontology. It selects as
minimal as possible a subset of the classes and relationships needed to
fulfil the use cases. It draws mostly from CRM base, with a few select
terms from sci and dig. There is also a Linked Art extension that defines a
small number of terms that aren't available in any other extension (but
typically align with the direction that soc is taking). You can see Linked
Art's documentations here: https://linked.art/


We also need to select vocabulary to use with P2_has_type and rely heavily
on the Getty AAT thesaurus. We divide the vocabulary into three
conditional, disjoint buckets:
  * Terms that MUST be used for the description to be able to be
understood.
  * Terms that SHOULD be used for the description to be easily
interoperable across institutions
  * Terms that MAY be used, as assistance to the community rather than
requiring them to look them up independently

We try to keep the MUST bucket as small as possible, and based on
cross-domain and universal use cases. Examples include:
  * Primary Name (A classification on an appellation that it is the "main"
name of the entity) vs Display Name (classification on appellation that it
is the human readable representation of an entity like a TimeSpan)
  * Activity Classifications: We need to distinguish Provenance,
Publishing, Promise and Exhibitions as having particular recommended
structures.
  * Meta types: We don't require any particular types for even things like
Painting, but we do require types on those types so we know what sort of
thing they are. For example, there is an "object type" which is required on
the object's type. Meta types include object type, nationality, culture,
gender, statement type, color, shape. Example:

E22 (the painting) p2_has_type E55 (painting) .  <-- painting is recommended
E55 (painting) p2_has_type <aat:300435443> (type of work) .  <-- type of
work is required

Now we can slot anything in to the "painting" slot and know that it's the
type of the work rather than some other classification... like shape or
color.

Thus we also require aat:300191751 for permanent transfers of custody or
location, and aat:300221270 for temporary transfers of custody or location,
per the recent decision to not add has_permanent_custodian to manage it at
the property level.

The SHOULD bucket is on the order of 100 terms for common requirements, but
ones that would reduce the ability to easily compare across institutions'
datasets, rather than ones that would make the data almost useless if they
weren't present.  These are things like the common types of statement about
an entity, the common types of Place, Group, or Object. Also the types of
comparable structure like Dimension, Appellation and Identifiers. Then the
common Measurement Units, Currencies, Languages. We use AAT for all of
these.

The MAY bucket is just things that we've found ourselves looking up and
want to make it easier for others to find.

Hope that helps,

Rob

-- 
Rob Sanderson
Director for Cultural Heritage Metadata
Yale University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20210608/148b6898/attachment-0001.html>


More information about the Crm-sig mailing list