Re: [Crm-sig] CRM translation working group

[Massoomeh Niknia via Crm-sig]

Hi,

Please count on me as well for the Persian version.

Kind regards,
Massoomeh 

> On 9. Mar 2021, at 10:30, Дарья Юрьевна Гук via Crm-sig 
>  wrote:
> 
>  Count me in as well for Russian version.
> 
> 
> 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 mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

Re: [Crm-sig] Issue:530 Bias in the CRM

[Nicola Carboni via Crm-sig]

Dear Thanasis, all,


I would be happy to join the discussion. Another useful reading other 
than the already cited ones, is ["Cataloguing Culture: Legacies of 
Colonialism in Museum 
Documentation”](https://www.ubcpress.ca/cataloguing-culture) by Hannah 
Turner.


Regarding the name and the scope of the issue: should we focus on data 
structure (I see the title of the issue is "bias in data structure") or 
specifically on ontologies and CRM?
While I do very much believe that data structure is an enormously 
important topic to discuss, it is an extremely large subject, and entail 
a larger series of problems which do derive from the informational 
foundation, the concept of structure itself, the recorded information, 
as well as disciplinary inheritance in the chosen subject matter.


I second rob proposing to focus on the problem of the ontology and the 
process of documentation/development. I would add that we should include 
some point about CRM as system of thought as well as the problem of 
formalisation.



* Implementations and Instances of the Ontology
 -- I think these are useful as second-order evidence, but that we 
should not be too involved or prescriptive.


I would include the topic, as to make clear the diversity in 
implementation (use of terminological systems as well as the use of the 
concept of controlled terminology itself), avoiding indeed the 
prescriptive stance.



Best,

Nicola


P.s. Great initiative :-)



On 8 Mar 2021, at 21:33, Athanasios Velios via Crm-sig wrote:

Thank you Erin. We are using Zotero already for the CRM so this is a 
good idea. I can check if a new folder can be created for issue 530.


T.


On 08/03/2021 19:01, Erin Canning wrote:
I would also like to be involved in this discussion, please! I too 
have a reading list on the subject that I would be happy to share; I 
have been meaning to pull everything into a Zotero library and this 
is a good excuse to do so. For a single article to start things off, 
I would recommend Miriam Posner's "What's Next: The Radical, 
Unrealized Potential of the Digital Humanities" 
 
as an interesting read.


Best,
Erin


Erin Canning

canni...@uoguelph.ca
Ontology Systems Analyst, LINCS
https://lincsproject.ca/



*From:* Crm-sig  on behalf of 
Athanasios Velios via Crm-sig 

*Sent:* March 8, 2021 12:52 PM
*To:* crm-sig 
*Subject:* Re: [Crm-sig] Issue:530 Bias in the CRM
EXTERNAL EMAIL:

Fantastic! Thank you for sharing and you are first in the list.

For the rest in list and if you did not attend today's sessions,
following discussion for issue 530, a working group is being formed 
to
discuss bias in the CRM. Please let me know if you wish to contribute 
to

the discussion.

All the best,

Thanasis

On 08/03/2021 17:17, Anaïs Guillem wrote:

Dear Thanasis, all,
Some digital humanists work and publish on this question of bias in
digital humanities: here is an example of very a propos publication:

https://journals.dartmouth.edu/cgi-bin/WebObjects/Journals.woa/xmlpage/4/article/425



>


I gathered myself bibliography about decolonizing knowledge and
methodology especially in digital project. I could join the 
discussion

of your working group if you want.
Cheers,
Anais

Le mer. 3 mars 2021 à 14:58, Athanasios Velios 
>> a 
écrit :


 Dear all,

 In version 7.1 a short but important sentence has been 
added at the end

 of the scope section:

 "Discussions on the types of bias present in the CIDOC CRM 
are in

 progress within the CIDOC CRM community."

 Issue 530 is used to track the discussions here:

http://cidoc-crm.org/Issue/ID-530-bias-in-data-structure



 >


 It is important to engage in this discussion so that we 
first understand
 the issues around bias and privileged positions and then 
how these may

 or may not impact the development of the model.

 We will then be more confident in making a more complete 
statement is
 future versions. Issue 530 is scheduled to be discussed at 
the community

 session of the forthcoming meeting.

 Looking forward to it.

 All the best,

 Thanasis
 ___
 Crm-sig mailing list
 Crm-sig@ics.forth.gr >

Re: [Crm-sig] CRM translation working group

[Дарья Юрьевна Гук via Crm-sig]

Count me in as well for Russian version.


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

Re: [Crm-sig] Issue:530 Bias in the CRM

[Athanasios Velios via Crm-sig]

Thank you Erin. We are using Zotero already for the CRM so this is a 
good idea. I can check if a new folder can be created for issue 530.


T.


On 08/03/2021 19:01, Erin Canning wrote:
I would also like to be involved in this discussion, please! I too have 
a reading list on the subject that I would be happy to share; I have 
been meaning to pull everything into a Zotero library and this is a good 
excuse to do so. For a single article to start things off, I would 
recommend Miriam Posner's "What's Next: The Radical, Unrealized 
Potential of the Digital Humanities" 
 
as an interesting read.


Best,
Erin


Erin Canning

canni...@uoguelph.ca
Ontology Systems Analyst, LINCS
https://lincsproject.ca/



*From:* Crm-sig  on behalf of Athanasios 
Velios via Crm-sig 

*Sent:* March 8, 2021 12:52 PM
*To:* crm-sig 
*Subject:* Re: [Crm-sig] Issue:530 Bias in the CRM
EXTERNAL EMAIL:

Fantastic! Thank you for sharing and you are first in the list.

For the rest in list and if you did not attend today's sessions,
following discussion for issue 530, a working group is being formed to
discuss bias in the CRM. Please let me know if you wish to contribute to
the discussion.

All the best,

Thanasis

On 08/03/2021 17:17, Anaïs Guillem wrote:

Dear Thanasis, all,
Some digital humanists work and publish on this question of bias in
digital humanities: here is an example of very a propos publication:

https://journals.dartmouth.edu/cgi-bin/WebObjects/Journals.woa/xmlpage/4/article/425 


>


I gathered myself bibliography about decolonizing knowledge and
methodology especially in digital project. I could join the discussion
of your working group if you want.
Cheers,
Anais

Le mer. 3 mars 2021 à 14:58, Athanasios Velios mailto:thana...@softicon.co.uk >> a écrit :

 Dear all,

 In version 7.1 a short but important sentence has been added at the end
 of the scope section:

 "Discussions on the types of bias present in the CIDOC CRM are in
 progress within the CIDOC CRM community."

 Issue 530 is used to track the discussions here:

http://cidoc-crm.org/Issue/ID-530-bias-in-data-structure 


 >


 It is important to engage in this discussion so that we first understand
 the issues around bias and privileged positions and then how these may
 or may not impact the development of the model.

 We will then be more confident in making a more complete statement is
 future versions. Issue 530 is scheduled to be discussed at the community
 session of the forthcoming meeting.

 Looking forward to it.

 All the best,

 Thanasis
 ___
 Crm-sig mailing list
 Crm-sig@ics.forth.gr >
http://lists.ics.forth.gr/mailman/listinfo/crm-sig 


 >




--
Anaïs Guillem
Architect-archaeologist
+33 630005089

___
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

Re: [Crm-sig] Bias in the CRM

[Robert Sanderson via Crm-sig]

Happy to join as well. I'm co-chair for the Bias Awareness and
Responsibility Committee for Cultural Heritage at Yale University, and
happy to share our experiences in that work. This is especially relevant to
our work as we move to adopt CIDOC-CRM (via Linked Art) as our baseline
ontology.

Some readings that we found useful:

https://doi.org/10.1080/0270319X.2019.1696069 -- "Aliens" vs Catalogers:
Bias in the Library of Congress Subject Headings
https://journals.litwinbooks.com/index.php/jclis/article/view/120 --
Cultural Humility as a Framework for Anti-Oppressive Archival Description
https://doi.org/10./cura.12191 -- Coming Together to Address Systemic
Racism in Museums
https://www.youtube.com/watch?v=MbrC0yvBCNo_channel=CollectionsTrust --
Decolonizing the Database by Dr Errol Francis
And, in print media: Algorithms of Oppression: How Search Engines Reinforce
Racism by Sufiya Noble of UCLA

A colleague and I presented about our work at EuroMed2020:  Libraries,
Archives and Museums are not Neutral: Working Toward Eliminating Systemic
Bias and Racism in Cultural Heritage Information Systems
Youtube capture of the zoom: https://youtu.be/V9-IHQQv-LY?t=26661

>From a CIDOC-CRM perspective, I think there are several issues to grapple
with, including those that were brought up today.
Some differentiation I would try to draw, and without presumption that the
answer for any of them is positive or negative:

* Ontology Features
 -- does the data structure described by the ontology introduce, require or
reinforce biases (especially harmful ones)?
 -- does the ontology preclude use or engagement with different communities
- is it accessible or are there barriers to entry that limit usage to
certain communities, thereby introducing bias through exclusion

* Documentation of the Ontology
  -- does the documentation about the ontology introduce, require or
reinforce biases?
  -- is the documentation accessible to broad and diverse communities?
  -- is the documentation transparent about issues that are known or
presumed to exist

* Methodology of determining the Ontology
  -- does the way we produce the ontology, from ideation to
standardization, introduce, require or reinforce biases
  -- is the methodology accessible to broad and diverse communities for
participation?
  -- is the methodology transparent as to how it works, and accountable
when it doesn't?

* Implementations and Instances of the Ontology
  -- I think these are useful as second-order evidence, but that we should
not be too involved or prescriptive.


And some micro-topics and thoughts, which are more opinionated:

* P48 Has Preferred Identifier -- this breaks the very beneficial "neutral
standpoint" design decision. We should deprecate it for this reason, quite
apart from the issue on the docket that it should be deprecated as an
outmoded design pattern.

* E31 Document, E32 Authority Document vs E73 Information Object -- The
need to distinguish "propositions about reality" and "terminology or
conceptual systems" from other information seems to introduce subjectivity
and the potential therein for harmful biases as to what constitutes "truth"
or "reality", and what is a "terminology" versus what is just a word
document.


HTH,

Rob



On Mon, Mar 8, 2021 at 12:25 PM Anaïs Guillem via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear Thanasis, all,
> Some digital humanists work and publish on this question of bias in
> digital humanities: here is an example of very a propos publication:
>
>
> https://journals.dartmouth.edu/cgi-bin/WebObjects/Journals.woa/xmlpage/4/article/425
>
> I gathered myself bibliography about decolonizing knowledge and
> methodology especially in digital project. I could join the discussion of
> your working group if you want.
> Cheers,
> Anais
>
> Le mer. 3 mars 2021 à 14:58, Athanasios Velios 
> a écrit :
>
>> Dear all,
>>
>> In version 7.1 a short but important sentence has been added at the end
>> of the scope section:
>>
>> "Discussions on the types of bias present in the CIDOC CRM are in
>> progress within the CIDOC CRM community."
>>
>> Issue 530 is used to track the discussions here:
>>
>> http://cidoc-crm.org/Issue/ID-530-bias-in-data-structure
>>
>> It is important to engage in this discussion so that we first understand
>> the issues around bias and privileged positions and then how these may
>> or may not impact the development of the model.
>>
>> We will then be more confident in making a more complete statement is
>> future versions. Issue 530 is scheduled to be discussed at the community
>> session of the forthcoming meeting.
>>
>> Looking forward to it.
>>
>> All the best,
>>
>> Thanasis
>> ___
>> Crm-sig mailing list
>> Crm-sig@ics.forth.gr
>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>>
>
>
> --
> Anaïs Guillem
> Architect-archaeologist
> +33 630005089
> ___
> Crm-sig mailing list
> Crm-sig@ics.forth.gr
> 

Re: [Crm-sig] Issue:530 Bias in the CRM

[Erin Canning via Crm-sig]

I would also like to be involved in this discussion, please! I too have a 
reading list on the subject that I would be happy to share; I have been meaning 
to pull everything into a Zotero library and this is a good excuse to do so. 
For a single article to start things off, I would recommend Miriam Posner's 
"What's Next: The Radical, Unrealized Potential of the Digital 
Humanities"
 as an interesting read.

Best,
Erin


Erin Canning
canni...@uoguelph.ca
Ontology Systems Analyst, LINCS
https://lincsproject.ca/


From: Crm-sig  on behalf of Athanasios Velios via 
Crm-sig 
Sent: March 8, 2021 12:52 PM
To: crm-sig 
Subject: Re: [Crm-sig] Issue:530 Bias in the CRM

EXTERNAL EMAIL:

Fantastic! Thank you for sharing and you are first in the list.

For the rest in list and if you did not attend today's sessions,
following discussion for issue 530, a working group is being formed to
discuss bias in the CRM. Please let me know if you wish to contribute to
the discussion.

All the best,

Thanasis

On 08/03/2021 17:17, Anaïs Guillem wrote:
> Dear Thanasis, all,
> Some digital humanists work and publish on this question of bias in
> digital humanities: here is an example of very a propos publication:
>
> https://journals.dartmouth.edu/cgi-bin/WebObjects/Journals.woa/xmlpage/4/article/425
> 
>
> I gathered myself bibliography about decolonizing knowledge and
> methodology especially in digital project. I could join the discussion
> of your working group if you want.
> Cheers,
> Anais
>
> Le mer. 3 mars 2021 à 14:58, Athanasios Velios  > a écrit :
>
> Dear all,
>
> In version 7.1 a short but important sentence has been added at the end
> of the scope section:
>
> "Discussions on the types of bias present in the CIDOC CRM are in
> progress within the CIDOC CRM community."
>
> Issue 530 is used to track the discussions here:
>
> http://cidoc-crm.org/Issue/ID-530-bias-in-data-structure
> 
>
> It is important to engage in this discussion so that we first understand
> the issues around bias and privileged positions and then how these may
> or may not impact the development of the model.
>
> We will then be more confident in making a more complete statement is
> future versions. Issue 530 is scheduled to be discussed at the community
> session of the forthcoming meeting.
>
> Looking forward to it.
>
> All the best,
>
> Thanasis
> ___
> Crm-sig mailing list
> Crm-sig@ics.forth.gr 
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
> 
>
>
>
> --
> Anaïs Guillem
> Architect-archaeologist
> +33 630005089
___
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

Re: [Crm-sig] Issue:530 Bias in the CRM

[Athanasios Velios via Crm-sig]

Fantastic! Thank you for sharing and you are first in the list.

For the rest in list and if you did not attend today's sessions, 
following discussion for issue 530, a working group is being formed to 
discuss bias in the CRM. Please let me know if you wish to contribute to 
the discussion.


All the best,

Thanasis

On 08/03/2021 17:17, Anaïs Guillem wrote:

Dear Thanasis, all,
Some digital humanists work and publish on this question of bias in 
digital humanities: here is an example of very a propos publication:


https://journals.dartmouth.edu/cgi-bin/WebObjects/Journals.woa/xmlpage/4/article/425 



I gathered myself bibliography about decolonizing knowledge and 
methodology especially in digital project. I could join the discussion 
of your working group if you want.

Cheers,
Anais

Le mer. 3 mars 2021 à 14:58, Athanasios Velios > a écrit :


Dear all,

In version 7.1 a short but important sentence has been added at the end
of the scope section:

"Discussions on the types of bias present in the CIDOC CRM are in
progress within the CIDOC CRM community."

Issue 530 is used to track the discussions here:

http://cidoc-crm.org/Issue/ID-530-bias-in-data-structure


It is important to engage in this discussion so that we first understand
the issues around bias and privileged positions and then how these may
or may not impact the development of the model.

We will then be more confident in making a more complete statement is
future versions. Issue 530 is scheduled to be discussed at the community
session of the forthcoming meeting.

Looking forward to it.

All the best,

Thanasis
___
Crm-sig mailing list
Crm-sig@ics.forth.gr 
http://lists.ics.forth.gr/mailman/listinfo/crm-sig




--
Anaïs Guillem
Architect-archaeologist
+33 630005089

___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

Re: [Crm-sig] Bias in the CRM

[Anaïs Guillem via Crm-sig]

Dear Thanasis, all,
Some digital humanists work and publish on this question of bias in digital
humanities: here is an example of very a propos publication:

https://journals.dartmouth.edu/cgi-bin/WebObjects/Journals.woa/xmlpage/4/article/425

I gathered myself bibliography about decolonizing knowledge and methodology
especially in digital project. I could join the discussion of your working
group if you want.
Cheers,
Anais

Le mer. 3 mars 2021 à 14:58, Athanasios Velios  a
écrit :

> Dear all,
>
> In version 7.1 a short but important sentence has been added at the end
> of the scope section:
>
> "Discussions on the types of bias present in the CIDOC CRM are in
> progress within the CIDOC CRM community."
>
> Issue 530 is used to track the discussions here:
>
> http://cidoc-crm.org/Issue/ID-530-bias-in-data-structure
>
> It is important to engage in this discussion so that we first understand
> the issues around bias and privileged positions and then how these may
> or may not impact the development of the model.
>
> We will then be more confident in making a more complete statement is
> future versions. Issue 530 is scheduled to be discussed at the community
> session of the forthcoming meeting.
>
> Looking forward to it.
>
> All the best,
>
> Thanasis
> ___
> Crm-sig mailing list
> Crm-sig@ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>


-- 
Anaïs Guillem
Architect-archaeologist
+33 630005089
___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

Re: [Crm-sig] CRM translation working group

[Anaïs Guillem via Crm-sig]

Count me in as well.
Cheers,
Anais

On Mon, Mar 8, 2021, 17:44 Franco Niccolucci via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Please count me in
>
> 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
>
>
> ___
> 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] CRM translation working group

[Franco Niccolucci via Crm-sig]

Please count me in

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


___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

Re: [Crm-sig] Issue 519: Homework to propose deprecation of P48, P54

[Dominic Oldman]

Hi All, (Sorry send key accidently)

This may well be the right approach, but I had a general point about these 
areas.

It would be useful to know the rationale behind them in the first instance. It 
occurred to me that perhaps the CIDOC-CRM needs to have some kind of associated 
knowledge base around it that points to the empirical work or evidence that led 
to the property in the first place so that we understand the origins of 
something. This is particular important as time goes by and different people 
join. So, it could be that items were, in hindsight, a mistake - that they are 
just vocabulary not ontology and not justified by practice, that they are 
borderline and there is a case for rationalisation, or that there has been a 
change of approach to these items.

It may be that we have some provenance here and I just need to look through the 
SIG forum etc. But I wonder whether this should be more formalised. This would 
strengthen the CIDOC CRM and provide more trust - but in any event the CIDOC 
CRM is not a top down ontology - it is a researched ontology and as an object 
of research it should be able to point to its underlying research, which is how 
the CRM should then be subsequently used - ontological commitments based on 
evidence.

Cheers,

Dominic


From:
Dominic Oldman 
Sent: 08 March 2021 08:25
To: Robert Sanderson ; crm-sig 
Subject: Re: [Crm-sig] Issue 519: Homework to propose deprecation of P48, P54

Hi All,

This may well be the right approach, but I had a general point about these 
areas.

But it would be useful to know the rationale behind them in the first instance. 
It occurred to me that perhaps the CIDOC-CRM needs to have some kind of 
knowledge base around it that points to the empirical work that led to the 
property in the first place so that we understand the origins of something. So, 
it could be that items were, in hindsight a mistake - that they are just 
vocabulary not ontology and not justified by practice, that they are borderline 
and there is a case for rationalisation, or that there is a change of approach 
to these items.

From: Crm-sig  on behalf of Robert Sanderson 

Sent: 03 March 2021 20:49
To: crm-sig 
Subject: [Crm-sig] Issue 519: Homework to propose deprecation of P48, P54

Dear all,

Thanks to Eleni for sending out the agenda and thereby reminding of our 
homework!

