[Crm-sig] Issue 419: Activity plans
Dear all, During discussions on the future of activity plans it appears that we have 3 options: 1) Activity plans to remain as part of CRMsoc. This makes sense since obeying laws and receiving penalties take place in societies and such things appear to match the model for activity plans. However, they are not central to the current CRMsoc discourse. 2) Activity plans to move to CRMbase. This makes sense given that Purchase is in core and there is an increasing amount of interest in business transactions, but again perhaps not central enough to the CRMbase focus. 3) Activity plans to become its own extension. This makes sense as it is a construct focussing on possible future events rather than past events mainly concerning the CRM and its extensions otherwise. Also it being a separate extension could create a space for business transactions. I support option 3 and I would like us to discuss this at the next SIG meeting and decide. I am happy to act as the maintainer of such an extension. All the best, Thanasis ___ Crm-sig mailing list Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig
Re: [Crm-sig] HW 496 - Recommending Types
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 > 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 (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@
[Crm-sig] HW Questions - #534, #519
#534 - In that RDF doesn't allow for meta-properties, we would need to reify anyway. At which point we couldn't use a shortcut. So while I understand the challenge, I don't have (or need) a solution. Seems like it would need to be on a case by case basis to determine the relationship of the meta property to the main property anyway? #519 - I think we exhausted time, energy and options in the last SIG on this one. Not sure what evidence we were looking for that would make a difference? 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
Re: [Crm-sig] HW 496 - Recommending Types
While unfortunately true, it is more fortunate that linked.*art* is not in any way related to Linked In Rob On Tue, Jun 8, 2021 at 1:51 PM Дарья Юрьевна Гук wrote: > Dear all, > please pay attention that access to LinkedIn is closed in some countries, > me is from one of them. Sorry. > > > > With kind regards, > Daria Hookk > > Senior Researcher of > the dept. of archaeology of > Eastern Europe and Siberia of > the State Hermitage Museum, > PhD, ICOMOS member > > E-mail: ho...@hermitage.ru > Skype: daria.hookk > https://hermitage.academia.edu/HookkDaria > -- 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
Re: [Crm-sig] HW 496 - Recommending Types
Dear all, please pay attention that access to LinkedIn is closed in some countries, me is from one of them. Sorry. With kind regards, Daria Hookk Senior Researcher of the dept. of archaeology of Eastern Europe and Siberia of the State Hermitage Museum, PhD, ICOMOS member E-mail: ho...@hermitage.ru Skype: daria.hookk https://hermitage.academia.edu/HookkDaria___ Crm-sig mailing list Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig
[Crm-sig] HW 496 - Recommending Types
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 (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] [HW] Issue 536, has dimension on Time and Place
I propose to defer the discussion of Issue 536 until after #531 and #537 have been resolved, on the grounds that the changes from those issues will affect the decision about any new properties for shortcutting from an observable entity (or place) to a dimension. In particular, if all observable things can have dimensions, then the existing has_dimension could simply change its range to Observable Entity. As (currently) Places are not observable, they would need a new property, following the "mathematically calculated" dimension definition from Martin. 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
Re: [Crm-sig] Issue 537 Homework
My +1 to this reformulation. Rob On Tue, Jun 8, 2021 at 6:05 AM Martin Doerr via Crm-sig < crm-sig@ics.forth.gr> wrote: > Dear Robert, All, > > The current problem of S4 Observation is the single-property formulation, > dictated by E13 Attribute Assignment, but compatible with INSPIRE and E16 > Measurement. On the other side, it will never allow for observing > distances. Therefore, in order to proceed the generalization of Measurement > in CRMsci, we can take two paths: > > A) Consider a minimal change in the definition of S15 Observable > Entity and S4 Observation, generalize E16 Measurement with these > definitions, and later revise S15,S4 to be a wider generalization. This > will leave us with a consistent intermediate stage. > > B) Begin with change in the definition of S15 Observable Entity and > S4 Observation, Issue 531, and then rework all properties. > > I describe here solution A (a modification of the previous formulation of > this issue). > > I assume as background the change of S15 Observable Entity to superclass > of E5 Event, S10 Material Substantial, by Issue 531 > > Change S21 Measurement to superclass of E16 Measurement. > > Change O24 measured (was measured by) to superproperty of P39 measured > (was measured by). > > Confirm! O16 observed value (value was observed by) to be superproperty of > P40 observed dimension (was observed in). It is no more inconsistent. > > Declare O12 to be identical with P43 for E18 Physical Thing, which is the > intersection of E70 Thing and S15 Observable Entity. > > O9 observed property type (property type was observed by) : subproperty of > P177 assigned property of type (is type of property assigned) > > This relatively conservative readjustment appears to be the best way to > detangle the issues 531 and 388 (Position Measurement) > > Please check! > > Best, > > Martin > > -- > > Dr. Martin Doerr > > Honorary Head of the > Center for Cultural Informatics > > Information Systems Laboratory > Institute of Computer Science > Foundation for Research and Technology - Hellas (FORTH) > > N.Plastira 100, Vassilika Vouton, > GR70013 Heraklion,Crete,Greece > > Vox:+30(2810)391625 > Email: mar...@ics.forth.gr > Web-site: http://www.ics.forth.gr/isl > > ___ > Crm-sig mailing list > Crm-sig@ics.forth.gr > http://lists.ics.forth.gr/mailman/listinfo/crm-sig > -- 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] Issue 537 Homework
Dear Robert, All, The current problem of S4 Observation is the single-property formulation, dictated by E13 Attribute Assignment, but compatible with INSPIRE and E16 Measurement. On the other side, it will never allow for observing distances. Therefore, in order to proceed the generalization of Measurement in CRMsci, we can take two paths: A)Consider a minimal change in the definition of S15 Observable Entity and S4 Observation, generalize E16 Measurement with these definitions, and later revise S15,S4 to be a wider generalization. This will leave us with a consistent intermediate stage. B)Begin with change in the definition of S15 Observable Entity and S4 Observation, Issue 531, and then rework all properties. I describe here solution A (a modification of the previous formulation of this issue). I assume as background the change of S15 Observable Entity to superclass of E5 Event, S10 Material Substantial, by Issue 531 Change S21 Measurement to superclass of E16 Measurement. Change O24 measured (was measured by) to superproperty of P39 measured (was measured by). Confirm! O16 observed value (value was observed by) to be superproperty of P40 observed dimension (was observed in). It is no more inconsistent. Declare O12 to be identical with P43 for E18 Physical Thing, which is the intersection of E70 Thing and S15 Observable Entity. O9 observed property type (property type was observed by) : subproperty of P177 assigned property of type (is type of property assigned) This relatively conservative readjustment appears to be the best way to detangle the issues 531 and 388 (Position Measurement) Please check! Best, Martin -- Dr. Martin Doerr Honorary Head of the Center for Cultural Informatics Information Systems Laboratory Institute of Computer Science Foundation for Research and Technology - Hellas (FORTH) N.Plastira 100, Vassilika Vouton, GR70013 Heraklion,Crete,Greece Vox:+30(2810)391625 Email: mar...@ics.forth.gr Web-site: http://www.ics.forth.gr/isl Issue_537.docx Description: MS-Word 2007 document ___ Crm-sig mailing list Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig
