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@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@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
_______________________________________________
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
_______________________________________________
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