The proposal is to deprecate two properties, P48 has preferred identifier and 
P54 has current permanent location, following on from the conclusion of the 
discussion around the proposed property of 'has current permanent custodian' in 
issue 473.

As I recall it, the rationale for not adding 'has current permanent custodian' 
was not that the property did not make sense (it did) and not that it was not 
useful (it is), but that it was not necessary to add, as it is possible to add 
a classification to the activity that has the result of the transfer of 
custody, as to whether it is temporary or permanent.

The consequence of this was a (brief) examination of the specification for 
other properties where this pattern would be applicable, with the obvious 
deprecation candidates of P48 and P54.
The remediation pattern for P48 would be to add P2_has_type to the E41 
Identifier to indicate preferred-ness, or the E13 attribute assignment / E15 
Identifier Assignment of the identfier to the identified entity.
The remediation pattern for P54 would be to add a P2_has_type to the E9 Move to 
the location, in the same way that the resolution for 473 was to add 
P2_has_type to the Transfer of Custody.

The proposal should be considered separable -- not accepting the deprecation of 
P48 is not grounds for not accepting the deprecation of P54.

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 519: Homework to propose deprecation of P48, P54

[Dominic Oldman]

Hi All,

This may well be the right approach, but I had a general point about these 
areas.

But it would be useful to know the rationale behind them in the first instance. 
It occurred to me that perhaps the CIDOC-CRM needs to have some kind of 
knowledge base around it that points to the empirical work that led to the 
property in the first place so that we understand the origins of something. So, 
it could be that items were, in hindsight a mistake - that they are just 
vocabulary not ontology and not justified by practice, that they are borderline 
and there is a case for rationalisation, or that there is a change of approach 
to these items.

From: Crm-sig  on behalf of Robert Sanderson 

Sent: 03 March 2021 20:49
To: crm-sig 
Subject: [Crm-sig] Issue 519: Homework to propose deprecation of P48, P54

Dear all,

Thanks to Eleni for sending out the agenda and thereby reminding of our 
homework!

The proposal is to deprecate two properties, P48 has preferred identifier and 
P54 has current permanent location, following on from the conclusion of the 
discussion around the proposed property of 'has current permanent custodian' in 
issue 473.

As I recall it, the rationale for not adding 'has current permanent custodian' 
was not that the property did not make sense (it did) and not that it was not 
useful (it is), but that it was not necessary to add, as it is possible to add 
a classification to the activity that has the result of the transfer of 
custody, as to whether it is temporary or permanent.

The consequence of this was a (brief) examination of the specification for 
other properties where this pattern would be applicable, with the obvious 
deprecation candidates of P48 and P54.
The remediation pattern for P48 would be to add P2_has_type to the E41 
Identifier to indicate preferred-ness, or the E13 attribute assignment / E15 
Identifier Assignment of the identfier to the identified entity.
The remediation pattern for P54 would be to add a P2_has_type to the E9 Move to 
the location, in the same way that the resolution for 473 was to add 
P2_has_type to the Transfer of Custody.

The proposal should be considered separable -- not accepting the deprecation of 
P48 is not grounds for not accepting the deprecation of P54.

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] Propose New Issue: Guidelines and Protocols for Translating CIDOC CRM

[Massoomeh Niknia via Crm-sig]

Dear All,



Thank you George for proposing this issue. I totally agree with this
proposal. Due to our experience with translating the Model into Persian,
Omid Hodjati and I answered to your questions. Please follow this link
 to see the slides of our
answers.



I am looking forward to the discussion tonight!

Kind regards,
Massoomeh

On Wed, 3 Mar 2021 at 10:23, George Bruseker 
wrote:

