[Crm-sig] HW 496 - Recommending Types

Athanasios Velios thanasis at softicon.co.uk
Fri Jun 11 17:29:47 EEST 2021


Dear all,

To follow up with this, and with the usual apologies for potentially 
misunderstanding the objective of the issue, I have done a quick scan of 
the CRM document to identify where these recommendations for types are 
done. Some are rather implicit but may be worth considering:

* E4: type of period
* E10: type of transfer of custody
* E15: type of identifier assignment
* E34: type of alphabet
* E56: type of language
* E57: type of material
* E58: type of unit
* E90 / P3.1: type of encoding

All the best,

Thanasis

On 08/06/2021 20:34, Franco Niccolucci via Crm-sig wrote:
> Dear Robert
> 
> dealing with vocabularies, we noticed (in ARIADNE) that named time periods may have some ambiguity as the same name may refer to different time spans depending on the location. It is a well-known fact firstly evidenced in the ARENA project with an interesting comparative diagram among several EU countries.
> This is more evident in archaeology, where e.g. "Iron Age” has a different meaning in Ireland and in Italy. I use to make a joke on this, telling the story of a time traveller who travelled in the year 50 AD from Roman Age back to Iron Age, while he simply went from Ronan Gaul (then in the Roman Age) to Ireland, which was never invaded by Romans and at the time was still in its Iron Age.
> 
> I think that this may be also relevant to Art, for example a “Renaissance painting” is dated to rather different time periods according to its provenance.
> 
> The solution we found to the issue is TeriodO https://perio.do/en/ a gazetteer of periods which may assign different time spans to the same name according to location. If this is interesting I can provide further details on how we successfully managed the issue.
> 
> regards
> 
> Franco
> 
> 
> 
> Prof. Franco Niccolucci
> Director, VAST-LAB
> PIN - U. of Florence
> Scientific Coordinator ARIADNEplus
> Technology Director 4CH
> 
> Editor-in-Chief
> ACM Journal of Computing and Cultural Heritage (JOCCH)
> 
> Piazza Ciardi 25
> 59100 Prato, Italy
> 
> 
>> Il giorno 8 giu 2021, alle ore 19:04, Robert Sanderson via Crm-sig <crm-sig at ics.forth.gr> ha scritto:
>>
>>
>> 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
>> _______________________________________________
>> Crm-sig mailing list
>> Crm-sig at ics.forth.gr
>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
> 
> 
> _______________________________________________
> Crm-sig mailing list
> Crm-sig at ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
> 


More information about the Crm-sig mailing list