> Dear all,
>
> Thanks already for your valuable feedback and uptake on this proposal. I
> am pleased to say that this issue has been added to the official CRM SIG
> issue list:
>
>
> http://www.cidoc-crm.org/Issue/ID-528-guidelines-and-protocols-for-translating-cidoc-crm
>
> It is also scheduled to be discussed in the afternoon session of the
> upcoming SIG on Monday March 8th. I do hope everyone responding here and
> all others interested in this topic will be available to share their
> knowledge and help us move this subject forward.
>
> Sincerely,
>
> George
>
> On Sat, Feb 27, 2021 at 8:50 AM Franco Niccolucci <
> franco.niccolu...@gmail.com> wrote:
>
>> Dear all,
>>
>> the appearance of this issue is the sign of the vitality, importance and
>> diffusion of the CRM.
>>
>> Undertaking a transation poses a number of issues that need to be
>> addressed before moving to practicalities.
>>
>> The “Canadian case” shows the need of complying with legal constraints.
>> For example, if a country formally decides that the national standard for
>> cultural heritage documentation is the CRM, the related decree will need to
>> have an appendix with the CRM version approved, and I think that it would
>> not be acceptable to include it in English, but it should be in that
>> country’s national official language(s). Thus it is better to have an
>> ‘approved' translation in advance, to guarantee that the ‘official’ text is
>> a faithful one. This may also resolve contractual issues, for example with
>> companies contracted to prepare heritage documentation compliant with CRM.
>>
>> On the other hand, using different translated versions of the CRM may -
>> at least in principle - undermine its universality. Even if machine
>> actionability would eventually be preserved, attention must be paid to the
>> human side of the job, to guarantee that scope notes - for example - give
>> the same meaning to labels acroos translations.
>>
>> What should be translated? Of course, the discursive part, as the
>> introduction - the pages numbered with Roman numerals in the CRM
>> description. But, they contain examples and references to Classes and
>> Properties, for which the specific rules should apply. For example, the
>> statement on page xi "In CIDOC CRM such statements of responsibility are
>> expressed though knowledge creation events such as E13 Attribute
>> Assignment and its relevant subclasses.” includes such a reference that
>> must follow the translation rules for Class names.
>> Another example is the “IsA” relationship. If translated, it contains the
>> indeterminate article “A” which in some languages must follow the
>> grammatical gender of the term it refers to, and thus gets two/three
>> equivalents. So my choice would be to consider it as a symbol and keep it
>> in English also in the translations. There may be other issues of this
>> kind, so a general directive should be 1) established 2) accepted according
>> to local constraints. I believe that the decision could be easy in this
>> particular case; but it must be decided for all the similar occurrences.
>>
>> The above leads me to think that before undertaking any translation, the
>> official English version should be examined to evaluate what is English -
>> and may be translated - and what is symbolic and just seems English - not
>> to be translated. IsA is an example, there may be others. The translation
>> may be funny from a literary point of view (“Martin Doerr IsA un homme”),
>> so an explanation could be given - maybe in a footnote - to help
>> understandability.
>>
>> Naming conventions (pages xiv - xv) should of course be preserved. Here
>> examples are given in Italic e.g. "*E53 Place. P122 borders with: E53
>> Plac*e”. I am not completely clear with the need of a full stop after
>> Place (could be a typo from copy-paste), but also the use of Italic is
>> introduced surreptitiously. By the way, it is maybe high time to establish
>> a recommendation to standardize how to quote class and property names e.g.
>> in articles, in order to distinguish them from plain discourse also
>> typographically.
>>
>> Coming to scope notes, I think that only the symbolic parts should remain
>> in English, i.e. the alphanumeric label e.g. “E1”.
>>
>> The above are just examples of what a preventive survey of the official
>> English text will define as “not translatable”. In my opinion it wouldn’t
>> take much time to fo it.
>>
>> The next step is what George calls “translation rules”. I am looking
>> forward to fierce debates about the 

Re: [Crm-sig] Issue 388 measuring position

[Hiebel, Gerald]

Dear Martin,

thanks for the feedback and pointing me to P196 relating the E18 to E92. I 
missed that one, now the Presence works fine for E18.
Looking forward the discussion,

Best,
Gerald

From: Martin Doerr 
Date: Monday, 8. March 2021 at 09:39
To: "Hiebel, Gerald" , crm-sig 
Subject: Re: [Crm-sig] Issue 388 measuring position

Dear Gerald,

Yes, this should be subclass of O21 Measurement. We need further elaboration 
about how measurements relate to the approximation of things of interest. I 
found this to be quite diverse, and adding to this class a repetition of all 
topological relations confusing. E18 still has a Presence directly related.

Best,

Martin

On 3/8/2021 10:07 AM, Hiebel, Gerald wrote:
Dear Martin and all,

thanks for taking this forward and the suggested proposition, which defines the 
process very well.

One question I have is how to relate the Position Measurement to the measured 
object (E18 or S10).
I believe the E93 Presence is the correct way for it, but we may run into a 
problem, as E18 is no longer a subclass of E92 and therefore not of E93.

For implementation simplicity a shortcut to a measured object in the form of a 
specific property would be nice, or could we use O24 measured ?
If so, should we make  Position Measurement  a subclass of O21 Measurement and 
maybe include an example that shows the modelling.

But maybe I did not see an obvious solution.
Best,
Gerald


From: Crm-sig 
 on behalf 
of Martin Doerr 
Date: Monday, 1. March 2021 at 21:31
To: crm-sig 
Subject: [Crm-sig] Issue 388 measuring position

Dear All,

I revise my previous proposal for measuring positions:



Any position measurement is based

on triangulation with multiples distances to reference points and angle 
measurements. GPS measures distances to satellites. Distances are Dimensions. 
If directed distances use georeferenced directions, i.e. angle to the rotation 
axis of earth, etc. angles

are again dimensions. Hence, a position measurement is an evaluation of a 
combination of multiple associated distance and angle measurements from a 
particular spot to certain reference points of known position in the same 
reference space. If stars are used,

they constitute (extremely) distant reference points. Gravity and Earth 
Magnetic Field also provide reference directions for angle measurements that do 
not need a second reference point. Classical longitude measurements use 
temporal simultaneity of a common

event with a reference location, which evaluates to an angle. All methods are 
fairly complex, but the details are a standard routine or even hidden in a 
modern GPS module.


Therefore

we argue that position measurement is a specific (composite) observation which 
results in a position expression, but the constituent dimensions may or may not 
be documented.

Hence,

P40 observed dimension (was observed in): E54 Dimension may not be instantiated.



All

position measurements are approximations of other places. Therefore, they 
result in a declarative place defined by an E94 Space Primitive. Since in 
general we talk about moving reference spaces, moving things and evolving 
processes, the time of measurement

is essential. We take it either to be the time-span of the measurement, or a 
narrower time-span which covers the contributing time-critical observations. In 
essence, this defines a declarative spacetime box (volume), which again is an 
approximation. It appears

to me that such an approximation would normally be used to determine parts of 
the extent of some instance of Presence by overlap, coverage or containment.


Sxxx

Position Measurement

Subclass

of:E16 Attribute Assignment

Scope

note: This class comprises activities of measuring positions in space and 
time. The measured position is intended to approximate a part or all of the 
extent of the presence (instance of E93 Presence) of an instance of E18 
Physical Thing or E4 Period of

interest, such as the outer walls of an excavated settlement, the position of a 
ship sailing or the start and end of athlete’s run in a competition. 
Characteristically, a theodolite or GPS device may be positioned on some 
persistent feature. Measuring the

position of the device will yield an approximation of the position of the 
feature of interest. Alternatively, some material item may be observed moving 
through a measured position at a given time.

A

position measurement is an evaluation of a combination of measurement of 
multiple associated distances and/or angles (instances of E54 Dimension) from a 
particular spot to certain reference points of previously known position in the 
same reference space.

Often, the observed constituting dimensions are not documented, or hidden in an 
electronic device software.The measured position is given as an E94 Space 
Primitive corresponding to a declarative place. Together with the measured 

[Crm-sig] recording of the 49th meeting for checking the minutes

[Christian-Emil Smith Ore]

Dear all,

The 49th meeting zoom meeting will be recorded for the purpose of taking 
minutes. The recordings will be deleted as soon as the minutes are completed 
and checked against the recordings.

Best,

Christian-Emil Ore

deputy chair, CRM-SIG
___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

Re: [Crm-sig] Issue 388 measuring position

[Martin Doerr]

Dear Gerald,

Yes, this should be subclass of O21 Measurement. We need further 
elaboration about how measurements relate to the approximation of things 
of interest. I found this to be quite diverse, and adding to this class 
a repetition of all topological relations confusing. E18 still has a 
Presence directly related.


Best,

Martin

On 3/8/2021 10:07 AM, Hiebel, Gerald wrote:


Dear Martin and all,

thanks for taking this forward and the suggested proposition, which 
defines the process very well.


One question I have is how to relate the Position Measurement to the 
measured object (E18 or S10).


I believe the E93 Presence is the correct way for it, but we may run 
into a problem, as E18 is no longer a subclass of E92 and therefore 
not of E93.


For implementation simplicity a shortcut to a measured object in the 
form of a specific property would be nice, or could we use O24 measured ?


If so, should we make  Position Measurement  a subclass of O21 
Measurement and maybe include an example that shows the modelling.


But maybe I did not see an obvious solution.

Best,

Gerald

*From: *Crm-sig  on behalf of Martin 
Doerr 

*Date: *Monday, 1. March 2021 at 21:31
*To: *crm-sig 
*Subject: *[Crm-sig] Issue 388 measuring position

Dear All,

I revise my previous proposal for measuring positions:



Any position measurement is based

on triangulation with multiples distances to reference points and 
angle measurements. GPS measures distances to satellites. Distances 
are Dimensions. If directed distances use georeferenced directions, 
i.e. angle to the rotation axis of earth, etc. angles


are again dimensions. Hence, a position measurement is an evaluation 
of a combination of multiple associated distance and angle 
measurements from a particular spot to certain reference points of 
known position in the same reference space. If stars are used,


they constitute (extremely) distant reference points. Gravity and 
Earth Magnetic Field also provide reference directions for angle 
measurements that do not need a second reference point. Classical 
longitude measurements use temporal simultaneity of a common


event with a reference location, which evaluates to an angle. All 
methods are fairly complex, but the details are a standard routine or 
even hidden in a modern GPS module.


Therefore

we argue that position measurement is a specific (composite) 
observation which results in a position expression, but the 
constituent dimensions may or may not be documented.


Hence,

P40 observed dimension (was observed in): E54 Dimension may not be 
instantiated.


All

position measurements are approximations of other places. Therefore, 
they result in a declarative place defined by an E94 Space Primitive. 
Since in general we talk about moving reference spaces, moving things 
and evolving processes, the time of measurement


is essential. We take it either to be the time-span of the 
measurement, or a narrower time-span which covers the contributing 
time-critical observations. In essence, this defines a declarative 
spacetime box (volume), which again is an approximation. It appears


to me that such an approximation would normally be used to determine 
parts of the extent of some instance of Presence by overlap, coverage 
or containment.


Sxxx

Position Measurement

Subclass

of:        E16 Attribute Assignment

Scope

note:     This class comprises activities of measuring positions in 
space and time. The measured position is intended to approximate a 
part or all of the extent of the presence (instance of E93 Presence) 
of an instance of E18 Physical Thing or E4 Period of


interest, such as the outer walls of an excavated settlement, the 
position of a ship sailing or the start and end of athlete’s run in a 
competition. Characteristically, a theodolite or GPS device may be 
positioned on some persistent feature. Measuring the


position of the device will yield an approximation of the position of 
the feature of interest. Alternatively, some material item may be 
observed moving through a measured position at a given time.


A

position measurement is an evaluation of a combination of measurement 
of multiple associated distances and/or angles (instances of E54 
Dimension) from a particular spot to certain reference points of 
previously known position in the same reference space.


Often, the observed constituting dimensions are not documented, or 
hidden in an electronic device software.The measured position is given 
as an E94 Space Primitive corresponding to a declarative place. 
Together with the measured time-span covering the time-critical


observations it forms a spacetime volume, which should normally 
overlap with the spatiotemporal extent of the thing or phenomenon of 
interest.


Properties:

Oxx1

determined position (was determined by): E94 Space Primitive

Oxx2

has validity time-span (is position validity for): E52 Time-Span

We

may now formulate the approximation to the things of 

Re: [Crm-sig] Issue 388 measuring position

[Hiebel, Gerald]

Dear Martin and all,

thanks for taking this forward and the suggested proposition, which defines the 
process very well.

One question I have is how to relate the Position Measurement to the measured 
object (E18 or S10).
I believe the E93 Presence is the correct way for it, but we may run into a 
problem, as E18 is no longer a subclass of E92 and therefore not of E93.

For implementation simplicity a shortcut to a measured object in the form of a 
specific property would be nice, or could we use O24 measured ?
If so, should we make  Position Measurement  a subclass of O21 Measurement and 
maybe include an example that shows the modelling.

But maybe I did not see an obvious solution.
Best,
Gerald


From: Crm-sig  on behalf of Martin Doerr 

Date: Monday, 1. March 2021 at 21:31
To: crm-sig 
Subject: [Crm-sig] Issue 388 measuring position

Dear All,

I revise my previous proposal for measuring positions:




Any position measurement is based

on triangulation with multiples distances to reference points and angle 
measurements. GPS measures distances to satellites. Distances are Dimensions. 
If directed distances use georeferenced directions, i.e. angle to the rotation 
axis of earth, etc. angles

are again dimensions. Hence, a position measurement is an evaluation of a 
combination of multiple associated distance and angle measurements from a 
particular spot to certain reference points of known position in the same 
reference space. If stars are used,

they constitute (extremely) distant reference points. Gravity and Earth 
Magnetic Field also provide reference directions for angle measurements that do 
not need a second reference point. Classical longitude measurements use 
temporal simultaneity of a common

event with a reference location, which evaluates to an angle. All methods are 
fairly complex, but the details are a standard routine or even hidden in a 
modern GPS module.


Therefore

we argue that position measurement is a specific (composite) observation which 
results in a position expression, but the constituent dimensions may or may not 
be documented.

Hence,

P40 observed dimension (was observed in): E54 Dimension may not be instantiated.



All

position measurements are approximations of other places. Therefore, they 
result in a declarative place defined by an E94 Space Primitive. Since in 
general we talk about moving reference spaces, moving things and evolving 
processes, the time of measurement

is essential. We take it either to be the time-span of the measurement, or a 
narrower time-span which covers the contributing time-critical observations. In 
essence, this defines a declarative spacetime box (volume), which again is an 
approximation. It appears

to me that such an approximation would normally be used to determine parts of 
the extent of some instance of Presence by overlap, coverage or containment.


Sxxx

Position Measurement

Subclass

of:E16 Attribute Assignment

Scope

note: This class comprises activities of measuring positions in space and 
time. The measured position is intended to approximate a part or all of the 
extent of the presence (instance of E93 Presence) of an instance of E18 
Physical Thing or E4 Period of

interest, such as the outer walls of an excavated settlement, the position of a 
ship sailing or the start and end of athlete’s run in a competition. 
Characteristically, a theodolite or GPS device may be positioned on some 
persistent feature. Measuring the

position of the device will yield an approximation of the position of the 
feature of interest. Alternatively, some material item may be observed moving 
through a measured position at a given time.

A

position measurement is an evaluation of a combination of measurement of 
multiple associated distances and/or angles (instances of E54 Dimension) from a 
particular spot to certain reference points of previously known position in the 
same reference space.

Often, the observed constituting dimensions are not documented, or hidden in an 
electronic device software.The measured position is given as an E94 Space 
Primitive corresponding to a declarative place. Together with the measured 
time-span covering the time-critical

observations it forms a spacetime volume, which should normally overlap with 
the spatiotemporal extent of the thing or phenomenon of interest.

Properties:

Oxx1

determined position (was determined by): E94 Space Primitive

Oxx2

has validity time-span (is position validity for): E52 Time-Span

We

may now formulate the approximation to the things of interest, e.g.


Oxx3

overlaps with presence: E93 Presence.


But

the time=span of this presence is already implicit in the time-span of validity.


If

we use:


Oxx3

overlaps with presence of: , we need a property for E18 and another for E4…


Another

use case is when someone wants to determine if she is at a particular 
declarative place: Fisherman now mark positions in the sea with GPS, in order 
to return