Re: [Crm-sig] Issue 519, use of "preferred identifier" and "current permanent location"

[Robert Sanderson via Crm-sig]

yes to deprecating both properties.

preference is both context specific, and a classification of an identifier
in that context, not a globally true relationship.

Permanent location has the same problem as permanent custodian, which was
not approved as a relationship at a recent SIG - its a function of intent
and movement, like custodian is of intent and custody.

Rob



On Thu, Oct 12, 2023, 4:12 PM Martin Doerr via Crm-sig 
wrote:

> Dear All,
>
> Since it is on tomorrow's agenda to deprecate or not "preferred
> identifier" and "current permanent location", I'd suggest an e-vote,
> if the meeting tends to deprecation, because basically the question
> remains if these are used or not. The latter is a question to a wider
> audience.
>
> 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
>
___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

Re: [Crm-sig] Issue: Completing the list of shortcuts in CRMbase

[Robert Sanderson via Crm-sig]

In Linked Art we avoid the use of shortcuts unless we are *never* going to
use the full path. Otherwise every query and piece of code needs to check
for both patterns which adds complexity for no value. So ... I agree with
those reviewers, from a "don't do that then" point of view! :)

Rob



On Wed, Oct 4, 2023 at 7:10 AM Christian-Emil Smith Ore via Crm-sig <
crm-sig@ics.forth.gr> wrote:

>
> Not necessarily new issues for each extension. But as an afterthought,
> this will be the best and keep the process(es) tidy.. Also, the the
> discussion about possible new shortcuts, strong etc. are mostly interesting
> for the geeks among us (including me). For the rest, this issue may be
> considered to be not close to their interests and everyday use of CRM.  If
> I remember correctly some of the reviewers of CRM in the early 2000s,
> suggested that every path could be shortcuted.
>
> Best,
>
> C-E
>
>
> --
> *From:* Crm-sig  on behalf of Schmidle,
> Wolfgang via Crm-sig 
> *Sent:* 04 October 2023 11:42
> *To:* crm-sig@ics.forth.gr
> *Subject:* [Crm-sig] Issue: Completing the list of shortcuts in CRMbase
>
> Dear All,
>
> P81 "ongoing throughout" and  P82 "at some time within" are strong
> shortcuts, but not yet marked as such:
>
> E52 Time-Span P81 ongoing throughout E61 Time Primitive
> E52 Time-Span P86i contains E52 (Declarative) Time-Span P170i time is
> defined by E61 Time Primitive
> P81(x,y) ⇔ (∃z) [E52(z) ∧ P86i(x,z) ∧ P170i(z,y)]
>
> E52 Time-Span P82 at some time within E61 Time Primitive
> E52 Time-Span P86 falls within E52 (Declarative) Time-Span P170i time is
> defined by E61 Time Primitive
> P82(x,y) ⇔ (∃z) [E52(z) ∧ P86(x,z) ∧ P170i(z,y)]
>
> Christian-Emil suggested opening an issue for completing the list of
> shortcuts in CRMbase, and to create a separate issue for the extensions
> whenever necessary.
>
> Best,
> Wolfgang
>
>
> ___
> 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
>


-- 
Rob Sanderson
Senior Director for Digital Cultural Heritage
Yale University
___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

Re: [Crm-sig] Issue 604: Make SIG meetings more sustainable

[Robert Sanderson via Crm-sig]

I would add ...

3) Stick to the published agenda. I've stopped attending meetings as it's
impossible to know when the topics will be discussed.

Rob



On Wed, Aug 23, 2023 at 9:08 PM Athanasios Velios via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear all,
>
> Just following up with this discussion following Eleni's reminders for
> HW. I think we have relaxed into the pattern of two hybrid meetings per
> year, which is a reasonable compromise while there are still regular
> participants who can cover their travel expenses.
>
>  From the discussion so far it seems that at the moment linking the SIG
> meetings with other conferences may not be a preferred option.
>
> I am happy with the hybrid meetings provided that we make a bit of an
> effort in terms of the audio/visual setup. I.e. sometimes online
> participants are side-lined in the discussion as "less" present in the
> "room".
>
> Some proposals to consider:
>
> 1) We should make decent conference microphones a requirement for
> hosting institutions so that online participants can hear all
> discussions in the room without having to interrupt and request speakers
> to repeat (and someone in the room having to move the mic, etc.).
>
> 2) In the physical room, we should have two screens connected to the
> machine running zoom, one screen with the faces of the online
> participants and another screen for screen sharing. Zoom supports this
> kind of setup.
>
> If these make sense and they are not too demanding requirements, then
> maybe we can accept them and close this issue for now.
>
> All the best,
>
> Thanasis
> ___
> Crm-sig mailing list
> Crm-sig@ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>


-- 
Rob Sanderson
Senior Director for Digital Cultural Heritage
Yale University
___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[Robert Sanderson via Crm-sig]

If the intent is that the assertion is in the discourse, and not a
syntactic workaround for .1 properties that would be unnecessary if we had
RDF* or property graphs, then I would say E13 is exactly the right approach
to use. In comparison, I consider the PC classes to be just that - a
syntactic work around needed in RDF and not part of the discourse. In
LInked Art, in a discussion around uncertain attribution of artists and
"style of" vs "school of", we posited the need for a property on E13 for
this scenario. (Also the need for .1 on P11 for the same reason as we have
it on P14)

I would say that Dig's annotation is *not* the correct approach for several
reasons:
* Named Graphs are a very specific technology that have never seen
significant uptake and are likely (IMO) to decrease in usage once RDF* is
formalized.
* Dig needs to be updated, and Annotation is (I would hope) likely to go
away ... because ...
* ... it could just use the Web Annotation Data Model:
https://www.w3.org/TR/annotation-model/

(And reification has all the problems discussed in this thread already)

Rob


On Thu, May 11, 2023 at 7:17 AM George Bruseker via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear Martin,
>
> I agree that E13 is a poor man's solution to a complicated problem. But it
> is for some, the solution available. Other solutions like Inf for
> documenting historical argumentation and using named graphs is great as a
> possibility. Using prov o to represent the meta discursive level of the
> provenance of the dataset as such great. But my immediate interest was
> simple the humble ability of E13 to be able to point to all statements that
> can be made with precisely one link in CRM.  I'll keep watching the space!
>
> Cheers,
>
> G
>
> On Thu, May 11, 2023 at 1:25 PM Martin Doerr  wrote:
>
>> Dear George,
>>
>> I agree with you below about the historical aspects. The annotation model
>> has the same historical aspect, but is not limited to a single link.
>>
>> Let us discuss!
>>
>> Best,
>>
>> Martin
>>
>> On 5/11/2023 12:41 PM, George Bruseker wrote:
>>
>> Dear Francesco, Martin,
>>
>> Again for the record since I seem to be being read at cross purposes,
>> when I mention the word 'provenance' I do not mean it in the sense of
>> dataset provenance (to which prov o would apply). I mean that in the world
>> to be described (the real world of tables charis cats dogs scholars ideas
>> etc.) there are real world events in which people attribute things to
>> things (see my previous email). This is content of the world to be
>> represented in the semantic graph (not a metagraph about the graph). This
>> is describable and is described in CIDOC CRM using E13 and its friends. If
>> you want to say that there was a historical situation that someone in your
>> department said (likely in the information system) that some attribute
>> related two things you can do this with E13 (or I have
>> completely misunderstood the CIDOC CRM). This happens all the time in art
>> history. One particular often arising case is an argument about who played
>> what role in some object. Was Davinci the painter or was it Simon? This is
>> just a hum drum case of needing to apply CIDOC CRM to real cases. Since E13
>> is a mechanism for so doing on all other statements, it would be a logical
>> continuation that it could be used also on .1 statements. But for technical
>> reasons it cannot, that is why I suggested a mild technical solution that
>> makes the technical extension logically coherent. It is in this sense that
>> I mean provenance and not in the metasense of the provenance of the data
>> qua data, also an exciting but other issue to my mind.
>>
>> Cheers,
>>
>> George
>>
>> On Thu, May 11, 2023 at 12:27 PM Martin Doerr via Crm-sig <
>> crm-sig@ics.forth.gr> wrote:
>>
>>> Dear Francesco,
>>>
>>> This is an excellent paper.
>>>
>>> I cite: "However, reification has no formal semantics, and leads to a
>>> high increase in the number of triples, hence, it does not scale well. "
>>>
>>> I agree with your proposals. Prov-O mapping is a must for CRM-SIG.
>>>
>>> Best,
>>>
>>> Martin
>>>
>>> On 5/10/2023 11:55 PM, Francesco Beretta via Crm-sig wrote:
>>>
>>> Dear Martin, George, All,
>>>
>>> I would not dare to suggest some solution of this complex issue but let
>>> me hint to a couple of useful papers (among many others):
>>>
>>> Sikos, Leslie F., and Dean Philp, ‘Provenance-Aware Knowledge
>>> Representation: A Survey of Data Models and Contextualized Knowledge
>>> Graphs’, *Data Science and Engineering*, 5.3 (2020), 293–316 <
>>> https://doi.org/10.1007/s41019-020-00118-0>
>>>
>>> Hernández, Daniel, Aidan Hogan, and Markus Krötzsch, ‘Reifying RDF: What
>>> Works Well With Wikidata?’, in *Proceedings of the 11th International
>>> Workshop on Scalable Semantic Web Knowledge Base Systems Co-Located with
>>> 14th International Semantic Web Conference (ISWC 2015), Bethlehem, PA, USA,
>>> October 11, 2015.*, 2015, pp. 32–47 <
>>> 

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[Robert Sanderson via Crm-sig]

Perhaps for the first time, I agree with Martin and not George!

The PC classes are part of the ontological layer -- we don't say that
classes or properties are descendants of E1. Or PC classes are T box
(terminology) and not A box (assertions using that terminology).
(See - https://en.wikipedia.org/wiki/Abox)

I can see, however, that it would be useful to be able to refer to
assertions in CRMInf and perhaps in Activity templates ... but then those
assertions _are_ A box - the are the subject of the discourse, not the
language in which the discourse is taking place.  We have Attribute
Assignment to talk about important activities that assert relationships or
properties. And if we don't want to go to that layer of A box layer
reification, then we have the partitioning pattern -- to assert a role of a
particular individual in an activity, we can identify the part of that
activity that the person carried out and assert a role classification on it
via P2_has_type.

Rob


On Mon, May 8, 2023 at 9:44 AM Martin Doerr via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear All,
>
> I don't think it is correct to make the PC classes entities. Even though
> formally an RDF class could be regarded as an entity, ontologically we
> distinguish entities and relationships. The E-R paradigm makes this
> distinction also formally clear. We model the properties with .1 properties
> in FOL as n-ary relationships, and not as individuals.
>
> Making the PC classes CRM Entities is inconsistent with the FOL
> definition, which is the proper formalization.
> In other words, we would make a workaround for a missing feature in RDFS
> an ontological argument. We are again in the discussion to take RDFS as the
> definition of the CRM, and not as an implementation.
>
> As a first step, we could introduce an "E0 CRM Relation", which would have
> as instances all properties and the PC classes. The ontological distinction
> between relations and entities is fundamental to the methodology of
> ontological analysis.
>
> As a second step, we can start to investigate to which degree PC classes
> qualify as ontological individuals in their own right. If we start
> declaring a priori all PC classes as entities, we have later to justify and
> remove all those that are relations in the true sense.  For instance, I
> cannot imagine the "being part of" a Physical Object for some time to
> become an entity, because it needs a timespan.
>
> Best,
>
> Martin
>
> On 5/8/2023 12:54 PM, George Bruseker via Crm-sig wrote:
>
> Hi all,
>
> I would argue that the safest thing to do is to make the PCs a subclass of
> E1 and then see where we go from there. I agree with Martin that it can't
> be an information object (because everything would be then) but I imagine
> we would have a debate about what each .1 actually ontologically is. What
> is certain is that by virtue of the fact of being something said in the
> universe of CIDOC CRM it is something sayable / mentionable. This is what
> E1 gives us, the most vague point of an object that can be pointed to and
> named, possibly classified. The problem is right now that we have something
> that is sayable in CIDOC CRM (PCxxx) but it is not referenceable. But this
> is a logical contradiction. Everything that can be said can be referenced
> and PCxxx can definitely be said.
>
> For example, if I say that Bob was involved in the Production of Mona Lisa
> as Creator then this is something said / stated that is important, that has
> a real world referent, which has a definite meaning which is true or false
> etc. Ergo, it requires provenance. The basic mechanism for provenance in
> CRMbase is E13 and indicates that there was an agency behind something
> being asserted of something else.
>
> Here the thing we want to talk about is the role and the role IS an
> instance of PC14. It's already an instance of a class so it should be
> referenceable. (Also one might like to put a bibliography for people who
> thought that Bob was Creator of Mona Lisa etc.)
>
> So I would go exactly for Paulos' modelling but with this change:
>
> :painting_sistine_chapel
>  crm:P01i_is_domain_of :role_of_michaelangeo_in_sistene_chapel_project
>
> :role_of_michaelangeo_in_sistene_chapel_project
>a crm:PC14_carried_out_by ;
>crm:P02_has_range :Michelangelo  ;
>crm:P14.1_in_the_role_of  :master_craftsman .
> :attrAssign1
>a crm:E13_Attribute_Assignment ;
>crm:P140_assigned_attribute_to
> :role_of_michaelangeo_in_sistene_chapel_project
>... ... ...
>
>
> On Mon, May 8, 2023 at 10:42 AM athinak  wrote:
>
>> Dear George, all,
>>
>>   I am not sure that the class PC0_Typed_CRM_Property should be a
>> subclass of E1. In my understanding, this class implies a situation
>> concluded in an epistemological context. I am also not sure if the
>> provenance we are looking for in this set of statements is a kind of
>> E13. I am just wondering.
>>
>> BRs,
>> Athina
>>
>>
>>   On 2023-03-29 16:36, George Bruseker via Crm-sig 

Re: [Crm-sig] Issue 624, linguistic Appellation

[Robert Sanderson via Crm-sig]

While this is interesting, the issue is not to re-engineer names and
languages from first principles. There is an existing class,
E33_E41_Linguistic_Appellation, which is in use in many projects and
products around the world. The issue, as raised by George, is that it is
thought that it would be better for this class to have documentation
outside of the RDFS document that defines it technically.

There are two possible outcomes of this issue:
1. It is agreed that there should be human-intended documentation for the
class, and then that documentation gets written for
E33_E41_Linguistic_Appellation.
2. It is not agreed that there should be human-intended documentation for
the class, and documentation gets written outside of CIDOC-CRM.

Rob


On Fri, Dec 16, 2022 at 5:05 AM Francesco Beretta via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear Martin, Rob,
>
> If we consider the intended phenomenon in reality, we can observe (through
> everyday experience or documentation) that humans use names for identifying
> things. Insofar as humans live in cultural contexts, and these are realized
> through languages, these names are in some way related to, or valid in
> different languages.
>
> If we stick to the ontological substance of E41 Appellation, we can
> observe that people can use the "The Big Apple" appellation to identify
> New York City even in sentences expressed in other languages than English,
> and possibly without even understanding the meaning of this expression.
>
> This phenomenon, which occurs on Earth in billions of instances at every
> moment, can be expressed, or has been expressed in the context of CIDOC CRM
> in three ways:
>
>- in using frbroo:F52 Name Use Activity
> which, as a subclass of crm:E7
>Activity , captures the
>information about the dynamic of human groups in space and time and thus in
>a linguistic context. One could interpret sdh:C11 Appellation in a
>Language  in this sense and
>add a property situating the activity in a linguistic context
>- in using LRM Nomen as Martin proposes. The concerned propositional
>object captures the *intentional conten*t (as social philosophers
>would say) of the belief that this appellation is validly usable, i. e.
>understandable in this language in order to identify a thing
>- in using sdh:C11 Appellation in a Language
> as it was originally
>modelled in a social perspective, i.e. as a subclass of Intentional State
>or State of Mind, situating in a temporal region (as temporal phenomenon)
>the fact that a thing is considered as being validly named with this
>appellation in a linguistic and social context. This is the perspective of
>CRMsoc with a domain that complements CRMbase from the 'inside' perspective
>(in the sense of intention carryied in the *individual* minds) and
>(indirectly) through observable phenomena and documentation. Therefore not
>a State as alternative to Event (in the same CRMbase domain) but something
>else, a sort of quality of the minds of the believers —a state of mind— of
>the LRM Nomen instance.
>
>
> This said, one can consider the property crm:P1 is identified by
> (identifies)  as a shortcut
> and abstraction of this phenomenon, regardless of the ways of expressing it
> summarized above, relating the *intended entity* with an *appellation* of
> it.
>
> In the same perspective of abstraction and simplification, and in my
> opinion as a robust way, without adding subclasses of Persistent Item which
> risks to be cumbersome and their substance not well defined and
> rigid/disjoint, I'd be in favor, as already expressed, of adding an
> additional property:
>
> E41 Appellation --> P... is used in --> E56 Language
>
> as a shortcut of another aspect of  sdh:C11 Appellation in a Language
>  (without engaging for the
> moment in defining what this class is)
>
>
> This solution seems to cope with the problem and brings the information to
> the conceptual model in a concise and stringent way, without engaging in
> the ontological discussion about the language in which an appellation *is*
> (was it created in this language? is it used as such? etc. etc.).
>
> The substance of the property, given all the examples you brought, seems
> to be quite clear: the property expresses the observable fact (in
> documentation and every day life) that an appellation is used in a language
> (by an intentional community or society — not necessarily a group with
> potential of acting together) as a valid identifier of an entity.
>
> Best
> Francesco
>
>
> Le 15.12.22 à 20:38, Martin Doerr via Crm-sig a écrit :
>
> Dear Robert,
>
> On 12/15/2022 4:57 PM, Robert Sanderson wrote:
>
>
> This doesn't meet the 

Re: [Crm-sig] Issue 624, linguistic Appellation

[Robert Sanderson via Crm-sig]

This doesn't meet the requirements, unfortunately.

sdh:C11 is a temporal entity -- the state of being named something -- and
not a name itself. While interesting, as previously States have been widely
decreed as an anti-pattern to be avoided, it does not meet the requirements
set forth for E33_E41, which is that an Appellation itself can have a
Language.

So I believe that this does not solve the problem as stated - that
E33_E41_Linguistic_Appellation does not have a description outside of the
RDFS document.

Rob


On Wed, Dec 14, 2022 at 3:54 PM Martin Doerr via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear Francesco, dear George,
>
> After the discussion in the last CRM SIG meeting, I propose to follow
> Francesco's "sdh:C11 Appellation in a Language
>  class." as *a longpath for P1*.
>
>
> I propose to generalize the context. It could be a language, it could be a
> country, a Group. I propose to analyze, if this can be mapped or identified
> with LRM Nomen and its properties. It can further be made compatible with
> the RDF labels with a language tag, which are domain instance specific and
> not range specific, and of course can represent the TGN language
> attributes. For VIAF, we would need a "national" context, i.e., the
> national library.
>
> Best,
>
> Martin
>
>
>
>
>
> On Sat, 12 Nov 2022, 2:43 pm Francesco Beretta via Crm-sig, <
> crm-sig@ics.forth.gr> wrote:
>
>> Dear Martin, all
>>
>> Sorry to intervene so late in this interesting exchange, I was away for
>> some days and I'm going through my emails now.
>>
>> I encountered the same questions while working a few years ago in a
>> history project interested in the evolution of the use of names and
>> surnames.
>>
>> The approach of the project was similar to the one presented by Martin
>> below and amounted to saying that it is difficult to state to which
>> language a first name, or surname, belongs in itself, except for some cases
>> or if we consider the region of origin, but what is relevant is that this
>> specific string of characters is used at a given time (and attested in the
>> sources) in a language or in another (i.e. in a society speaking this
>> language) to identify a person or an object.
>>
>> To capture the information envisaged in the project in the sense of this
>> approach I decided to stick to the substance of crm:E41 Appellation class:
>>
>> "This class comprises signs, either meaningful or not, or arrangements of
>> signs following a specific syntax, that are used or can be used to refer to
>> and identify a specific instance of some class or category within a certain
>> context. Instances of E41 Appellation do not identify things by their
>> meaning, even if they happen to have one, but *instead by convention,
>> tradition, or agreement*." (CRM 6.2).
>>
>> and to add in what has become the SDHSS CRM unofficial extension the sdh:C11
>> Appellation in a Language 
>> class.
>>
>> This class has as you'll see a clear social, i.e. intentional flavor, and
>> captures the information that some appellation is considered as a valid
>> appellation of a thing in a language (i.e. society speaking his language)
>> during an attested time-span.
>>
>> This was also an attempt to cope with the frbroo:F52 Name Use Activity
>> issue:
>>
>> 413 Pursuit and Name Use Activity to CRMsoc
>> 
>> 573 CRMsoc & F51 Pursuit & F52 Name Use Activity
>> 
>>
>> which is somewhat slowed down by the ongoing exchanges around the nature
>> and substance of the social world as foundation of the CRMsoc extension.
>>
>> But one could easily provide another substance to an *Appellation in a
>> Language* class making it a Name Use Activity (in a Language) class (and
>> subclass of crm:E13 Attribute Assignment
>>  or crm:E7 Activity).
>>
>> This would be in my opinion a good way of coping with the wish expressed
>> by George at the beginning of this exchange to "make [this kind of classes]
>> full classes in the standard so that they are fully vetted and controlled.
>> It is a fundamental class. It should be in the standard in the first
>> place", wish that I definitely share. And also to stick, as far as I can
>> understand, to the modelling principles reminded by Martin.
>>
>> And it would also finally solve the issues still open, to my knowledge,
>> concerning the original FRBR-oo class.
>>
>> Best
>>
>> Francesco
>>
>>
>>
>>
>>
>>
> --
> 
>  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
>  

Re: [Crm-sig] error in RDFS for 7.1.1 for the class that is a subclass of E41 and E33

[Robert Sanderson via Crm-sig]

Hi Martin,

No one is proposing anything other than P72. Please stop creating issues
where none exist :)

"The Big Apple" is a name for the Place which is also known as "New York
City".
Does anyone disagree that "The Big Apple" is in English with the precise
semantics of P72, or that it is not a Name for that Place?

Rob


On Thu, Nov 10, 2022 at 1:31 PM Martin Doerr via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear Gordon,
>
> "The Library of Congress has only recently stopped assigning gender to the
> referant of a name",
>
> That is interesting!
>
> I'd kindly ask for your expert opinion, about the "language" of a name.
>
> We had introduced the language property of a title because of the frequent
> cases of words of a natural language and their translations.
>
> Here, my question is:
>
> A) In library practice, do you associate a name with a language, and what
> would be the rules.
>
> George wrote: "He has a transliterated name: Abū l-Walīd Muḥammad Ibn
> ʾAḥmad Ibn Rušd . Is that his name in Arabic or English or no language? I
> don't know. Both? Maybe. I'm not a scholar of philosopher's names and it's
> not my province to judge. This is not the domain of the ontologist but the
> specialist in onomastics or the appropriate discipline. "
>
> I absolutely disagree with that. Can transliteration to another script
> change and produce a language-specificity? That is definitely an
> ontological question. Otherwise, we have no concept at all for this
> property.
>
> My example of Joshua had another purpose: The spelling and pronunciation
> "Josua" is the one used in German, but not exclusively. "Joshua" in English
> (and?), may be Yeshua  in Hebrew
> written in Latin script? If this is the case, they are variants shaped and
> used in different language groups. That would justify a
> language-specificity.
>
> B) If the meaning of the language property we are seeking for is not the
> language of the name, but the suitable use in a language group of the name
> for the named instance, then, it is a subproperty of P1 and not P72. Such
> as "is typically identified in English by...etc. That *is *an ontological
> question.
>
> All the best,
>
> Martin
>
> On 11/10/2022 1:21 PM, Gordon Dunsire wrote:
>
> All
>
> A librarian expresses an initial opinion:
>
> What about gender of a name? E.g. "Gordon" is male; "Gordana" is female.
> The Library of Congress has only recently stopped assigning gender to the
> referant of a name, which has resulted in howlers like "Robert Galbraith"
> (pseudonym of J.K. Rowling) is a male because the name is 'male'.
>
> RDA: resource description and access is an implementation of the IFLA
> Library Reference Model (entity-relationship version). Names and titles are
> given equal treatment; the only difference between a 'name' and a 'title'
> is that 'title' is the traditional word for the 'name' of an information
> resource. Since LRM/RDA has four 'resource entities', we have 'title of
> work', 'title of expression', 'title of manifestation', and 'title of
> item'; all other entities have 'name": 'name of place', 'name of
> time-span', 'name of agent', etc.
>
> This discussion exposes a further difference, but it is not absolute. A
> 'title' is usually composed of words, etc. taken from a natural language:
> "Ceci n'est pas une pipe" uses French words; "The treachery of images" uses
> English words; "La trahison des images" is back to French; "The wind and
> the song" is back to English ... On the other hand, a 'name' is usually
> composed of words, etc. that have no other use in natural language. But
> there are many counter-examples, and the distinction may not exist in a
> specific language group (e.g. Chinese?).
>
> Although RDA has a property for 'has language of nomen' ('nomen' being the
> generic term for 'name/title', 'access point', and 'identifier'), the
> expectation is that it only has utility for 'title', but not 'name'.
>
> The sibling property 'has script of nomen' has utility for names and
> titles. It is important for transliterations.
>
> On 09/11/2022 20:02 GMT George Bruseker via Crm-sig 
>  wrote:
>
>
> Dear Martin,
>
> I don't see an ontological problem here. One name can be used by / in many
> languages. If it is, that can be documented.
>
>
>
> The question was not if names can belong to language, or if langauges
> create names. It was how this is unambiguously defined.
>
>
> It isn't our job as ontologists to unambiguously define the instances of
> things in the world. This is for the domain specialists.
>
>
>
>
> The example below is what I feared. The fact that the arabic script is
> mainly used for Arabic, does itr make a *transcript *of an English name
> "Arabic?" why not Farsi?  I ask here for the Librarians to express their
> opinion.
>
>
> Who documents the object, documents their knowledge and, hopefully,
> thereby, the state of affairs in the world.
>
> I don't understand the Farsi aspect of the above question. 

Re: [Crm-sig] error in RDFS for 7.1.1 for the class that is a subclass of E41 and E33

[Robert Sanderson via Crm-sig]

Unsurprisingly, I agree with George.

The quantification of P72 has language is many to many, necessary.

Meaning that a Linguistic Object can have many languages, and each Language
can be the language of many Linguistic Objects.

So, if you wanted to say that my name is "Robert Sanderson", and that Name
P72_has_language English and the same entity P72_has_language French ... no
problem. That they are pronounced differently in those two languages
(Roh-bit vs Roe-bear) is interesting, but not a symbolic (nor
propositional) concern.

Combined with the open world assumption, saying that my name is "Robert
Sanderson" in English and French doesn't preclude it from also being the
symbolic representation of my name in German or Dutch.

So per George's response, I think there's no philosophical issue. Per mine,
there's no technical issue. And per previously, there's no scoping /
inclusion logistics issue.

I assume the next step is to propose a scope note and formal definition?

Rob


On Wed, Nov 9, 2022 at 3:10 PM George Bruseker via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear Martin,
>
> I don't see an ontological problem here. One name can be used by / in many
> languages. If it is, that can be documented.
>
>
>> The question was not if names can belong to language, or if langauges
>> create names. It was how this is unambiguously defined.
>>
>
> It isn't our job as ontologists to unambiguously define the instances of
> things in the world. This is for the domain specialists.
>
>
>>
>>
>> The example below is what I feared. The fact that the arabic script is
>> mainly used for Arabic, does itr make a *transcript *of an English name
>> "Arabic?" why not Farsi?  I ask here for the Librarians to express their
>> opinion.
>>
>
> Who documents the object, documents their knowledge and, hopefully,
> thereby, the state of affairs in the world.
>
> I don't understand the Farsi aspect of the above question. Why
> would transliterating a name into English from Arabic make it Farsi?
> Librarians?
>
> Here's a person with a name: https://en.wikipedia.org/wiki/Averroes
>
> His name is ابن رشد in Arabic and also أبو الوليد محمد ابن احمد ابن رشد.
>
> With E33_E41 we can say that. Without it, we can't.
>
> His name in English is usually Averroes and also he is known as Ibn Rushd.
>
> With E33_E41 we can say that. Without it, we cant.
>
> He has a transliterated name: Abū l-Walīd Muḥammad Ibn ʾAḥmad Ibn Rušd .
> Is that his name in Arabic or English or no language? I don't know. Both?
> Maybe. I'm not a scholar of philosopher's names and it's not my province to
> judge. This is not the domain of the ontologist but the specialist in
> onomastics or the appropriate discipline.
>
>
>
>>
>> Why is Douglas Adams not "German"? I would use it in German exactly in
>> this form.
>>
>
> Then put in the KB for this name 'has language English' and 'has language
> German' and the problem is solved.
>
>
>>
>>
>> But "Adams" I  think is a last name exclusive to English, as Dörr to
>> German.
>>
>> What is the language of "Martin", "Martino",  of
>>
>> Martin: Identical in English, Spanish, French, Dutch, German, Norwegian,
>> Danish, Swedish?
>>
>
> If that is what the expert in onomastics thinks, yes. Not an ontological
> issue. We provide the semantic framework, they do the researching.
>
>
>> Martino in Italian, Rumanian?
>>
>> From Wikipedia: "Joshua".
>>
>> *Josua* or *Jozua* is a male given name and a variation of the Hebrew
>> name Yeshua .[1]
>> [2]
>>  Notable people with
>> this name include:
>>
>>- Josua Bühler 
>>(1895–1983), Swiss philatelist
>>- Josua de Grave 
>>(1643–1712), Dutch draughtsman and painter
>>- Josua Harrsch 
>>(1669–1719), German missionary
>>- Josua Hoffalt  (born
>>1984), French ballet dancer
>>- Josua Järvinen 
>>(1871–1948), Finnish politician
>>- Josua Koroibulu 
>>(born 1982), Fijian rugby league footballer
>>- Josua Heschel Kuttner
>> (c. 1803–1878),
>>Jewish Orthodox scholar and rabbi
>>- Josua Lindahl 
>>(1844–1912), Swedish-American geologist and paleontologist
>>- Josua Maaler 
>>(1529–1599), Swiss pastor and lexicographer
>>- Josua Mateinaniu  (
>>fl. 1835), Fijian missionary
>>- Josua Mejías 
>>(born 1997), Venezuelan footballer
>>- Johann Josua Mosengel
>> 

Re: [Crm-sig] error in RDFS for 7.1.1 for the class that is a subclass of E41 and E33

[Robert Sanderson via Crm-sig]

To re-merge the threads, apologies for the duplication...

The language of an E33_E41 is the language in which the linguistic content
of the entity is expressed, per P72_has_language.

For example,

The language of the name of Douglas Adams (the Person) that has the
symbolic content of "Douglas Adams" is English.
The language of the name of Douglas Adams (the Person) that has the
symbolic content of "دوغلاس آدمز" is Arabic.

These are clearly expressed in a language, and appellations, and symbolic.

Or:

eg:Q42 a crm:E21_Person ;
  crm:P1_is_identified_by [
a crm:E33_E41_Linguistic_Appellation ;
P190_has_symbolic_content "Douglas Adams" ;
P72_has_language  ]
  crm:P1_is_identified_by [
a crm:E33_E41_Linguistic_Appellation ;
P190_has_symbolic_content "دوغلاس آدمز" ;
P72_has_language  ]

E33_E41 is a super-class of E35, which is semantically narrower through its
scope note as applying only to "works", and "can be clearly identified as
titles due to their form". I don't think anyone would say that "Douglas
Adams" is the "title" of the person.

Rob

On Wed, Nov 9, 2022 at 9:05 AM Martin Doerr via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear All,
>
> I would like to focus on the semantic questions wrt E33_E41. Would it be
> well defined? Please remember, that there were implementation arguments
> against multiple instantiation, not semantic ones. Therefore, we decided
> to solve the problem in the implementation side. Why the unlucky choice
> of two different labels now would warrent a deeper semantics is not
> clear to me. We can solve the issue by deciding a label.
>
> If there are possibly deeper semantics, as I indicated in my last
> message, could we specify this?
>
> Is the language of an E33_E41 a created within, made for, used by? Is it
> language or language speakers? What substance makes an Appellation
> "languageable"?
>
> Can someone take a position? If this stays unclear, I vote for the
> current solution.
>
> Cheers,
>
> Martin
>
> On 11/9/2022 10:46 AM, athinak via Crm-sig wrote:
> > Dear all,
> >
> > I fully agree that we must follow the principles of the ontology
> > development and remove classes that do not fulfil the criteria of
> > being classes in CRM Base. But, in my opinion, for specific classes of
> > this kind (that they seem not to fulfill the criteria because they
> > don't have properties ), such as Inscription, we should make an issue
> > not to delete, but to discuss the alternatives of removing this class
> > and maybe to remember the initial purpose of use of this class or to
> > find if there is an open issue regarding this - For E34, there is the
> > issue 533; So, my question is: what about the classes that we have
> > introduced in CRM base or in other compatible models, such as S7
> > Simulation or S5 in sci, which have no properties at all, but, as I
> > remember very well, the argument for introducing them (I am speaking
> > for sci) was that that they are domain specific but we haven't yet
> > developed them, but we intend to do so in future. - should we delete
> > them? E34 has not been developed, in my understanding, and it is now
> > replaced by CRM tex. So the issue , in my opinion, should be (for this
> > class)  how we sychronize and not delete.
> >
> > BRs,
> >
> > Athina
> >
> > On 2022-11-08 23:25, Mark Fichtner via Crm-sig wrote:
> >> Dear all,
> >>
> >> while I must agree with Rob that the three classes he proposed for
> >> deletion are not a particular best pratice in ontology building from a
> >> semantic point of view, I don't feel good with the direction the CRM
> >> is going currently. At our museum we are following the CRM because it
> >> is the only "really standardized" standard for our domain. It is
> >> expressive enough for a full top level ontology while also covering
> >> the domain of cultural heritage. We are not interested in yet another
> >> standard that maps metadata in a very common way - we have enough of
> >> these and if we would want to use dublin core we would do so. The full
> >> potential of the CRM is what binds us to using it.
> >>
> >> Concepts like "Title" are really important for our domain - it is one
> >> of the most important metadata fields for documentation in our museum.
> >> With the abolishment of properties and classes in CRM Base that were
> >> used a lot in the past the SIG and the CRM takes a turn away from the
> >> museum side of documentation towards being a very general ontology.
> >> While I know development may always hurt a little bit, this does not
> >> feel right in any way anymore.
> >>
> >> I am asking myself: Is this really what the CIDOC CRM should do? Is it
> >> possible for the CIDOC CRM to survive in comparison to standards that
> >> are more widely spread while abolishing it's own user base? Do we
> >> really want a domain ontology - extending CRM Base called "CRM Museum
> >> Documentation Ontology" because we throw out everything that is museum
> >> related out of CRM Base? 

Re: [Crm-sig] New Issue: Delete E35 Title

[Robert Sanderson via Crm-sig]

The issue in question is 340:
https://cidoc-crm.org/Issue/ID-340-classes-without-properties

Discussed at SIG meetings 39, 41, and 43.

Whereby the classes in question were kept under this clause:

It can be useful as a leaf class (i.e. at the end of a CRM branch) to
domain communities building CRM extensions or matching key domain classes
from other models to the CRM (e.g. E34 Inscription).


I propose that being able to Name things with a Linguistic Appellation that
is not an E35 Title is critically important to all domain communities and
matches classes from other models. People, Places, Concepts and many other
fundamental entities have Names in languages which are not Titles.

Therefore it falls within the scope of CRM Base.

The substance of the class is that humans name specific instances with
different names in different languages. The Name is expressed in a
Language, exactly in the same way as other uses of P72. If E33_E41 doesn't
have substance, then I find it hard to see how E35 is substantive either --
E35 is a more restrictive version of E33_E41 through its scope note, as can
be seen by the identical super-classes.

Rob


On Wed, Nov 9, 2022 at 8:59 AM Martin Doerr via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear Robert, All,
>
> To my  best knowledge, Title, Site and Inscription had been on the list of
> classes potentially to be deleted, when the current principles for
> minimality had been formulated. The respective decision not to delete is
> documented in some minutes. It was extensively discussed and voted.
> Following our rules, this decision can only be undone in a new issue, if
> new, different evidence is provided. This rule is to ensure some continuity
> for a standard, and economy of work. Currently, I see no new evidence.
>
> Best,
>
> Martin
>
> On 11/8/2022 10:33 PM, Robert Sanderson via Crm-sig wrote:
>
>
> I propose that E35 Title also does not legitimately rise to the
> requirements of being a named class in CRM Base.
>
> In particular:
>
> * It does not have its own properties
> * While it is the range of P102, P102 is indistinguishable semantically
> from its super-property, P1. Read the scope notes and replace "title" with
> "name" and it comes out the same.  If that is *not* the case, then we would
> need a property that relates E1 and E33_E41_Linguistic_Appellation, at
> which point we would need to give a number of E33_E41.
> * It can be replaced without semantic loss by
> E33_E41_Linguistic_Appellation, perhaps further clarified by the addition
> of domain specific vocabulary (supplied title vs artist's title) using
> P2_has_type
> * It does not have any sub-classes.
>
> And so, it can safely be deleted.
>
> Rob
>
> --
> Rob Sanderson
> Director for Cultural Heritage Metadata
> Yale University
>
> ___
> Crm-sig mailing 
> listCrm-sig@ics.forth.grhttp://lists.ics.forth.gr/mailman/listinfo/crm-sig
>
>
>
> --
> 
>  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

Re: [Crm-sig] New Issue: Delete E35 Title

[Robert Sanderson via Crm-sig]

Hi Martin,

I think the new evidence is the new precedent of including classes in the
RDFS that are not documented in the formal standard, where those classes
are deemed not to meet the minimality requirements. Also your very
reasonable assertion to be objective in the application of those rules,
which was not clearly taken into account during the previous discussions,
otherwise they would have been removed at the time.

Rob


On Wed, Nov 9, 2022 at 8:59 AM Martin Doerr via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear Robert, All,
>
> To my  best knowledge, Title, Site and Inscription had been on the list of
> classes potentially to be deleted, when the current principles for
> minimality had been formulated. The respective decision not to delete is
> documented in some minutes. It was extensively discussed and voted.
> Following our rules, this decision can only be undone in a new issue, if
> new, different evidence is provided. This rule is to ensure some continuity
> for a standard, and economy of work. Currently, I see no new evidence.
>
> Best,
>
> Martin
>
> On 11/8/2022 10:33 PM, Robert Sanderson via Crm-sig wrote:
>
>
> I propose that E35 Title also does not legitimately rise to the
> requirements of being a named class in CRM Base.
>
> In particular:
>
> * It does not have its own properties
> * While it is the range of P102, P102 is indistinguishable semantically
> from its super-property, P1. Read the scope notes and replace "title" with
> "name" and it comes out the same.  If that is *not* the case, then we would
> need a property that relates E1 and E33_E41_Linguistic_Appellation, at
> which point we would need to give a number of E33_E41.
> * It can be replaced without semantic loss by
> E33_E41_Linguistic_Appellation, perhaps further clarified by the addition
> of domain specific vocabulary (supplied title vs artist's title) using
> P2_has_type
> * It does not have any sub-classes.
>
> And so, it can safely be deleted.
>
> Rob
>
> --
> Rob Sanderson
> Director for Cultural Heritage Metadata
> Yale University
>
> ___
> Crm-sig mailing 
> listCrm-sig@ics.forth.grhttp://lists.ics.forth.gr/mailman/listinfo/crm-sig
>
>
>
> --
> 
>  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

Re: [Crm-sig] error in RDFS for 7.1.1 for the class that is a subclass of E41 and E33

[Robert Sanderson via Crm-sig]

Thank you for the clarification, Martin!

I have proposed the justifications for deleting three further classes that
do not, I believe, fulfil the criteria of being classes in CRM Base.

And indeed, let us judge these objectively and by the given criteria,
rather than subjective and personal preferences. If we come across a class
that we simply cannot delete without irreparable damage to the ontology, at
*that point* let us reconsider the criteria as being incomplete.

Thanks again,

Rob



On Tue, Nov 8, 2022 at 2:24 PM Martin Doerr via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear All,
>
> I just want to remind that we have a principle explicitly in the
> introduction of the CRM not to add classes without distinct properties of
> their own which is sufficiently relevant. By this, we purged a lot of very
> useful classes from the CRM, because it is "base".
>
> I prefer not to hear again "if we don't like a class". I kindly ask
> members to delete such terms from our vocabulary.
>
> Any argument in favour of a class in CRMbase which is nothing more
> semantics than multiple IsA, must be measured by this principle, and not by
> likes.
>
> If the principle is to be abandoned again, please make an issue. If the
> principle is unclear, please make an issue.
>
> Any issue for adding more custom classes to RDFS, to be discussed.
>
> Best,
>
> Martin
>
> On 11/8/2022 5:46 PM, Pavlos Fafalios via Crm-sig wrote:
>
> Dear George and Robert,
>
> Your comments are well taken and understood. I do not take a position
> against or for the addition of this class (I'm not yet sure of either
> decision), nor I support that "rules" must be always respected. I just
> tried to find a good reason for not having already introduced such a class
> (and thus facilitate the discussion).
>
> Best,
> Pavos
>
> On Tue, Nov 8, 2022 at 5:00 PM Robert Sanderson 
> wrote:
>
>>
>> I agree with George that this should be added.
>>
>> There are plenty of cases of classes without additional properties that
>> serve only to join two parent classes. For example E22_Human-Made_Object,
>> E25_Human-Made_Feature, and E34_Inscription. There are also remaining leaf
>> nodes with no properties with only one parent class, such as E27_Site.
>> Further, there are classes that have a property, but which is semantically
>> indistinguishable from its super property. If the requirement is a
>> property, then I propose
>>
>> Pxx_is_named_by (names)
>> Domain: E1
>> Range: Exx_Name (previously E33_E41)
>> Sub Property Of: P1_is_identified_by
>> Super Property Of:  P102 has title
>>
>> This property describes the naming of any entity by a name in a human
>> language.
>>
>> And the
>> Exx_Name
>> Super Class: E33, E41
>> Super Class Of: E35 Title
>>
>>
>> The discussion last time devolved to "Well we use those so we don't want
>> to get rid of them so we're not going to even though they don't have
>> properties". But here's the thing ... *everything* has a Name (by which I
>> mean an E33_E41_Linguistic_Appellation). And it's easy to demonstrate that
>> E33_E41 is very well used.
>>
>> So ... I don't find the argument that we can't do this "because rules"
>> very convincing when those rules are applied so inconsistently.
>>
>> Rob
>>
>>
>>
>> On Tue, Nov 8, 2022 at 9:18 AM Pavlos Fafalios via Crm-sig <
>> crm-sig@ics.forth.gr> wrote:
>>
>>> Dear George,
>>>
>>> To my understanding (without having been involved in the
>>> relevant discussions about having the E33_E41 class in the RDFS but not in
>>> CRM),
>>> and according to the discussion in issue 363
>>> 
>>> ,
>>> classes that use to co-occur on things simultaneously without being
>>> associated with properties only applicable to the combination of such
>>> classes, are not modelled individually as subclasses of multiple parent
>>> classes (a principle used for keeping the ontology compact).
>>>
>>> The 'E35 Title' class exists because there is a property 'P102 has
>>> title' (of E71 Human-Made Thing) that needs to point to something that is
>>> both a linguistic object and an appellation.
>>> So, for having a CRM class "E? Linguistic Appellation", there should be
>>> a property that needs to point to something that is both a linguistic
>>> object and an appellation (and with the intended meaning), e.g. a 'has
>>> linguistic appellation' property for E39 Actor or E77 Persistent Item. To
>>> my understanding, since there is no such property, there is (currently) no
>>> need to introduce such a class in CRM.
>>>
>>> Best,
>>> Pavlos
>>>
>>>
>>>
>>> On Tue, Nov 8, 2022 at 12:50 PM George Bruseker via Crm-sig <
>>> crm-sig@ics.forth.gr> wrote:
>>>
 It's not really though. In the majority of cases when you talk about a
 name you need to talk about a language too. Especially if CRM wants to be
 inclusive etc. We have a subclass 'title' of appellation that does allow
 but it only works for inanimate objects. So it is useless 

[Crm-sig] New Issue: Delete E35 Title

[Robert Sanderson via Crm-sig]

I propose that E35 Title also does not legitimately rise to the
requirements of being a named class in CRM Base.

In particular:

* It does not have its own properties
* While it is the range of P102, P102 is indistinguishable semantically
from its super-property, P1. Read the scope notes and replace "title" with
"name" and it comes out the same.  If that is *not* the case, then we would
need a property that relates E1 and E33_E41_Linguistic_Appellation, at
which point we would need to give a number of E33_E41.
* It can be replaced without semantic loss by
E33_E41_Linguistic_Appellation, perhaps further clarified by the addition
of domain specific vocabulary (supplied title vs artist's title) using
P2_has_type
* It does not have any sub-classes.

And so, it can safely be deleted.

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] NEW ISSUE: Delete E27 Site

[Robert Sanderson via Crm-sig]

The class E27 Site does not meet the given criteria for being a class in
CRM Base.

In particular:

* It does not have its own properties
* It is not the range of any other class's properties
* It is not the super-class of any other class
* It can be trivially replaced with its parent class, E26, with a
vocabulary entry in P2_has_type without loss of fidelity.

As such, we can safely and should delete the class.

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] NEW ISSUE: Delete E34 Inscription

[Robert Sanderson via Crm-sig]

E34 Inscription does not meet the requirements for a class in CRM Base, and
I thus propose that it should be deleted.

In particular:

* It does not have its own properties
* It is not the range of any properties
* It does not have any sub classes
* It is not any more discriminating than the intersection of its two
parents E33 Linguistic Object and E37 Mark (e.g. it is a linguistic mark)

As such, it does not rise to the level of a class that should be in CRM
Base and is unnecessary to include. It could be replaced with
E33_E37_Linguistic_Mark in the RDFS, following the
E33_E41_Linguistic_Appellation pattern.

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] error in RDFS for 7.1.1 for the class that is a subclass of E41 and E33

[Robert Sanderson via Crm-sig]

I agree with George that this should be added.

There are plenty of cases of classes without additional properties that
serve only to join two parent classes. For example E22_Human-Made_Object,
E25_Human-Made_Feature, and E34_Inscription. There are also remaining leaf
nodes with no properties with only one parent class, such as E27_Site.
Further, there are classes that have a property, but which is semantically
indistinguishable from its super property. If the requirement is a
property, then I propose

Pxx_is_named_by (names)
Domain: E1
Range: Exx_Name (previously E33_E41)
Sub Property Of: P1_is_identified_by
Super Property Of:  P102 has title

This property describes the naming of any entity by a name in a human
language.

And the
Exx_Name
Super Class: E33, E41
Super Class Of: E35 Title


The discussion last time devolved to "Well we use those so we don't want to
get rid of them so we're not going to even though they don't have
properties". But here's the thing ... *everything* has a Name (by which I
mean an E33_E41_Linguistic_Appellation). And it's easy to demonstrate that
E33_E41 is very well used.

So ... I don't find the argument that we can't do this "because rules" very
convincing when those rules are applied so inconsistently.

Rob



On Tue, Nov 8, 2022 at 9:18 AM Pavlos Fafalios via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear George,
>
> To my understanding (without having been involved in the
> relevant discussions about having the E33_E41 class in the RDFS but not in
> CRM),
> and according to the discussion in issue 363
> 
> ,
> classes that use to co-occur on things simultaneously without being
> associated with properties only applicable to the combination of such
> classes, are not modelled individually as subclasses of multiple parent
> classes (a principle used for keeping the ontology compact).
>
> The 'E35 Title' class exists because there is a property 'P102 has title'
> (of E71 Human-Made Thing) that needs to point to something that is both a
> linguistic object and an appellation.
> So, for having a CRM class "E? Linguistic Appellation", there should be a
> property that needs to point to something that is both a linguistic object
> and an appellation (and with the intended meaning), e.g. a 'has linguistic
> appellation' property for E39 Actor or E77 Persistent Item. To my
> understanding, since there is no such property, there is (currently) no
> need to introduce such a class in CRM.
>
> Best,
> Pavlos
>
>
>
> On Tue, Nov 8, 2022 at 12:50 PM George Bruseker via Crm-sig <
> crm-sig@ics.forth.gr> wrote:
>
>> It's not really though. In the majority of cases when you talk about a
>> name you need to talk about a language too. Especially if CRM wants to be
>> inclusive etc. We have a subclass 'title' of appellation that does allow
>> but it only works for inanimate objects. So it is useless as a general
>> case. The use of E33_E41 should be a default in most modelling cases with
>> E41 being the exception (mostly names are in a language). The general idea
>> of a name in a language is not an arcane concept, but the majority concept.
>> Needing to use an arcane construct either E33_E41 or multi instantiation
>> for the majority case when the standard could just provide the appropriate
>> class and document it and allow people to build around it, would be a
>> superior way to go imho.
>>
>> On Tue, Nov 8, 2022 at 12:04 PM stead...@outlook.com <
>> stead...@outlook.com> wrote:
>>
>>> Surely the RDFS E33_E41 is just a workaround for a common multiple
>>> instantiation that is problematic in RDFS land not a need for a new class.
>>>
>>>
>>>
>>> *From:* Crm-sig  *On Behalf Of *George
>>> Bruseker via Crm-sig
>>> *Sent:* 07 November 2022 15:58
>>> *To:* Elias Tzortzakakis 
>>> *Cc:* Crm-sig@ics.forth.gr
>>> *Subject:* Re: [Crm-sig] error in RDFS for 7.1.1 for the class that is
>>> a subclass of E41 and E33
>>>
>>>
>>>
>>> Thank Elias,
>>>
>>>
>>>
>>> You are definitely right that it is ok in the actual doc but mis
>>> referenced in the xml commentary. My point is not that the RDFS is wrong
>>> and it is great that it is produced and solid. I am more interested in how
>>> NOT having legitimate classes in the standard but compromising and just
>>> putting them in RDFS means that a) we create all sorts of arcana around
>>> what should be an open standard and b) because the class is not documented
>>> in the specification document we don't actually have a rule to know what is
>>> should be called.
>>>
>>>
>>>
>>> So it's more a process and principles level issue.
>>>
>>>
>>>
>>> Cheers,
>>>
>>>
>>>
>>> George
>>>
>>>
>>>
>>> On Mon, Nov 7, 2022 at 5:29 PM Elias Tzortzakakis 
>>> wrote:
>>>
>>> Dear George,
>>>
>>>
>>>
>>> The rdfs defines 1 such class using just 1 name the
>>> ‘E33_E41_Linguistic_Appellation’.
>>>
>>> The second name reference you are referring to
>>> ‘E41_E33_Linguistic_Appellation’ exists only in the 

Re: [Crm-sig] ISSUE: Delete Unnecessary / Incorrect Classes of CRMdig

[Robert Sanderson via Crm-sig]

YES

On Sun, Nov 6, 2022 at 7:15 AM Athanasios Velios via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> YES
>
> On 01/11/2022 09:53, George Bruseker via Crm-sig wrote:
> > Dear all,
> >
> > I propose the deletion of the following classes of CRMdig. The reason
> > that each should be deleted is listed beside it, but there are two
> > basic, principled reasons for the proposal:
> >
> > 1) the class can be modelled using a more generic pattern from CRMbase
> > or CRMdig without loss of semantic valence
> > 2) the class violates a CIDOC CRM modelling principle / best practice,
> > an alternative mode of expressing it already exists using standard
> > modelling in CRM and SHOULD be employed
> >
> > Therefore, if our proposal is done correctly removing all these classes
> > will serve to a) make the model lighter but just as semantically
> > powerful, b) accord with CRM SIG general modelling principles and c)
> > serve better as a middle level domain ontology for its area of scope.
> >
> > Martin Doerr, Rob Sanderson and Nicola Carboni have all contributed over
> > time to this review or properties alongside myself as proposer. Any
> > mistakes being mine.
> >
> > With that as background here are the proposed deletions:
> >
> > *D21 Person Name*: Obvious reasons. We already have a general E41
> > Appellation class and we do not specialize name classes endlessly but
> > use the p2 has type formulation.
> >
> > *D23 Room*: Convenience class that is in fact not that convenient: use
> > E53 Place
> >
> > This is a first list to which others may be added. At this time, I am
> > happy to propose the above list for deletion as hopefully relatively
> > uncontroversial.
> >
> > You can find the specification for CRMdig here:
> > https://cidoc-crm.org/crmdig/sites/default/files/CRMdig_v3.2.1.pdf
> > 
> >
> > To read more on these classes.
> >
> > There are other problematic classes which need to be reanalyzed before
> > they are considered for deletion or reworking. Separate issues will be
> > raised for each of these as necessary.
> >
> > I call a vote now, ending on Nov 11. Please vote by answering YES to
> > this emaill thread if you agree to these deletions or NO. If you vote
> > NO, please indicate if you vote NO to all or if you vote NO to some part
> > of the proposal.
> >
> > Thanks in advance for your interest and participation.
> >
> > Best,
> >
> > George
> > Vice Chair CRM SIG
> >
> > --
> > George Bruseker, PhD
> > Chief Executive Officer
> > Takin.solutions Ltd.
> > https://www.takin.solutions/ 
> >
> > ___
> > 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
>


-- 
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: Delete Unnecessary / Incorrect Properties of CRMdig

[Robert Sanderson via Crm-sig]

YES

Thank you for writing this up, George!

On Sun, Nov 6, 2022 at 7:15 AM Athanasios Velios via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> YES
>
> On 01/11/2022 09:48, George Bruseker via Crm-sig wrote:
> > Dear all,
> >
> > I propose the deletion of the following properties of CRMdig. The reason
> > that each should be deleted is listed beside it, but there are two
> > basic, principled reasons for the proposal:
> >
> > 1) the property can be modelled using a more generic pattern from
> > CRMbase or CRMdig without loss of semantic valence
> > 2) the property violates a CIDOC CRM modelling principle / best
> > practice, an alternative mode of expressing it already exists using
> > standard modelling in CRM and SHOULD be employed
> >
> > Therefore, if our proposal is done correctly removing all these
> > properties will serve to a) make the model lighter but just as
> > semantically powerful, b) accord with CRM SIG general modelling
> > principles and c) serve better as a middle level domain ontology for its
> > area of scope.
> >
> > Martin Doerr, Rob Sanderson and Nicola Carboni have all contributed over
> > time to this review or properties alongside myself as proposer. Any
> > mistakes being mine.
> >
> > With that as background here are the proposed deletions:
> >
> > *Delete:* L4 has preferred label: inconsistent with the rest of CRM,
> > redundant to other ontologies
> >
> > *Keep until D11/D9 revision is understood*: L20 has created: because D9
> > is removed (but see also D11)
> >
> > *Keep, not marginal: *L24 created logfile: creates a file of type
> > ‘logfile’ (used to separate derivative output from automated provenance
> > reporting.)
> >
> > *Delete:* L29 has responsible organization: unnecessary sub property
> > just use p14
> > *Delete:* L30 has operator: unnecessary sub property just use p14
> >
> > *Delete: *L31 has starting date-time: inconsistent modelling, use time
> > span like everyone else
> > *Delete: *L32: has ending date time: inconsistent modelling, use time
> > span like everyone else
> >
> > *Delete:* L33: has maker: this property violates event modelling. If it
> > continues to exist then E73 should have ‘has author’ (local project
> > requirements...)
> >
> > *Delete:* L34 has contractor: unnecessary sub property of an unnecessary
> > subproperty, use p14
> >
> > *Delete: *L35 has commissioner: unnecessary sub property, use p14
> >
> > *Delete: *L47 has comment: not ontological at all
> >
> > *Delete: *L51 has first name: inconsistent non ontological modelling,
> > anathema!
> > *Delete: *L52 has last name: see above
> > *Delete: *L53 is not uniquely identified by: this is not a way to encode
> > a negation and does not say anything (see also neg properties question)
> > *Delete: *L55 has inventory number: this is not ontological, please use
> > standard modelling
> > *Delete: *L56 has pixel width: no standard modelling, use dimension
> > *Delete: *L57 has pixel height: non standard modelling, use dimension
> > *Delete: *L59 has serial number: non standard modelling, use E42
> >
> > *Delete: *L61 was on going at: again non standard time modelling for
> > convenience sake
> >
> > This is a first list to which others may be added. At this time, I am
> > happy to propose the above list for deletion as hopefully relatively
> > uncontroversial.
> >
> > You can find the specification for CRMdig here:
> > https://cidoc-crm.org/crmdig/sites/default/files/CRMdig_v3.2.1.pdf
> > 
> >
> > To read more on these properties.
> >
> > I call a vote now, ending on Nov 11. Please vote by answering YES to
> > this emaill thread if you agree to these deletions or NO. If you vote
> > NO, please indicate if you vote NO to all or if you vote NO to some part
> > of the proposal.
> >
> > Thanks in advance for your interest and participation.
> >
> > Best,
> >
> > George
> > Vice Chair CRM SIG
> >
> >
> > --
> > George Bruseker, PhD
> > Chief Executive Officer
> > Takin.solutions Ltd.
> > https://www.takin.solutions/ 
> >
> > ___
> > 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
>


-- 
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 613 Re: Are there "weak inverse" shortcuts?

[Robert Sanderson via Crm-sig]

This seems inconsistent with the definition of shortcut:


A shortcut is a formally defined single *property *that represents a
deduction or join of a data path in the CIDOC CRM. The *scope notes *of all
properties characterized as shortcuts describe in words the equivalent
deduction.


(emphasis original)

"deduction", "equivalent" and "join" are not defined, but given other uses
of deduction / deduce (e.g. in the definition of "primitive" and "join" is
not used in that sense anywhere else in the document) it reads to me that
the definition of a short cut allows one to deduce the existence of the
longer data path. Equivalent typically means, and indeed does in the rest
of the document, "equal in value, meaning or function".

I would propose that the definition of shortcut be updated to not use the
words deduction or equivalent, and to include the information from the
second section about shortcuts that Christian-Emil has quoted.

Rob

On Thu, Oct 27, 2022 at 8:22 AM Christian-Emil Smith Ore via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear all,
>
> Some starting points:
>
>
> weak inverse is a somewhat opaque term. The defintion in Meghini & Doerr
> is not  clear:
>
> "inverse weak shortcuts, that is weak shortcuts on the inverse
> properties, and therefore in them an instance of the shortcut property
> implies an instance of each of the properties on the shortcut path"
>
> As far as I understand a "weak inverse" shortcut is a shortcut where an
> instance of the shortcut property  implies the existence of an instance of
> the long path.
>
> The example of a weak inverse property  in Meghini & Doerr is dated:
> P53 has former or current location: inverse weak
> From E18 Physical Thing through P161 has spatial projection,
> E53 Place, P121 overlaps with to E53 Place
>
> From v 6.2.8 E18 Physical Thing is no longer a subclass of E92 Spacetime
> Volume. So the long path becomes longer.
>
> P53 has former or current location:
> From E18 Physical Thing.P196 defines: E92 Spacetime Volume. P161 has
> spatial projection: E53 Place.P121 overlaps with:E53 Place
>
> Is this a weak inverse shortcut?  Can the long path be inferred from an
> instance of the shortcut property inside the frame of an actual KB?
>
> From the introduction to CRM (v.7.2.1):
>
> Some properties are declared as shortcuts of longer, more comprehensively
> articulated paths that connect the same domain and range classes as the
> shortcut property via one or more intermediate classes. For example, the
> property E18 Physical Thing*. P52 has current owner (is current owner of)*
> : E39 Actor, is a shortcut for a fully articulated path from E18 Physical
> Thing through E8 Acquisition to E39 Actor. An instance of the
> fully-articulated path always implies an instance of the shortcut property.
> However, the inverse may not be true; an instance of the fully-articulated
> path cannot always be inferred from an instance of the shortcut property
> inside the frame of the actual KB
>
> Best,
> Christian-Emil
>
>
>
>
>
>
>
> --
> *From:* Crm-sig  on behalf of Wolfgang
> Schmidle via Crm-sig 
> *Sent:* 19 October 2022 18:25
> *To:* crm-sig@ics.forth.gr
> *Subject:* Re: [Crm-sig] Are there "weak inverse" shortcuts?
>
> Aha, this belongs to issue 613. I didn’t see it before.
>
>
> > Am 19.10.2022 um 16:59 schrieb Wolfgang Schmidle via Crm-sig <
> crm-sig@ics.forth.gr>:
> >
> > And another one: Are there really no "weak inverse" shortcuts?
> >
> > Meghini & Doerr 2018 argue that weak inverse shortcuts are possible,
> although their example looks a little artificial:
> >
> > E18 Physical Thing P53 has former or current location E53 Place
> > implies
> > E18 Physical Thing P161 has spatial projection E53 Place P121 overlaps
> with E53 Place
> >
> > The CIDOC CRM document, on the other hand, says: "An instance of the
> fully-articulated path always implies an instance of the shortcut
> property." So, there seems to be a change of opinion after 2018.
> >
> > But this FOL expression that can be spotted in the wild looks to me like
> an example of a weak inverse shortcut:
> >
> > E70 Thing P101 had as general use E55 Type
> > E70 Thing P16i was used for E7 Activity P2 has type E55 Type
> > P101(x,y) ⇒ (∃z) [E7(z) ∧ P16i(x,z) ∧ P2(z,y)]
> >
> > The P101 scope note mentions it only indirectly ("This property
> associates an instance of E70 Thing with an instance of E55 Type that
> describes the type of use that it was actually employed for"), but I assume
> it is indeed ⇒ and not ⇔.
> >
> > Best,
> > Wolfgang
> >
> >
> > ___
> > 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
> 

Re: [Crm-sig] Deducing the current custody / ownership / location

[Robert Sanderson via Crm-sig]

Given this, I feel that we should re-open Issue 473:
https://cidoc-crm.org/Issue/ID-473-normal-custodian-of

If we cannot infer the current keeper, then nor can we infer the current
normal/permanent keeper, despite what we concluded previously.

Rob


On Tue, Oct 18, 2022 at 3:57 PM Martin Doerr via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear both,
>
> I think the discussion was that the "current" status cannot be inferred,
> but it is based on a local "closed world" knowledge, and can only be "true"
> until the time of the last respective update. So, I think the "no other
> move" since time X, or "no other move without back move" since time X
> exceeds the scope of logic.
> Isn't it?
>
> I fear the "if and only if" statements are wrong anyway. Better you raise
> an issue. I fear we have not understood circumstances that can lead to a
> custody or loosing etc., including death, heirs etc.
>
> Best,
>
> Martin
>
> On 10/18/2022 7:44 PM, Christian-Emil Smith Ore via Crm-sig wrote:
>
> I tried to say that
>
> P55(x,y) ⇐ (∃z) [ [E9(z) ˄ P25i(x,z) ˄ P26(z,y)]
> ˄ ¬ (∃w) [E9(w) ˄ P25i(x,w) ˄ P27(w,y)˄
> P182(z,w)]]
>
>
> is not sufficient since the above implication is true if the premise is
> false. So if there exist a newer move ( (∃w) [E9(w) ˄ P25i(x,w) ˄
> P27(w,y)˄ P182(z,w)]] is true) it is consistent with P55(x,y). The question
> is what should the additional axiom be ?
> The following is too strong since we do not require knowledge about a move
> P55(x,y) ⇒ (∃z) [ [E9(z) ˄ P25i(x,z) ˄ P26(z,y)]
> ˄ ¬ (∃w) [E9(w) ˄ P25i(x,w) ˄ P27(w,y)˄
> P182(z,w)]]
>
> That was what I thought.
> Best,
> Christian-Emil
> --
> *From:* Wolfgang Schmidle 
> 
> *Sent:* 18 October 2022 17:47
> *To:* Christian-Emil Smith Ore
> *Cc:* crm-sig@ics.forth.gr
> *Subject:* Re: [Crm-sig] Deducing the current custody / ownership /
> location
>
> Dear Christian-Emil,
>
> I am not sure I understand your additional axiom. How would it be
> expressed in normal language? Are you saying "if the knowledge base knows
> that x has current location y and that were was at least one Move of x,
> then there must be a Move of x to y after which there is no more Move of x
> away from y"?
>
> Best,
> Wolfgang
>
>
> > Am 17.10.2022 um 16:04 schrieb Christian-Emil Smith Ore via Crm-sig
>  :
> >
> > Dear Wolfgang,
> > It is clear (at least to me) that the FOLs in the 'current' properties
> are too weak. A complicating factor is that the FOL describes what we
> explicitly know, that is, the status in the knowledge system. In a closed
> world system, all shortcuts will imply at least one  instance of the
> corresponding long path.  This is not the case in an open world view, I
> think.
> >
> > P55(x,y) ⇐ (∃z) [ [E9(z) ˄ P25i(x,z) ˄ P26(z,y)]
> >  ˄ ¬ (∃w) [E9(w) ˄ P25i(x,w) ˄ P27(w,y)˄
> P182(z,w)]]
> >
> > If the premise in the FOL above is false, then P55(x,y) is trivially
> true. This is ok if [E9(z) ˄ P25i(x,z) ˄ P26(z,y)] is false, but it is not
> ok if
> >  (∃z) [ [E9(z) ˄ P25i(x,z) ˄ P26(z,y)]  ˄ (∃w) [E9(w) ˄ P25i(x,w) ˄
> P27(w,y)˄ P182(z,w)]]
> > is true.
> >
> > We need an additional axiom, something like
> > (∃z) [P55(x,y)  ˄  [E9(z) ˄ P25i(x,z) ˄ P26(z,y)] ⇒  ¬ (∃w) [E9(w)
> ˄P25i(x,w) ˄ P27(w,y)˄ P182(z,w)]]]
> > ?
> > Best,
> > Christian-Emil
> >
> > From: Crm-sig 
>  on behalf of Wolfgang Schmidle via Crm-sig
>  
> > Sent: 16 October 2022 14:37
> > To: crm-sig@ics.forth.gr
> > Subject: [Crm-sig] Deducing the current custody / ownership / location
> >
> > Dear All,
> >
> > I am trying to understand how one can infer the current custody /
> ownership / location of a Physical Thing / Object.
> >
> > Let's assume that there has been a E10 Transfer of Custody / E8
> Acquisition / E9 Move to an Actor or Place y. If there was no later event
> at all, it is inferred in the scope notes of P50 has current keeper / P52
> has current owner / P55 has current location that y is, in fact, the
> current keeper / owner / location. For example, the scope note of "P52 has
> current owner" says: "This property is a shortcut for the more detailed
> path from E18 Physical Thing through P24i changed ownership through, E8
> Acquisition, P22 transferred title to to E39 Actor, if and only if this
> acquisition event is the most recent."
> >
> > There is a stronger-sounding but actually weaker requirement that there
> was no later event that included a "P28 custody surrendered by / P23
> transferred title from / P27 moved from" y. The owner / location scope
> notes use the stronger requirement, the keeper scope note uses the weaker
> requirement. It would be good to explain in the respective scope notes the
> reasoning behind this difference.
> >
> > The FOL encodes the weaker requirement in all three cases. I assume the
> discrepancy between scope notes and FOL is an oversight. (This was actually
> my starting point.)
> >
> > The scope notes not only 

Re: [Crm-sig] New issues: Make SIG meetings more sustainable

[Robert Sanderson via Crm-sig]

Agree 100% with 1 and 2. Perhaps broadening 1 to "a relevant conference,
such as CIDOC / ICOM". The meeting would need to be shorter than the 4 day
marathon pattern however.

Federation via regional meetings is hard, especially amongst a relatively
small community, and multiplies the logistics burden. I don't think we have
the scale for it at this stage.

Rob



On Thu, Jul 7, 2022 at 12:59 PM Erin Canning via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear all,
>
> I would like to raise three items for discussion, regarding the SIG
> meetings and processes. "Make SIG meetings more sustainable" would be the
> third of these:
>
> *Background:* The requirement for online SIG meetings during the past two
> years showed that participation to online SIG meetings is much higher than
> meeting at a specific place. Securing funding for travel is not possible
> for participants outside large and rich institutions. This is in addition
> to the inevitable carbon footprint of the SIG especially for long-haul
> flights. Online meetings lack the capacity for easy idea sharing and are
> perhaps less practical for collaboration in groups. Another drawback of
> online meetings is the impossibility of convenient time-zones for all.
>
> *Proposal - the following are starting points for discussion:*
>
>1. The SIG to meet in person once a year at the CIDOC conference (with
>some overlap in schedules to avoid extremely long trips).
>2. The SIG to meet online twice a year to accommodate members who
>cannot travel and strengthen the community with wider representation across
>different time zones.
>3. Consider a federated SIG, where regional meetings take place either
>online or at a location thus reducing requirement for travel. These could
>be led by a member of the editorial group. Decisions at regional meetings
>will be sent for offline review and discussed by the editorial board in
>separate meetings either in person or online. Right for veto to remain at
>global level.
>
>
> I look forward to your thoughts.
>
> All the best,
> Erin Canning
>
> ___
> 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

Re: [Crm-sig] New issue: Contextualise issues in a more informative way

[Robert Sanderson via Crm-sig]

While I agree with the sentiment, everyone is busy and getting homework
done early is frequently a challenge. Especially when there is no guarantee
that the issue will actually get discussed at the SIG.
Getting people to attend pre-meeting meetings is also often a challenge. I
would propose that further changes, such as those outlined in your other
two emails, would be prerequisites to more formalized approaches to issue
contextualization during meetings.

Instead, I would put the burden on the issue's creator to ensure that the
explanation is sufficiently approachable before it makes it to a SIG
agenda. Then that description can be read in advance and summarized at the
beginning of the discussion. This could be combined with something George
has proposed of allowing the agenda to be formulated such that issues that
are well described and easy to engage with are prioritized, whereas group
wordsmithing / editorial tweaks can be deprioritized to smaller groups.

Rob


On Thu, Jul 7, 2022 at 12:54 PM Erin Canning via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear all,
>
> I would like to raise three items for discussion, regarding the SIG
> meetings and processes. "Contextualize issues in a more informative way"
> would be the first of these:
>
> *Background:* At the SIG meetings we are following a protocol with the
> working documents for introducing issues for decision. We cannot assume
> that members (especially newcomers) read these documents before the issues
> are discussed because: a) the volume of the documents and the background
> reading is too large, b) some (most) of them are prepared too soon before
> the meeting and there is no time to review them. Newcomers may not be
> completely aware of the process.
>
> *Proposal:*
>
>1. Before each SIG meeting one of the CIDOC-CRM chairs to hold a
>briefing meeting with the session chairs, to remind them that inclusive and
>informative introductions are needed for the whole duration of the meeting.
>2. Before or at the beginning of each meeting an informal and
>non-technical discussion among newcomers is held, convened by one of the
>members of the editorial group.
>3. Reminder to homework owners that working documents should be
>distributed to the listserv at least one week before the meeting dates in
>order to give participants sufficient time to get up to speed.
>
>
> I look forward to your thoughts.
>
> All the best,
> Erin Canning
>
> ___
> 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

Re: [Crm-sig] New issue: Improve voting process

[Robert Sanderson via Crm-sig]

I agree completely, this would greatly improve the transparency of and
engagement with the process.

Rob

On Thu, Jul 7, 2022 at 12:53 PM Erin Canning via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear all,
>
> I would like to raise three items for discussion, regarding the SIG
> meetings and processes. "Improve voting process" would be the second of
> these:
>
> *Background:* At the SIG meetings we are voting for decisions after
> discussion. It is often unclear why some participants vote and others do
> not. Typically newcomers feel that they should not or cannot vote. When
> documenting the votes, there is no clarity on how many participants
> abstained and how many were not eligible to vote. At the moment, the
> recorded votes do not represent this situation accurately.
>
> *Proposal:*
>
>1. In each vote, all present participants respond in one of four
>categories: yes, no, abstain, ineligible (for those participants who have
>not been voted as SIG members). All responses are recorded. Reasoning for
>opposing votes should be recorded in the minutes, and participants are
>encouraged to provide rationale if desired.
>2. During the first session, the status of voting members is explained
>and when everyone introduces themselves participants who are not already
>voted are asked whether they would like to be voted as SIG members so that
>they can have voting capacity.
>
>
> I look forward to your thoughts.
>
> All the best,
> Erin Canning
>
> ___
> 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

Re: [Crm-sig] NEW ISSUE: "causal" in P14 scope note

[Robert Sanderson via Crm-sig]

Thanks Martin! :)

For the querying, I agree that if there's subProperty inferencing, and you
query for participated in, but the particular data uses carried out by,
that you'll still find it.
However without those inferences, or in our case, as a profile for as few
choices to make as possible in terms of implementation, we would still need
to pick one. Thus, as it's not P14, we should use P11 had participant.

R



On Wed, Jan 12, 2022 at 3:33 PM Martin Doerr via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear Robert,
>
> Yes, scope notes can always be improved!
>
> The role of the child should definitely not be regarded as P14. Necessary
> participation is definitey not meant by "causal" or "legal responsibility"
> in this scope note. P14 is meant in an active sense. In a sense, any
> participation may have an impact on an event. This was not meant here.
>
> Similarly, patients in a surgery are necessary, but do not carry it out.
> However, there are well-known criminal cases in which participation
> without inhibiting murder etc. are regarded as legally co-responsible. In
> that case, we should rather use P14, in my opinion.
>
> Since participation is a generalization of P14, the difference for the
> recall/ precision of querying the CRM is however marginal.
>
> Best,
>
> Martin
>
> On 1/12/2022 7:32 PM, Robert Sanderson via Crm-sig wrote:
>
> Dear all,
>
> A question came up in the Linked Art group today about the intent of
> "causal" in the scope not for P14 carried out by.
>
> The scope note reads, in its entirety:
>
> This property describes the active participation of an instance of E39
> Actor in an instance of E7 Activity. It implies causal or legal
> responsibility. The *P14.1 in the role of *property of the property
> specifies the nature of an Actor’s participation.
>
>
> The particular scenario being discussed was the baptism of a child and
> whether it could be said that the baby carried out the activity or was
> merely a participant or present.  The child is a necessary participant in
> the activity, but does that make their participation "causal"? Whether the
> child is actively or passively participating seems difficult to determine
> so we didn't rule P14 out on those grounds.
>
> For such an important property, I think we could easily improve the scope
> note :)
>
> Rob
>
> --
> Rob Sanderson
> Director for Cultural Heritage Metadata
> Yale University
>
> ___
> Crm-sig mailing 
> listCrm-sig@ics.forth.grhttp://lists.ics.forth.gr/mailman/listinfo/crm-sig
>
>
>
> --
> 
>  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] NEW ISSUE: "causal" in P14 scope note

[Robert Sanderson via Crm-sig]

Dear all,

A question came up in the Linked Art group today about the intent of
"causal" in the scope not for P14 carried out by.

The scope note reads, in its entirety:

This property describes the active participation of an instance of E39
Actor in an instance of E7 Activity. It implies causal or legal
responsibility. The *P14.1 in the role of *property of the property
specifies the nature of an Actor’s participation.


The particular scenario being discussed was the baptism of a child and
whether it could be said that the baby carried out the activity or was
merely a participant or present.  The child is a necessary participant in
the activity, but does that make their participation "causal"? Whether the
child is actively or passively participating seems difficult to determine
so we didn't rule P14 out on those grounds.

For such an important property, I think we could easily improve the scope
note :)

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] Modelling an Event's General Outcome Ideas? Properties?

[Robert Sanderson via Crm-sig]

I agree with Francesco -- anywhere we don't have complete knowledge of the
activities there will be utility to such a shortcut, when there is an
intended outcome, but one which is not certain.

An archeological expedition -- resulted in outcome of type "came home empty
handed" / "found something"
Commission of an artwork -- resulted in outcome of type "artist ran off
with the money" / "artist produced something else" / "artist produced what
was wanted" / ...
Exhibition planning -- resulted in outcome of type "exhibition" / "no
exhibition" / "revised exhibition" / ...
Conservation of object -- resulted in outcome of type "destroyed object by
mistake" / "no change" / "repaired damage" / ...
etc.

Rob




On Thu, Jan 6, 2022 at 12:56 PM George Bruseker 
wrote:

> Hi Rob / Martin,
>
> Yes, Rob provides a nice instance example.
>
> Again, I just want to explore whether such a property has applications
> beyond this scope. Perhaps it isn't needed but if we look at more examples
> maybe a generalization will arise.
>
> Best,
>
> George
>
> On Thu, Jan 6, 2022 at 7:53 PM Robert Sanderson 
> wrote:
>
>>
>> Let me try and explain my understanding
>>
>> There are events, such as the auction of a specific lot, in which the
>> objects in the lot are offered for sale.
>>
>> That event might result in the transfer of ownership of the objects in
>> the lot from their current owner to the new owner, but they might not --
>> there might be no bidders, the reserve price might not be met, etc. At
>> which point there is no transfer of ownership at all, and hence we should
>> not create an E8 Acquisition because there was no change in ownership.
>>
>> So ... we have established that the auction of the lot is not the same
>> entity as the E8 acquisition, which might be triggered by the auction of
>> lot. Let's just call it an E7 Activity.
>>
>> Now, lets assume that we do not know anything at all about that
>> Acquisition. So, much like the other *_of_type properties, we don't want to
>> instantiate an E8 which was triggered by the E7 but with no properties, but
>> instead to just say that the E7 resulted in an activity of_type Sale, or
>> of_type Return, or of_type Unknown, or of_type Bought In.
>>
>> Thus:
>>
>>  a E7_Activity ;
>>   carried_out_by  ;
>>   triggered_activity_of_type  .
>>
>>  a E55_Type .
>>
>> Something like that?
>>
>> Rob
>>
>>
>> On Thu, Jan 6, 2022 at 12:28 PM Martin Doerr via Crm-sig <
>> crm-sig@ics.forth.gr> wrote:
>>
>>> Hi George,
>>>
>>> Please explain in more detail:
>>>
>>> On 1/6/2022 1:54 PM, George Bruseker wrote:
>>>
>>> Hi Martin,
>>>
>>> So the context for this is that there are provenance events being
>>> described and there is categorical knowledge derivable from the source
>>> material which a researcher might want to attribute to the event on what
>>> generally happened, the event ended in a sale, didn't end in a sale etc.
>>>
>>> What sort of event would "end in a sale", and why this event is not a
>>> sale itself, or why the sale itself is not an event in its own right. Can
>>> you cite an instance? Since I have happened to make full analysis of
>>> auction house actions and internet sales offers, I would need more details.
>>>
>>> I used a model which simply separates the sales offer from the legal
>>> transaction. The sale itself is not an outcome in this model, but motivated
>>> by the offer. Note that sales may be done without offer. Requests for sales
>>> are also different communications.
>>>
>>> I did not see a need to describe "outcome" in general terms.
>>>
>>> Further, could you better explain what you mean by "outcome" other than
>>> common language? Could you give a semantic definition, that would separate
>>> expextations from necessities, prerequisites and deterministic behaviour
>>> etc. ?
>>>
>>> I seriuosly do not understand  that "outcome" has an ontological nature.
>>> For the time being I recognize it as a word of a language.
>>>
>>>
>>> The cheap and cheerful solution would just be to put this as a p2 has
>>> type... the typical solution.
>>>
>>> I principally disagree that cheap is cheerful. This is not a CRM
>>> Principle. P2 has type has never been a cheap solution. It is very precisly
>>> described as specialization without adding properties. I honestly do not
>>> understand what the type would pertain to, once it may not characterize the
>>> event, but an event to follow?
>>>
>>>
>>> It would nice to be more accurate though since the categorization isn't
>>> of the event itself but of its typical outcome.
>>>
>>> Exactly, if I would understand he sense of "outcome", I could follow you
>>> better. Note, that words and senses are different, and CRM is not modelling
>>> English language.
>>>
>>> So the case that comes up here is that provenance researchers want to
>>> classify the outcomes of an event by type regardless of their knowledge of
>>> the specifics of what went on in that event (because the source material
>>> may simply not allow them to know).
>>>

Re: [Crm-sig] Modelling an Event's General Outcome Ideas? Properties?

[Robert Sanderson via Crm-sig]

Let me try and explain my understanding

There are events, such as the auction of a specific lot, in which the
objects in the lot are offered for sale.

That event might result in the transfer of ownership of the objects in the
lot from their current owner to the new owner, but they might not -- there
might be no bidders, the reserve price might not be met, etc. At which
point there is no transfer of ownership at all, and hence we should not
create an E8 Acquisition because there was no change in ownership.

So ... we have established that the auction of the lot is not the same
entity as the E8 acquisition, which might be triggered by the auction of
lot. Let's just call it an E7 Activity.

Now, lets assume that we do not know anything at all about that
Acquisition. So, much like the other *_of_type properties, we don't want to
instantiate an E8 which was triggered by the E7 but with no properties, but
instead to just say that the E7 resulted in an activity of_type Sale, or
of_type Return, or of_type Unknown, or of_type Bought In.

Thus:

 a E7_Activity ;
  carried_out_by  ;
  triggered_activity_of_type  .

 a E55_Type .

Something like that?

Rob


On Thu, Jan 6, 2022 at 12:28 PM Martin Doerr via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Hi George,
>
> Please explain in more detail:
>
> On 1/6/2022 1:54 PM, George Bruseker wrote:
>
> Hi Martin,
>
> So the context for this is that there are provenance events being
> described and there is categorical knowledge derivable from the source
> material which a researcher might want to attribute to the event on what
> generally happened, the event ended in a sale, didn't end in a sale etc.
>
> What sort of event would "end in a sale", and why this event is not a sale
> itself, or why the sale itself is not an event in its own right. Can you
> cite an instance? Since I have happened to make full analysis of auction
> house actions and internet sales offers, I would need more details.
>
> I used a model which simply separates the sales offer from the legal
> transaction. The sale itself is not an outcome in this model, but motivated
> by the offer. Note that sales may be done without offer. Requests for sales
> are also different communications.
>
> I did not see a need to describe "outcome" in general terms.
>
> Further, could you better explain what you mean by "outcome" other than
> common language? Could you give a semantic definition, that would separate
> expextations from necessities, prerequisites and deterministic behaviour
> etc. ?
>
> I seriuosly do not understand  that "outcome" has an ontological nature.
> For the time being I recognize it as a word of a language.
>
>
> The cheap and cheerful solution would just be to put this as a p2 has
> type... the typical solution.
>
> I principally disagree that cheap is cheerful. This is not a CRM
> Principle. P2 has type has never been a cheap solution. It is very precisly
> described as specialization without adding properties. I honestly do not
> understand what the type would pertain to, once it may not characterize the
> event, but an event to follow?
>
>
> It would nice to be more accurate though since the categorization isn't of
> the event itself but of its typical outcome.
>
> Exactly, if I would understand he sense of "outcome", I could follow you
> better. Note, that words and senses are different, and CRM is not modelling
> English language.
>
> So the case that comes up here is that provenance researchers want to
> classify the outcomes of an event by type regardless of their knowledge of
> the specifics of what went on in that event (because the source material
> may simply not allow them to know).
>
> Please provide instances.
>
> In this context, as type the outcome value will be used for
> categorization, how many events resulted in 'sale' how many in 'not sale'.
>
> In a real query scenario it would be asking questions like how many events
> of such and such a type had what kinds of outcome. Or maybe how many events
> with such and such a general purpose had such and such a general outcome.
> And then filter by time, space, people etc.
>
> It would be very interesting to seek other examples of general outcome
> recording for events in other contexts and see if this is a generally
> useful property to define.
>
> Still, you use the term "outcome", without explaining it, isn't it? I
> honestly do not regard it as self-evident, and I had already written that
> in previous messages.
>
> Best,
>
> Martin
>
>
> Best,
>
> George
>
> On Sat, Jan 1, 2022 at 7:28 PM Martin Doerr via Crm-sig <
> crm-sig@ics.forth.gr> wrote:
>
>> In continuation:
>>
>> "Sold", "completed", "incomplete" are very specific things. Objects are
>> offered for sale, which does not imply anything more than a sort of
>> publication. Actual purchase is a reaction on the offer.  Purchase may
>> happen without offer. Actual change of ownership is modeled in the CRM. The
>> type of the event itself implies per default completion, such 

Re: [Crm-sig] Official NameSpaces of CRM Extensions?

[Robert Sanderson via Crm-sig]

That seems like a big change, and long-term for the better, but disruptive
in the shorter term while implementations change their namespaces.

A request, if we do go this route ... please don't nest namespaces, as it
makes life much harder for processing.

For example, if CRM base is http://www.cidoc-crm.org/cidoc-crm/ then
E55_Type would be http://www.cidoc-crm.org/cidoc-crm/E55_Type.

But then if sci is http://www.cidoc-crm.org/cidoc-crm/crm-sci/  processors
need to be careful not to use the CRM prefix, with a term
"crm-sci/O19_Encounter"

Thus, please, something like http://www.cidoc-crm.org/extensions/crm-sci/
as the namespace URI would be preferable.

Thanks!

Rob




On Tue, Dec 21, 2021 at 1:30 PM Pavlos Fafalios via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear George, all,
>
> I agree that it is better to have namespaces under cidoc-crm.org for the
> official extensions, e.g.:
>   http://www.cidoc-crm.org/cidoc-crm/crmsci/ (or any other similar uri
> that starts with http://www.cidoc-crm.org/)
> Also, these URIs, as well as the URIs of their classes and properties,
> should resolve to the latest "published version", based on the http request
> type (as we now do with the base model).
>
> We discussed a bit about this on issue 460 (see point F):
>
> https://docs.google.com/document/d/1pU_WJcCU5R-Fz_NTU1VcjhocLG--rsb04xW9dqrCjC4/edit#heading=h.2i15qaj965p7
>
> When a new published version is available for one of the extensions
> (ideally aligned with crm 7.1.1), we can give it a try.
>
> Best regards,
> Pavlos
>
>
>
> On Mon, Dec 20, 2021 at 11:57 AM George Bruseker via Crm-sig <
> crm-sig@ics.forth.gr> wrote:
>
>> Dear all,
>>
>> Thanks Nicola, that makes sense. I wonder if it is worth talking about
>> what namespace the extensions have going forward. Taking CRMDig as an
>> example. It arose from a project within which FORTH was a major partner and
>> is an outcome of that work. It thus makes sense that it is registered under
>> a FORTH namespace. But if it is considered an official extension, should it
>> eventually have a namespace within the cidoc crm world for
>> generally consistency / understandability / maintenance? May be worth a SIG
>> conversation?
>>
>> Best,
>>
>> George
>>
>> On Mon, Dec 20, 2021 at 9:51 AM Nicola Carboni 
>> wrote:
>>
>>> Dear George,
>>>
>>> The namespace to be used should be the xml:base value in the RDF
>>> document. Example:
>>>
>>> http://www.w3.org/1999/02/22-rdf-syntax-ns#; 
>>> xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#; xml:lang="en" 
>>> xml:base="http://www.cidoc-crm.org/cidoc-crm/CRMsci/;>
>>>
>>> http://www.w3.org/1999/02/22-rdf-syntax-ns#; 
>>> xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#; 
>>> xml:base="http://www.ics.forth.gr/isl/CRMgeo/; xml:lang="en">
>>>
>>> The confusion started because the namespace has changed over time
>>>
>>> CRMdig 3.2.2 had
>>>
>>> http://www.w3.org/1999/02/22-rdf-syntax-ns#; 
>>> xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#; 
>>> xml:base="http://www.ics.forth.gr/isl/CRMext/CRMdig.rdfs/; xml:lang="en">
>>>
>>> The latest version is
>>>
>>> rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#; 
>>> xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#; 
>>> xml:base="http://www.ics.forth.gr/isl/CRMdig/; xml:lang="en">
>>>
>>> Generally they are both documented in prefix.cc, hence someone is still
>>> using the old ones.
>>>
>>> For clarifying the confusion, It is possible to write explicitly in the
>>> RDF itself the preferred namespace and prefix, using the properties
>>> vann:preferredNamespaceUri and vann:preferredNamespacePrefix . Example (in
>>> ttl) from VIR  :
>>>
>>> vann:preferredNamespacePrefix "vir" ;vann:preferredNamespaceUri 
>>> "http://w3id.org/vir#; ;
>>>
>>> Best,
>>>
>>> Nicola
>>>
>>> --
>>> Nicola Carboni
>>> Visual Contagions
>>> Digital Humanities - dh.unige.ch
>>> Faculté des Lettres
>>> Université de Genève
>>> 5, rue de Candolle
>>> 1211 Genève 4
>>>
>>> On 15 Dec 2021, at 11:58, George Bruseker via Crm-sig wrote:
>>>
>>> Dear all,
>>>
>>> I am wondering if anybody else struggles with what official namespace ot
>>> use for the CRM extensions. I'm not really sure how the situation
>>> stands.
>>> Should the minisites for each extension have a prominent place where
>>> they
>>> display the namespaces just so we all follow the same procedure? Do I
>>> miss
>>> what is already there?
>>>
>>> Best,
>>>
>>> George
>>> ___
>>> 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
>>
>
>
> --
> Pavlos Fafalios
>
> Postdoctoral researcher (Marie Curie IF - Project ReKnow
> )
> Centre for Cultural Informatics & Information Systems Laboratory
> Institute of Computer Science - FORTH
>
> and
>

Re: [Crm-sig] Scope note/range clarification - E80, P112

[Robert Sanderson via Crm-sig]

Ahh, thank you, I understand now. Well, the scope notes of the various
classes and properties should be improved to make that clear if it's the
case.
And then we would need to have the discussion about how to remove fragments
from meteorites, so I hope that's _not_ the case :D

R


On Tue, Nov 30, 2021 at 3:59 PM Athanasios Velios 
wrote:

> I completely understand the reasoning and I agree that intuitively a
> tree with a broken branch is a diminished thing. It is just that the
> scope note and all of the examples in E80 Part Removal are for
> Human-Made things so I worry that the class has been designed for
> Human-Made things only, i.e. breaking off the original branch may not be
> E80. Part Addition and Part Removal are designed to allow us to track
> the use of a component integrated intentionally in multiple objects over
> its history, so it may be that a thing needs to be added before it can
> be removed. If we care about the tree prior to cutting the branch then
> it may be only a modification. Am I taking it too far?
>
> Having said that, pushing the property higher in the hierarchy, although
> I am told we should avoid it in general, in this case it may not cause
> too many problems.
>
> T.
>
> P.S. Amazingly, the inconsistency between the scope note and property
> range existed since version 3.4.
>
> On 30/11/2021 14:00, Robert Sanderson wrote:
> >
> > It makes sense for the twig from the branch, but not from the branch
> > from the tree (or stalactite from the cave, fragment for study from a
> > meteorite, etc etc).
> > Removing the branch/fragment from the tree/meteorite results in a
> > Human-Made Object (via the Part Removal / Production), but the
> > tree/meteroite that is P112 diminished by the activity does not become a
> > Physical Human-Made Thing in the process. It stays an E20 Biological
> > Object/E19 Physical Object, just a smaller one.
> >
> > R
> >
> >
> > On Tue, Nov 30, 2021 at 3:45 AM Athanasios Velios
> > mailto:thana...@softicon.co.uk>> wrote:
> >
> > Hm, I do not consider it as a value statement, but as indication of
> the
> > intension. Breaking a tree branch which is worth putting in your
> > collection is a production of a Human-Made Object (as well as a
> > Biological Object). So when you break the twig off the branch, you
> are
> > removing a part from a Human-Made thing. In other words you cannot
> > remove a part unless it is included intentionally on the original
> thing
> > in the first place. Does this make sense?
> >
> > T.
> >
> >
> > On 29/11/2021 19:57, Robert Sanderson wrote:
> >  >
> >  > Isn't "diminished" just a label, rather than a value statement? I
> > don't
> >  > think something needs to be complete for a part to be removed (I
> can
> >  > break a twig off the branch, which I previously broke off the
> > tree). I
> >  > read it as "was made smaller by" in that some part was removed.
> >  > I agree that Part Removal is not always a Production -- the same
> > part
> >  > could be added and removed several times, and clearly not all of
> > them
> >  > are Productions. [Personally, I would never say it was a
> > Production, but
> >  > that a Production might have a Part Removal as a part of it]
> >  >
> >  > Here's a related question... Can an E78 Curated Holding have a
> > Physical
> >  > Feature as part of it? Conceptually, yes ... but E78 is a physical
> >  > aggregate, not a conceptual thing. Does the collections system of
> > Arches
> >  > National Park have records for the rock formations? Surely it
> > must. And
> >  > if the National Park boundaries were changed, then the arched rock
> >  > formations that no longer fell within the protected area would
> > have to
> >  > be removed from the E78. So I think I even retract "you can't
> remove
> >  > features" given the physicality of E78.
> >  >
> >  > Rob
> >  >
> >  >
> >  > On Mon, Nov 29, 2021 at 2:05 PM Athanasios Velios
> >  > mailto:thana...@softicon.co.uk>
> > >>
> > wrote:
> >  >
> >  > Yes this is a logical position. I guess the way I have been
> > reading it
> >  > is that the object that is diminished was indeed
> > intentionally made
> >  > by a
> >  > human and therefore it *can* be diminished. If it is any
> > thing then who
> >  > judges if it is complete and has been diminished? There is no
> > agency on
> >  > its original "production".
> >  >
> >  > The reason we have E18 as range is because the removed item's
> > identity
> >  > is not that of a human made object. I.e. Part removal is not a
> >  > Production which I think is the reason the following sentence
> > is in the
> >  > scope note:
> >  >
> >  > "In cases where 

Re: [Crm-sig] Scope note/range clarification - E80, P112

[Robert Sanderson via Crm-sig]

It makes sense for the twig from the branch, but not from the branch from
the tree (or stalactite from the cave, fragment for study from a meteorite,
etc etc).
Removing the branch/fragment from the tree/meteorite results in a
Human-Made Object (via the Part Removal / Production), but the
tree/meteroite that is P112 diminished by the activity does not become a
Physical Human-Made Thing in the process. It stays an E20 Biological
Object/E19 Physical Object, just a smaller one.

R


On Tue, Nov 30, 2021 at 3:45 AM Athanasios Velios 
wrote:

> Hm, I do not consider it as a value statement, but as indication of the
> intension. Breaking a tree branch which is worth putting in your
> collection is a production of a Human-Made Object (as well as a
> Biological Object). So when you break the twig off the branch, you are
> removing a part from a Human-Made thing. In other words you cannot
> remove a part unless it is included intentionally on the original thing
> in the first place. Does this make sense?
>
> T.
>
>
> On 29/11/2021 19:57, Robert Sanderson wrote:
> >
> > Isn't "diminished" just a label, rather than a value statement? I don't
> > think something needs to be complete for a part to be removed (I can
> > break a twig off the branch, which I previously broke off the tree). I
> > read it as "was made smaller by" in that some part was removed.
> > I agree that Part Removal is not always a Production -- the same part
> > could be added and removed several times, and clearly not all of them
> > are Productions. [Personally, I would never say it was a Production, but
> > that a Production might have a Part Removal as a part of it]
> >
> > Here's a related question... Can an E78 Curated Holding have a Physical
> > Feature as part of it? Conceptually, yes ... but E78 is a physical
> > aggregate, not a conceptual thing. Does the collections system of Arches
> > National Park have records for the rock formations? Surely it must. And
> > if the National Park boundaries were changed, then the arched rock
> > formations that no longer fell within the protected area would have to
> > be removed from the E78. So I think I even retract "you can't remove
> > features" given the physicality of E78.
> >
> > Rob
> >
> >
> > On Mon, Nov 29, 2021 at 2:05 PM Athanasios Velios
> > mailto:thana...@softicon.co.uk>> wrote:
> >
> > Yes this is a logical position. I guess the way I have been reading
> it
> > is that the object that is diminished was indeed intentionally made
> > by a
> > human and therefore it *can* be diminished. If it is any thing then
> who
> > judges if it is complete and has been diminished? There is no agency
> on
> > its original "production".
> >
> > The reason we have E18 as range is because the removed item's
> identity
> > is not that of a human made object. I.e. Part removal is not a
> > Production which I think is the reason the following sentence is in
> the
> > scope note:
> >
> > "In cases where the part removed has no discernible identity prior to
> > its removal but does have an identity subsequent to its removal, the
> > activity should be modelled as both an instance of E80 Part Removal
> and
> > E12 Production."
> >
> > hence the removed part is pushed up to E18.
> >
> > T.
> >
> >
> > On 29/11/2021 16:36, Robert Sanderson wrote:
> >  >
> >  > Good spotting! I agree with Thanasis that there is any issue, but
> I
> >  > think that the range is wrong for P112, which I would argue
> > should also
> >  > be E18.
> >  >
> >  > For example, I find a tree and break off a branch. The tree is
> not a
> >  > Human-Made Thing, it's an E20 Biological Object. Or I break a
> > piece of
> >  > obsidian (I would argue an E19) into two. Or if the obsidian is
> > part of
> >  > a lava flow, then it would be a physical feature ... and thus we
> > end up
> >  > at E18 as the common ancestor.
> >  >
> >  > I think that E18 remains correct for P113, given the described
> > use of
> >  > removal of a part from an E78 Curated Holding. If I remove a
> > meteorite
> >  > fragment from the collection of a natural history museum, the
> > meteorite
> >  > is (again, I would argue) an E19. Now ... can it ever be an E18
> > Physical
> >  > Thing but not an E19 Physical Object? It can't be a Feature, as
> they
> >  > cannot be removed, ruling out E26 and below. However E78 is an E24
> >  > Physical Human-Made Thing, but not an E19 Physical Object.  If we
> > use
> >  > E78 to model sub-collections, and sub-collections can be removed
> > from
> >  > their parent, then yes, here is a case where we need E18.
> >  >
> >  > Rob
> >  >
> >  >
> >  > On Mon, Nov 29, 2021 at 11:22 AM Athanasios Velios via Crm-sig
> >  > mailto:crm-sig@ics.forth.gr>
> > >> wrote:
> > 

Re: [Crm-sig] Scope note/range clarification - E80, P112

[Robert Sanderson via Crm-sig]

Isn't "diminished" just a label, rather than a value statement? I don't
think something needs to be complete for a part to be removed (I can break
a twig off the branch, which I previously broke off the tree). I read it as
"was made smaller by" in that some part was removed.
I agree that Part Removal is not always a Production -- the same part could
be added and removed several times, and clearly not all of them are
Productions. [Personally, I would never say it was a Production, but that a
Production might have a Part Removal as a part of it]

Here's a related question... Can an E78 Curated Holding have a Physical
Feature as part of it? Conceptually, yes ... but E78 is a physical
aggregate, not a conceptual thing. Does the collections system of Arches
National Park have records for the rock formations? Surely it must. And if
the National Park boundaries were changed, then the arched rock formations
that no longer fell within the protected area would have to be removed from
the E78. So I think I even retract "you can't remove features" given the
physicality of E78.

Rob


On Mon, Nov 29, 2021 at 2:05 PM Athanasios Velios 
wrote:

> Yes this is a logical position. I guess the way I have been reading it
> is that the object that is diminished was indeed intentionally made by a
> human and therefore it *can* be diminished. If it is any thing then who
> judges if it is complete and has been diminished? There is no agency on
> its original "production".
>
> The reason we have E18 as range is because the removed item's identity
> is not that of a human made object. I.e. Part removal is not a
> Production which I think is the reason the following sentence is in the
> scope note:
>
> "In cases where the part removed has no discernible identity prior to
> its removal but does have an identity subsequent to its removal, the
> activity should be modelled as both an instance of E80 Part Removal and
> E12 Production."
>
> hence the removed part is pushed up to E18.
>
> T.
>
>
> On 29/11/2021 16:36, Robert Sanderson wrote:
> >
> > Good spotting! I agree with Thanasis that there is any issue, but I
> > think that the range is wrong for P112, which I would argue should also
> > be E18.
> >
> > For example, I find a tree and break off a branch. The tree is not a
> > Human-Made Thing, it's an E20 Biological Object. Or I break a piece of
> > obsidian (I would argue an E19) into two. Or if the obsidian is part of
> > a lava flow, then it would be a physical feature ... and thus we end up
> > at E18 as the common ancestor.
> >
> > I think that E18 remains correct for P113, given the described use of
> > removal of a part from an E78 Curated Holding. If I remove a meteorite
> > fragment from the collection of a natural history museum, the meteorite
> > is (again, I would argue) an E19. Now ... can it ever be an E18 Physical
> > Thing but not an E19 Physical Object? It can't be a Feature, as they
> > cannot be removed, ruling out E26 and below. However E78 is an E24
> > Physical Human-Made Thing, but not an E19 Physical Object.  If we use
> > E78 to model sub-collections, and sub-collections can be removed from
> > their parent, then yes, here is a case where we need E18.
> >
> > Rob
> >
> >
> > On Mon, Nov 29, 2021 at 11:22 AM Athanasios Velios via Crm-sig
> > mailto:crm-sig@ics.forth.gr>> wrote:
> >
> > Hm, yes, this is confusing. We might need a new issue to update the
> > scope note. I think the correct class is E24 as it seems that E80
> Part
> > Removal does not cover cases such as cutting a stalactite off in a
> cave.
> >
> > Thanasis
> >
> > On 29/11/2021 15:41, Erin Canning via Crm-sig wrote:
> >  > Hello,
> >  >
> >  > I am hoping you might be able to help me with a small confusion -
> >  >
> >  > The scope note for E80_Part_Removal
> >  >  > >
> states
> >  > that "This class comprises the activities that result in an
> > instance of
> >  > E18 Physical Thing being decreased by the removal of a part."
> > This reads
> >  > to me as if the relationship would then go: E80 > P112_diminished
> >  > E18,
> >  > as P112 creates the connection to the thing being diminished
> (having
> >  > something removed from it), as opposed to P113_removed, which is
> > for the
> >  > connection to the thing that was removed.
> >  > However, the range of P112 is E24, not E18, and the scope note for
> >  > P112_diminished
> >  >  >  >> reads
> >  > "This property identifies the instance E24 Physical Human-Made
> Thing
> >  > that was diminished by an instance of E80 Part Removal."
> >  > Meanwhile, the range of P113_removed
> >  > 

Re: [Crm-sig] Scope note/range clarification - E80, P112

[Robert Sanderson via Crm-sig]

Good spotting! I agree with Thanasis that there is any issue, but I think
that the range is wrong for P112, which I would argue should also be E18.

For example, I find a tree and break off a branch. The tree is not a
Human-Made Thing, it's an E20 Biological Object. Or I break a piece of
obsidian (I would argue an E19) into two. Or if the obsidian is part of a
lava flow, then it would be a physical feature ... and thus we end up at
E18 as the common ancestor.

I think that E18 remains correct for P113, given the described use of
removal of a part from an E78 Curated Holding. If I remove a meteorite
fragment from the collection of a natural history museum, the meteorite is
(again, I would argue) an E19. Now ... can it ever be an E18 Physical Thing
but not an E19 Physical Object? It can't be a Feature, as they cannot be
removed, ruling out E26 and below. However E78 is an E24 Physical
Human-Made Thing, but not an E19 Physical Object.  If we use E78 to model
sub-collections, and sub-collections can be removed from their parent, then
yes, here is a case where we need E18.

Rob


On Mon, Nov 29, 2021 at 11:22 AM Athanasios Velios via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Hm, yes, this is confusing. We might need a new issue to update the
> scope note. I think the correct class is E24 as it seems that E80 Part
> Removal does not cover cases such as cutting a stalactite off in a cave.
>
> Thanasis
>
> On 29/11/2021 15:41, Erin Canning via Crm-sig wrote:
> > Hello,
> >
> > I am hoping you might be able to help me with a small confusion -
> >
> > The scope note for E80_Part_Removal
> >  states
> > that "This class comprises the activities that result in an instance of
> > E18 Physical Thing being decreased by the removal of a part." This reads
> > to me as if the relationship would then go: E80 > P112_diminished > E18,
> > as P112 creates the connection to the thing being diminished (having
> > something removed from it), as opposed to P113_removed, which is for the
> > connection to the thing that was removed.
> > However, the range of P112 is E24, not E18, and the scope note for
> > P112_diminished
> >  reads
> > "This property identifies the instance E24 Physical Human-Made Thing
> > that was diminished by an instance of E80 Part Removal."
> > Meanwhile, the range of P113_removed
> >  is E18, as
> > is the range of P31_has_modified , the
> > superproperty of P112.
> >
> > It seems to me therefore that either I am reading the scope note
> > incorrectly (very possible!) or that there is an inconsistency between
> > the two, perhaps in the range of P112?
> >
> > I looked in the Issues history for anything about this, and wonder if
> > the discussion around the change of P31 (Issue 191
> > ) might have relevance
> > to either the range or language around it, as in that case the range of
> > P31 was relaxed from E24 to E18. Although, that being said, this
> > perceived E18/E24 inconsistency as described above exists as far back as
> > v4.0 , the earliest
> > version available on the website, so perhaps it is my reading of the
> > scope note that is backwards...
> >
> > To summarize, my question is - Which is the correct range of P112: E18
> > as stated in the E80 scope note or E24 as stated in the P112 scope note
> > and range; or am I reading this set of notes/relationships incorrectly?
> >
> > Thanks for your guidance on this,
> > Erin Canning
> >
> >
> >
> > ___
> > 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
>


-- 
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] CRMSci O19 Property Labels Minor Correction?

[Robert Sanderson via Crm-sig]

+1 to changing it from at, which definitely implies location.

object_encountered_during seems good to me, thank you Melanie!

Rob



On Fri, Oct 22, 2021 at 8:38 AM melanie.roche--- via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear George,
>
> I share your concerns. Being unfamiliar with CRMsci in general and O19 in
> particular, when I first read your mesage I immediately assumed that the
> inverse property pointed to a place. As a non-native English speaker, I
> agree that there is a very strong locative flavour to the preposition "at",
> and it would be totally counter-intuitive to associate it with an event. I
> also feel the same applies (though less strongly) to "in".
>
> If we want to exclude any kind of locative flavour, would the preposition
> "during" be appropriate, or would it only work for some events but not all?
>
> Best,
>
> Mélanie.
>
>
>
> De :"George Bruseker via Crm-sig" 
> A :"crm-sig" 
> Date :22/10/2021 13:43
> Objet :[Crm-sig] CRMSci O19 Property Labels Minor Correction?
> Envoyé par :"Crm-sig" 
> --
>
>
>
> Dear all,
>
> I am manually correcting some ontology files (horror) and changing the
> nomenclature from the previous names for O19 which were:
>
> has found object
> (was object found by)
>
> up until version 1.2.6 of the document.
>
> Then it changed, rightly (mostly), to:
>
> encountered object
> was object encountered at
>
> which is how it has been ever since.
>
> So, what's my problem? The inverse property label sounds like we named it
> poorly? Particularly the preposition 'at' has a locative flavour that to me
> would indicate that the object pointed at would be a place. The object
> pointed at, however, is of course the encounter event.
>
> I do not remember if we made the choice above on purpose or if this is
> just a mistake, but reading it now it strikes me as not the best choice.
>
> I think typically we would use 'by' (which is also problematic since
> sounds like it should point to an actor) or maybe 'in' which again sounds
> slightly locative, although might work better with an event.
>
> Anyhow, does anyone else see this as a problem or is it just me?
>
> Best,
>
> George___
> Crm-sig mailing list
> Crm-sig@ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>
> --
>
>
> *Découvrez toute la programmation culturelle de la rentrée à la BnF
> Pass BnF lecture/culture
>  : bibliothèques,
> expositions, conférences, concerts en illimité pour 15 € / an* – *Acheter
> en ligne *
>
> *Avant d'imprimer, pensez à l'environnement.*
> ___
> 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

Re: [Crm-sig] New Issue: Non-human Actors

[Robert Sanderson via Crm-sig]

Hi Martin, all,

Perhaps I am misunderstanding your comment about individuality ... but
there are clearly individual animals in both my use cases and Philippe's.
The twitter thread that Philippe linked to demonstrated the very common
nature of museum collections having to work around the lack of a non-human
agent class.

Given the lack of discussion at the SIG, the seeming lack of interest in
moving this forward in a timely fashion, and the demonstrated need to
document interactions between animals and other entities described in at
least natural history collections, such as the original use case presented
of the bird (identified and collected instance rather than type) that built
the nest (again, collected instance), plus the ones from Philippe, it seems
inevitable that something outside of CRM base is required.  There is a
precedent in CRMSci for inserting classes into the hierarchy, and as the
proposal from George is monotonic, it seems an extension could define the
solution as presented.

As such, we can take the proposed solution back to the Linked Art group to
discuss in that context and if, in the course of time, the SIG changes its
opinion or comes to a solution, then the extension can always be rolled
into either a SIG based extension or into base.

Rob

On Thu, Oct 14, 2021 at 4:13 PM Martin Doerr via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear Philippe, All,
>
> These are good examples. Could you provide sample records? We should check
> the schema used for migratory species tracking, and find an expert for
> that. Presence in events may be enough. Kea, Caledonian Crow and other
> behavior studies typically are done in controlled Lab environments, and
> therefore do not pose a problem of historical fact integration. Integration
> needs are on the kind of abilities, rather than the actions. Would need an
> expert.
> I think the examples show that we talk about some subset of animals that
> are relevant, and do not pose problems of individuality.
>
> Further, I think machine events are much more important to discuss. I
> suggest to talk about machine "reactions" "delayed reactions" stimulus
> induced reactions, predetermined. So far, robots with random behavior are
> not particularly useful.
> Software is instructions, not "active" or "reactive". What make a robot
> appear to have "agency" is nothing else that it work with a clock inside.
> There are traps, bombs triggered by clocks, mechanical vending machines
> etc, which generalize over the concept of deferred machine reactions.
>
> By the way, the term "agency" as a property has no good translation to
> German.
>
> All the best,
>
> Martin
>
> On 10/14/2021 5:40 PM, Philippe Michon via Crm-sig wrote:
>
> Dear all,
>
> I am not an expert in biology, but the question has aroused a lot of
> interest within my organization and I, therefore, allow myself to provide
> some animal examples within museum databases.
>
> I don't know if this example has been mentioned before, but the animals
> that received the Dickin medal are in my opinion good examples that animals
> participated in wars.
>
> As an example, the Canadian War Museum documents a Dickin medal of a dog
> named Gander .
> Although Gander is not widely documented on the museum's website, his
> Wikipedia  page highlights
> several of his heroic acts.
>
> Another similar example would be the rescue dog named Rex (also documented
> on Wikipedia )
> which is associated with 4 items from the Imperial War Museums
> .
> In addition to the Dickin medal
> , they also
> document his harness
> .
>
> Here is a short description from the harness record:
>
> Harness associated with 'Rex', a British Second World War Home Front
>> 'rescue dog'. 'Rex' was awarded the Dickin medal on 25 April 1945 for
>> outstanding bravery in finding bomb victims, trapped under fallen debris.
>
>
> Returning to Canada, the Canadian Museum of History documents 116
> artifacts (mostly trophies)
> 
> won by horses in various horse racing championships. The majority of horses
> are identified by their names such as Northern Dancer
>  for
> example. His biography is really well documented on Wikipedia
>  again.
>
> It also seems important to me to underline that the information on these
> horses is currently recorded in the "Person/Institution" field with an
> "Associated Famous Animal" tag. I don't know the reasons 

Re: [Crm-sig] New Issue: Non-human Actors

[Robert Sanderson via Crm-sig]

Hi Pat,

While that is certainly true from a model-theoretic perspective, in
practice authorities simply create Persons for them which is, in my
opinion, even worse because there is a demonstrated need which the modeling
is intentionally preventing.

For example in the Library of Congress:
Real animal/people:
  Lassie: https://id.loc.gov/authorities/names/nb2015016669.html
  Misha the Dolphin: https://id.loc.gov/rwo/agents/nb2017006372.html

And fictitious:
  Odie (from Garfield):
https://id.loc.gov/authorities/names/no2017122131.html
  Grumpy Cat: https://id.loc.gov/rwo/agents/n2013036964.html

In ULAN, here's a racehorse/person:

https://www.getty.edu/vow/ULANFullDisplay?find500353456


ISNI has a dog/person called Maggie Mayhem:
https://isni.org/isni/000497302960

And so on.

Rob


On Mon, Oct 11, 2021 at 4:50 PM Pat Riva via Crm-sig 
wrote:

> Just to remark that the library world discussed non-human actors for many
> years (in the literal sense of actor as in the dogs that portrayed Lassie
> in the TV series, or that portrayed Sykes and Paddy from Midsomer Murders,
> somehow it is always cute dogs that are brought up in the discussion).
>
> The desire was to list the named animal actors in the credits for the cast
> of a film and provide access via their "real" names the same as for the
> rest of the cast, and so using the same mechanisms as for human actors.
>
> This sounds like it might be fine until you realize that making the dog a
> valid LRM-E6 Agent means that it can have the full range of responsibility
> relationships to works, expressions, manifestations and items. Which
> becomes absurd.
>
> And while is it understood that one can easily film an individual animal,
> it isn't clear that it is behaving as an actor intending to create a
> cinematographic work in the same way that the human participants. There was
> also no clear consensus on which sorts of animals were individually
> interesting enough to merit this treatment, rather than just being viewed
> as an instance of their species (as in nature documentaries).
>
> The animal agent option was rejected in FRBR and again rejected in LRM,
> and a LRM-E6 Agent (= E39 Actor) remains restricted to either individual
> human beings (LRM-E7 Person) or groups of human beings (LRM-E8 Collective
> Agent, or F55 Collective Agent in LRMoo).
>
> The current compromise is that the animal actors, if it is desired to
> provide access points for them, are established as instances of a
> subcategory of LRM-E1 Res that is disjoint from LRM-E6 Agent. There was
> talk of creating some guidelines for this at one point, but I have not
> followed the issue since then.
>
> Pat
>
> Pat Riva
>
> Associate University Librarian, Collection Services
>
> Concordia University
>
> Vanier Library (VL-301-61)
>
> 7141 Sherbrooke Street West
>
> Montreal, QC H4B 1R6
>
> Canada
>
> pat.r...@concordia.ca
>
> --
> *From:* Crm-sig  on behalf of George
> Bruseker via Crm-sig 
> *Sent:* October 11, 2021 3:02 PM
> *To:* Martin Doerr 
> *Cc:* crm-sig@ics.forth.gr 
> *Subject:* Re: [Crm-sig] New Issue: Non-human Actors
>
> Hi Martin,
>
> I think Rob listed in the introduction to the issue the use cases of
> documentation of individual action of animals.
>
> It would seem that natural scientists don't only study species but also
> individuals.
>
> Here's a smattering of pieces culled from casual reading in the past few
> weeks with nice motivations and examples for these new classes.
>
>
> https://www.theguardian.com/environment/2021/sep/29/new-zealand-kea-can-use-touchscreens-but-cant-distinguish-between-real-and-virtual-worlds
> 
>
>
> https://www.businessinsider.com/watch-australias-google-delivery-drone-attacked-by-raven-mid-air-2021-9?utm_source=facebook.com_campaign=sf-insider-inventions_medium=social
> 
>
>
> 

Re: [Crm-sig] New Issue: Non-human Actors

[Robert Sanderson via Crm-sig]

Could we clarify what sort of expert we're looking for to move the
discussion forward? In particular, natural history museums seem to be at
the critical intersection between CIDOC and the activities of animals. I
can represent the sorts of documentary evidence from that side, and happy
to reach out to colleagues at other NHMs. So I think the first aspect is
covered, but I question whether we (as modelers of museum knowledge and
documentation) /need/ to understand animal individuality or behavior in
order to take the first step of describing an animal performing some
action. Conversely, my experience has always been that when there is
something to react to, it is much easier to engage with outside
specialists.  It is easier to ask for opinions on something than it is to
ask them to help come up with the interdisciplinary model.

I also don't think it makes sense to model animal actors in great detail,
down to the same level as the differences between classes in CRMTex for
example. The baseline that we need to start with is much simpler.  If there
isn't a fine grained concept of animal individuality, I don't think that
means we can't model an individual animal at a coarser granularity, just
that we shouldn't allow the ontology to describe anything that we don't
understand. Even as a non-biologist, I know without any hesitation that the
bird laid the egg in the nest in the Peabody Museum of Natural History, and
that the herd of dinosaurs created the footprints preserved in Dinosaur
State Park up the road from us. I know that a sheepdog can herd sheep and
makes decisions about which way to run to accomplish the aim of getting
the sheep into the next field (and when I was a little lad played the part
of such a sheepdog for my uncle in New Zealand). How does the sheepdog
know? Does it know that it knows? If we study 100 sheepdogs individually
and in groups, what do we learn about sheepdog behavior? I don't care, and
I don't think any other museum oriented documentation system would either :)

Rob


On Mon, Oct 11, 2021 at 11:50 AM Martin Doerr  wrote:

> Dear George, Robert,
>
> This makes generally sense to me as a discussion starting point. However,
> I‘d like to remind you that our methodology requires first a community
> practice of doing documentation about such things, and second domain
> experts for concepts that are not our primary knowledge.
>
> To my best knowledge, there does not exist any reliable concept of what
> individuality means across the animal kingdom, nor what a collective of
> such individuals is. There is an unbelievable complexity to these
> questions. We know from experience that any global widening of scope can
> blur all distinctions ontology enginerring relies on. Therefore I'd regard
> it as most important to find the experts first and let them speak.
>
> The reasons why we did not model animal actors is precisely the lack of an
> experts group to communicate with.
>
> Best,
>
> Martin
>
>
> On 10/11/2021 4:28 PM, George Bruseker wrote:
>
> Dear all,
>
> In preparation for the discussion of non-human actors as related to use
> cases arising in Linked.Art (inter alia), Rob and I have sketched some
> ideas back and forth to try to find a monotonic was to add the agency of
> animals in the first instance into CRM (proceeding in an empirical bottom
> up fashion) and then see where else we might also get added in (searching
> for the sibling class that Martin suggests and the generalization that it
> would need).
>
> The linked sketch provides a proposal for discussion. The background is
> given already in this issue.
>
>
> https://drive.google.com/file/d/1RtKBvAH1N0G8yaE_io6hU2Z8MTBmH_8-/view?usp=sharing
> (draw.io)
>
>
> https://drive.google.com/file/d/1aCEBtXjW8M0W7qCGe9ozSMeYAH7tJ3Wr/view?usp=sharing
> (png)
>
>
> Here is some argumentation.
>
> Up to now, CRM takes its scope as related to documenting intentional acts
> of human beings. Its top level class then has been E39 Actor which gives
> properties which allow the assigning of responsibility for an intentional
> activity. It has two subclasses, E21 Person and E74 Group. These two kinds
> of being have different behaviour, therefore properties, therefore classes.
>
> If we expand the scope (in base or in sci or wherever) to include animal
> agency in the first instance, then we must have a way to monotonically
> generate this extension (we don't want to just expand the scope of E39
> Actor because then we will end up with rabbits being responsible for
> financial crises and murders and all sorts of nonsense).
>
> So we want to introduce a sibling class for E39 Actor. Call this
> biological agent. Instances can be anything biological. This would
> obviously be some sort of a superclass of E21 Person, since all persons are
> biological actors as well. It would be a subclass of biological object
> since all biological agents must be biological. (but not all things
> biological are biological agents)
>
> Then we would want a 

Re: [Crm-sig] New Issue: RDFS Implementation and related issues

[Robert Sanderson via Crm-sig]

Thanks Pavlos, that's a great write up!

In case the discussion happens when I can't be at the SIG meeting (likely
due to timezone issues), my votes:

A - YES to the suggested scenario of creating a second file, that might
currently only hold this one alignment, but in the future might also map
between other core properties or classes. I'm okay with leaving it out
completely. I would be disappointed if it were left in, but not to the
point of a veto -- it's possible to ignore, just annoying to have to do so.

B - I'm okay with any of the results, so long as B3 (don't include them) is
also backed up with an OWL representation that /does/ include them.

C - YES. Also, FWIW, my code that generates a context file given the
ontology's RDFS:

https://github.com/linked-art/crom/blob/master/utils/make_jsonld_context.py
Which generates the context:
https://linked.art/ns/v1/linked-art.json

D - Would like to see what benefits a SHACL shape file would bring.
(abstain)

E - YES
F - YES

And the URI construction is a separate issue?

Rob


On Wed, Sep 29, 2021 at 8:46 AM Pavlos Fafalios via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear all,
>
> I think there is no open issue on this (please let me know if this is not
> true), so I suggest opening a new issue in order to finalize the discussion
> on the RDFS implementation.
>
> Based on the discussion on the other email thread (title: "RDFS, XML and
> more"), I created the below google doc (homework) where the different
> issues are summarised. Also, *there are suggestions on how to proceed*.
>
>
> https://docs.google.com/document/d/1oq02aS8xENzGBJAdxlSJzX_n9CE43_Aycl8NttReqis/edit?usp=sharing
>
> There will probably be a slot on this at the forthcoming SIG meeting, so
> that we can make some final decisions.
> So, please kindly check the doc before the next SIG meeting and feel free
> to comment (especially in case I forgot something, or something seems not
> to be the case), or directly reply to this email.
>
> Thank you all for the contributions!
>
> Best regards,
> Pavlos
>
> --
> Dr. Pavlos Fafalios
> Postdoctoral research fellow
> Project ReKnow  (MSCA Individual Fellowship
> )
>
> Centre for Cultural Informatics / Information Systems Laboratory
> Institute of Computer Science (ICS)
> Foundation for Research and Technology (FORTH)
>and
> Visiting Lecturer
> Department of Management Science & Technology (MST),
> Hellenic Mediterranean University (HMU)
>
> Address: N. Plastira 100, Vassilika Vouton, 70013 Heraklion, Greece
> Email: fafal...@ics.forth.gr
> Tel: +30-2810-391619
> Web: http://users.ics.forth.gr/~fafalios/
>
> ___
> 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

Re: [Crm-sig] New Issue: Non-human Actors

[Robert Sanderson via Crm-sig]

z Gonzalez 
>> ; crm-sig@ics.forth.gr 
>> 
>> *Asunto:* Re: [Crm-sig] New Issue: Non-human Actors
>>
>> Dear Mercedes,
>>
>> Thank you for your good comments! What we would need now most are real
>> data examples tracing individuals.
>>
>> All the best,
>>
>> Martin
>>
>> On 9/22/2021 4:31 PM, Mercedes Menendez Gonzalez wrote:
>>
>>
>>
>> Dear all,
>>
>>
>>
>> Although I am quite new to this, I would like to contribute my opinion on
>> this interesting topic, if I may.
>>
>> I agree that the most suitable option seems to be to create a class or
>> some new classes for non-human actors. Going back to Rob’s example, I would
>> say that the bird carries out an intentional action when it designs and
>> builds the nest with very specific purposes (to lay eggs that have a
>> specific size, to raise offspring).  We could even think on nest
>> construction as an individual action as well as a collective behavior.
>>
>>
>>
>> Best,
>>
>> Mercedes
>>
>>
>>
>> *I take the opportunity to thank you for the invitation to participate in
>> this forum and to introduce myself. I am Mercedes Menéndez, PhD candidate
>> in Art History at the University of Oviedo, Spain.
>>
>>
>>
>>
>>
>> Enviado desde Correo <https://go.microsoft.com/fwlink/?LinkId=550986>
>> para Windows
>>
>>
>>
>> *De: *Martin Doerr via Crm-sig 
>> *Enviado: *Tuesday, September 21, 2021 9:16 PM
>> *Para: *crm-sig@ics.forth.gr 
>> *Asunto: *Re: [Crm-sig] New Issue: Non-human Actors
>>
>>
>>
>> Dear Robert,
>>
>> I support this.
>>
>> I suggest the non-human Actors to go into CRMsci. It is a straightforward
>> extension of scope, and has been discussed in the past. Non-human actors
>> cannot be hold liable, and will not report. They are obviously a sibling to
>> the human actors, and fall under a common generalization. In the same way,
>> we have generalized over physical things in CRMsci.
>>
>> I think any opinion that animals in general cannot take intentional
>> actions has been proven non-sense. Conversely, human actions are often
>> enough instinct driven.
>>
>> So far, I do not think we have evidence of conceptual objects created by
>> non-human actors. Whales may turn out having oral traditions in the future.
>> Bird songs are, however, partially tradition and not innate, but we miss
>> the creator individual...
>>
>> Best,
>>
>> Martin
>>
>> On 9/21/2021 5:13 PM, Robert Sanderson via Crm-sig wrote:
>>
>>
>>
>> Dear all,
>>
>>
>>
>> In working with our natural history museum, we have a need to assign
>> non-human "actors" to "activities", which is not currently possible.
>>
>>
>>
>> I think the easiest case to discuss is the construction of a (collected)
>> nest by a (known individual) bird.
>>
>>
>>
>> We have an identity for the bird (and indeed, we have the remains of the
>> bird!) and we have an identity for the nest that the bird constructed. We
>> can estimate the time when the nest was made, and we know exactly where it
>> was made (due to where it was collected from).
>>
>> For example:
>> https://collections.peabody.yale.edu/search/Record/YPM-ORN-131036
>>
>> Or a dinosaur nest, where the adult and the eggs and the nest are
>> preserved.
>>
>>
>>
>> If the bird (or dinosaur) could be an Actor, then it would be easy - the
>> bird carried out a Production, during the TimeSpan, which produced the
>> (coughcough)MadeObject, at the Place. However the only thing that can carry
>> out activities is a human or group thereof.
>>
>>
>>
>> Similarly, the nest might have been built by a mated pair of birds,
>> thereby requiring a Group-like construct for non-human actors as well.
>>
>>
>>
>> At the moment it seems like the best we can do is
>> (beginning-of-existence-of-nest)  P12 occurred in the presence of
>> (bird-as-biological-object), which seems woefully inadequate semantically
>> as it likely occurred in the presence of a lot of things, including other
>> birds that didn't actually do anything. The closer subproperty is P11 had
>> participant, which we can't use as birds cannot be actors.
>>
>>
>>
>> This might also relate to other discussions, in particular:
>>
>> * Instruments -- the instrument is somehow more responsible for the
&

Re: [Crm-sig] New Issue: Non-human Actors

[Robert Sanderson via Crm-sig]

Could it be kept open until there's a clear cost / benefit established,
rather than philosophy around free will?

For example, if the ontology allows things that should be perdurants to
become endurants through agency, then we've messed up a fundamental design
decision. For example, a fire might "carry out" the destruction of an
object, but it's not an actor. But a self-driving car seems to have more
"agency" than the cyanobacteria "responsible" for creating stromatolites (
https://en.wikipedia.org/wiki/Stromatolite). A tiger escapes its enclosure
at a zoo and eats a child ... the tiger carried out the eating, but can't
be held legally accountable. The zoo on the other hand maybe could be ...
but the zoo did not eat the child.

There's lots to unpack ... it would be good to determine how far we can
unpack it as part of the process, while respecting core design values.

R


On Mon, Sep 27, 2021 at 3:59 PM Martin Doerr via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear Mercedes, all,
>
> My position is that machines are not actors. They are robots, that work on
> behalf of human actors, following human instructions. Their use is
> regulated by laws concerning those activating them, and not for suing the
> machine for its initiatives. There is no fundamental difference to setting
> up traps, no matter how complex the machine and its instructions are.
> Non-human actors should be restricted to living beings. Robots and traps
> and events set in action by them should be each a different category, and
> this is a nice, but different, challenge to model as well. Opinions?
>
> All the best,
>
> Martin
>
> On 9/25/2021 1:33 AM, Mercedes Menendez Gonzalez wrote:
>
> Thank you for the kind words, Martin.
>
> A brief try, could we find a good example in chess artificial
> intelligence? The human and the computer perform equivalent roles as
> (participants) players. For instance, the IBM computer named Deep Blue
> beated Kasparov in a well-documented match on May 11, 1997, at the
> Equitable Center in New York.
>
> Also, with my apologies if I am misunderstanding things.
>
> All the best,
>
> Mercedes
> --
> *De:* Martin Doerr  
> *Enviado:* miércoles, 22 de septiembre de 2021 22:14
> *Para:* Mercedes Menendez Gonzalez  ;
> crm-sig@ics.forth.gr  
> *Asunto:* Re: [Crm-sig] New Issue: Non-human Actors
>
> Dear Mercedes,
>
> Thank you for your good comments! What we would need now most are real
> data examples tracing individuals.
>
> All the best,
>
> Martin
>
> On 9/22/2021 4:31 PM, Mercedes Menendez Gonzalez wrote:
>
>
>
> Dear all,
>
>
>
> Although I am quite new to this, I would like to contribute my opinion on
> this interesting topic, if I may.
>
> I agree that the most suitable option seems to be to create a class or
> some new classes for non-human actors. Going back to Rob’s example, I would
> say that the bird carries out an intentional action when it designs and
> builds the nest with very specific purposes (to lay eggs that have a
> specific size, to raise offspring).  We could even think on nest
> construction as an individual action as well as a collective behavior.
>
>
>
> Best,
>
> Mercedes
>
>
>
> *I take the opportunity to thank you for the invitation to participate in
> this forum and to introduce myself. I am Mercedes Menéndez, PhD candidate
> in Art History at the University of Oviedo, Spain.
>
>
>
>
>
> Enviado desde Correo <https://go.microsoft.com/fwlink/?LinkId=550986>
> para Windows
>
>
>
> *De: *Martin Doerr via Crm-sig 
> *Enviado: *Tuesday, September 21, 2021 9:16 PM
> *Para: *crm-sig@ics.forth.gr 
> *Asunto: *Re: [Crm-sig] New Issue: Non-human Actors
>
>
>
> Dear Robert,
>
> I support this.
>
> I suggest the non-human Actors to go into CRMsci. It is a straightforward
> extension of scope, and has been discussed in the past. Non-human actors
> cannot be hold liable, and will not report. They are obviously a sibling to
> the human actors, and fall under a common generalization. In the same way,
> we have generalized over physical things in CRMsci.
>
> I think any opinion that animals in general cannot take intentional
> actions has been proven non-sense. Conversely, human actions are often
> enough instinct driven.
>
> So far, I do not think we have evidence of conceptual objects created by
> non-human actors. Whales may turn out having oral traditions in the future.
> Bird songs are, however, partially tradition and not innate, but we miss
> the creator individual...
>
> Best,
>
> Martin
>
> On 9/21/2021 5:13 PM, Robert Sanderson via Crm-sig wrote:
>
>
>
> 

Re: [Crm-sig] URI Management [Issue 460]

[Robert Sanderson via Crm-sig]

Reordering to most important first..


> *(C) BASE URI (NAMESPACE) FOR CLASSES AND PROPERTIES *What base URI
> should we use for the classes and properties of each version when serving
> RDF content? There are three options:
> *Option B1*. Always use an unversioned base URI, i.e.,
> http://www.cidoc-crm.org/cidoc-crm/ for all ontology versions.



This is the correct answer, according to 2 decades of RDF / Semantic Web
experience.
In particular, FOAF, one of the earliest RDF ontologies and written by one
of the original authors for RDF Dan Brickley, warns us in the specification:

Much of FOAF now is considered stable. Each release of this specification
document has an incrementally increased version number, even while the
technical namespace ID remains fixed and includes the original value of
"0.1". *It long ago became impractical to update the namespace URI without
causing huge disruption to both producers and consumers of FOAF data. *We
are left with the digits "0.1" in our URI. This stands as a warning to all
those who might embed metadata in their vocabulary identifiers.

(emphasis added). http://xmlns.com/foaf/spec/

Please, do NOT put a version number into the URIs. It makes everyone's
lives worse, and breaks interoperability between systems. It also makes it
much harder for people to upgrade systems and retract/republish data,
meaning we will leave folks behind in previous versions. It also makes it
harder to aggregate data, as the same property (say, P2) has different URIs
in different systems.

I would go so far as to say that, given we already have different RDFS and
OWL namespaces, that if there was further fragmentation, it would further
harm adoption and most users would simply pick the one that was easiest for
them given the already incompatible URIs.

In looking at similar topics (XML namespaces, API versions) the results are
the same -- URIs should be persistent, and versions / dates make them
either less persistent or appear out of date, both of which are harmful.

Thanasis has already made a point about not using versioned base URI:
> *"I am suggesting that classes do not need versions at all. Doing
> reasoning on a per class and per version basis would be bad practice, no?
> One would expect that the whole RDF/OWL representation would be used for
> reasoning. I think class URIs are only used as identifiers. This also
> avoids the problem of ensuring correct older versions for deprecated
> classes."*
> Thanasi, could you please elaborate more on this? It's not clear to us
> why/how reasoning considering a particular ontology version is affected
> when versioned URIs are used for the classes and properties.


As above, but Thansis is 100% correct - URIs are used as identifiers. We
wouldn't change the numbers in the ontology (E22, P2 etc) ... in RDF the
URI has the same function.


On Mon, Sep 27, 2021 at 6:41 AM Pavlos Fafalios via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear all,
>
> We (at FORTH) have started working on the URIs management issue, i.e. on
> how to provide resolvable URIs for the different versions of CIDOC-CRM and
> its compatible models. We would like to hear you opinion about the
> following:
>
> *(A) HAVING BOTH UNVERSIONED AND VERSIONED ONTOLOGY URIS  *
>
> The URI http://www.cidoc-crm.org/cidoc-crm/ will always resolve to the *last
> official* version of CIDOC-CRM ('official' according to the definition
> here ).
> *A question (also raised by George) is if we want to point to the last
> 'published' version* (which is *"a stable version of the standard and can
> be used for implementation, referencing and any other official purpose"*).
>
> In parallel, each version will have its own versioned URI, e.g.,
> http://cidoc-crm.org/cidoc-crm/7.1.1/ for version 7.1.1,
> http://cidoc-crm.org/cidoc-crm/6.2.9/ for version  6.2.9, etc. etc.
>

Yes. Best practice would be that the documentation for each version has a
separate URI, and a common URI can be used to always refer to the latest
version.
See: https://www.w3.org/2005/05/tr-versions

This is less important than (C) (people are better at concluding identity
than machines!) but still important :)



> *(B) SERVING HTML OR RDF (BASED ON HTTP REQUEST TYPE)*
>
> Different content will be served based on the type of the HTTP request.
> So, if one asks for
>http://www.cidoc-crm.org/cidoc-crm/
> will get either the HTML content
>  of the last
> official version (using text/html content type),
> or the RDFS of the last official version (using rdf/xml content type).  We
> will do the same for also the versioned URIs.
>

Excellent.



> Now, if one requests a specific class or property, e.g.:
>http://www.cidoc-crm.org/cidoc-crm/E5_Event
> will either navigate to the part of HTML content of the last official
> version which describes this particular class
>  

[Crm-sig] New Issue: Non-human Actors

[Robert Sanderson via Crm-sig]

Dear all,

In working with our natural history museum, we have a need to assign
non-human "actors" to "activities", which is not currently possible.

I think the easiest case to discuss is the construction of a (collected)
nest by a (known individual) bird.

We have an identity for the bird (and indeed, we have the remains of the
bird!) and we have an identity for the nest that the bird constructed. We
can estimate the time when the nest was made, and we know exactly where it
was made (due to where it was collected from).
For example:
https://collections.peabody.yale.edu/search/Record/YPM-ORN-131036
Or a dinosaur nest, where the adult and the eggs and the nest are preserved.

If the bird (or dinosaur) could be an Actor, then it would be easy - the
bird carried out a Production, during the TimeSpan, which produced the
(coughcough)MadeObject, at the Place. However the only thing that can carry
out activities is a human or group thereof.

Similarly, the nest might have been built by a mated pair of birds, thereby
requiring a Group-like construct for non-human actors as well.

At the moment it seems like the best we can do is
(beginning-of-existence-of-nest)  P12 occurred in the presence of
(bird-as-biological-object), which seems woefully inadequate semantically
as it likely occurred in the presence of a lot of things, including other
birds that didn't actually do anything. The closer subproperty is P11 had
participant, which we can't use as birds cannot be actors.

This might also relate to other discussions, in particular:
* Instruments -- the instrument is somehow more responsible for the
measurement than the thing being measured. It is at least "instrumental in"
the measurement, be it digitally or mechanically.
* Bias -- that animals cannot take intentional actions is a pretty biased
viewpoint. Canis virum mordet, not only vir canem mordet. This might be
extended to un-observable agents -- a culture might believe that a ghost,
spirit, god, or other non-physical entity carried out some action.
* Software "agents" -- even if the software is acting totally
deterministically at the behest of another actor, a hard determinist might
argue the same for humans.

We could add a property either something like "instrumental in" with a
broad range (Persistent Item, as super-class of Actor?) that is less about
intent and responsibility, and more concerned with the required-ness of the
entity for the event. Or we could go further and create some new classes
between E77 and E39 that allow limited performance of activities by non
Humans.


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] RDFS, XML and more

[Robert Sanderson via Crm-sig]

Thanks Martin :)

As Francesco asked and Thomas answered, I would also recommend a property
chain axiom that says:

If: x rdfs:label y
then: x P1_is_identified_by z ; z a E41_Appellation ,
P190_has_symbolic_content y .

I quickly defer to those who do OWL more often than I, but I think it's as
easy as:

rdfs:label owl:propertyChainAxiom (crm:P1_is_identified_by,
crm:P190_has_symbolic_content) .

Rob


On Thu, Sep 9, 2021 at 4:18 PM Martin Doerr  wrote:

> Sorry, I just forgot:
>
> Of course we can provide guidelines and S/W how to query all names etc.
> We can hardly forbid CRM users to put appellations into rdfs:label.
>
> So, how do this problem solved in OWL? Those of you opposing to the
> superproperty hack, how do you solve the query question?
>
> Best,
>
> Martin
>
> On 9/9/2021 11:12 PM, Martin Doerr wrote:
> > Dear Robert, Mark,
> >
> > Of course this is not elegant schema design. Unease is accepted, but
> > what are the alternatives??
> >
> > On 9/9/2021 10:30 PM, Robert Sanderson wrote:
> >>
> >>
> >>
> >> As expected, it entails the nonsense that the literal "fish"@en is an
> >> E1, E41, E90, etc. which is garbage caused by this pollution in the
> >> ontology, as literals cannot be the subject of triples.
> > This is, in my eyes, not nonsense, but simply reality. The literal
> > "fish" is used as a name. Hence it is ontologically an E41. Following
> > the definition of E90, "fish"@en is also symbolic object, regardless
> > whether one distinguishes data objects and literals. Note, that the
> > definitions of the CRM are ontological, not syntactic in the first place.
> >
> > This is a classical problem of data integration, and why formal
> > ontologies were invented. Literature in the 1980ties discussed that
> > classes can be hidden in boolean values, strings, or be explicit
> > tables. There is an arbitrary decision of applications to name things
> > via labels, or via classes in RDF/OWL. SKOS exclusively names things
> > via labels.
> >
> > So, if one makes a knowledge base that commits to the CRM, I would
> > like to have a query that returns all names in the whole world I can
> > reach, regardless what encoding variant and KR paradigm is used.
> > Otherwise, SKOS names will not be appellations.
> >
> > Alternatively, we close our eyes, and hard code in data entry and
> > query that "fish" is used as Appellation, but just don't write it down.
> >
> > @en actually is equivalent to "has language" etc. With these hidden
> > properties RDFS itself violates the separation of Literals and data
> > objects.  It opens up a whole world of user-defined data objects
> > within Literals, with no logical connection to the data objects. This
> > is nothing than a bad later patch to a problem not initially
> > anticipated. How are these compatible with OWL reasoners?
> >
> > There is no elegant solution to providing an ontology that describes a
> > reality based on FOL to fitting it exactly with Schema languages.
> >
> > At least, this is how I perceive this problem, having seen enough
> > knowledge representation languages and information integration
> > literature from the eighties and implementations from the nineties on.
> >
> > For me, the question is completely practical: We have a CRM compatible
> > KB, a real platform. What is the simplest form that I get all names in
> > the KB back?  I have not seen a whole "RDF" world that my statement
> > label IsA P1 would turn upside down. Do you have one?
> >
> > Best,
> >
> > Martin
> >>
> >> Hope that helps explain my unease!
> >>
> >> Rob
> >>
> >
>
>
> --
> 
>   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
>
>

-- 
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] RDFS, XML and more

[Robert Sanderson via Crm-sig]

Here, my understanding of the entailments from both an RDFS perspective
(not invalid entailments, just makes it impossible to use) and OWL
(actually invalid).

RDFS 1.1 says the following:

If a property P is a subproperty of property P', then all pairs of
resources which are related by P are also related by P'. The term
super-property is often used as the inverse of subproperty. If a property
P' is a super-property of a property P, then all pairs of resources which
are related by P are also related by P'.

See: https://www.w3.org/TR/rdf-schema/#ch_properties

So, the assertion is that rdfs:label (P) is a sub property of
P1_is_identified_by (P'), therefore all resources which are related by
rdfs:label are also related by P1_is_identified_by.

Thus, if there is an assertion  rdfs:label "fish"^^xsd:string .
Then it is a valid inference that  P1_is_identified_by
"fish"^^xsd:string .

Now let's look at rdfs:range.  RDFS 1.1 says:

rdfs:range is an instance of rdf:Property
 that is used to state that *the
values of a property are instances of one or more classes.*

(emphasis added)

RDFS asserts:

The rdfs:range  of rdfs:label
is rdfs:Literal .

CRM asserts at line 1174 of the RDFS:

P1_is_identified_by rdfs:range E41_Appellation


Thus, if  rdfs:label "fish", then "fish" rdf:type rdfs:Literal,
crm:E41_Appellation .

Which as Martin says is not impossible, because E41_Appellation is not
declared as disjoint with rdfs:Literal ... it's just utterly meaningless
and very annoying to anyone who has to deal with it, because
crm:E41_Appellation is not a subclass of rdfs:Literal, and every practical
syntax explicitly distinguishes between literals and URI references. E.g.
there is a *syntactic* difference between the URI "http://example.com/1;
and the string "http://example.com/1; -- the former can be the subject of
triples, and the latter (like every literal) cannot.

So, by asserting that a predicate that has a declared range of a datatype
class is the sub property of a predicate that as a declared range of a
non-Datatype class, this entails that the object is both a datatype and a
resource, and *this cannot be serialized.*


In OWL, rdfs:label would be a DataProperty, and P1_is_identified_by would
be an ObjectProperty. DataProperty values MUST respect the lexical space of
the datatype, and this is where the problem happens, because the URI that
identifies the E41_Appellation is NOT in the datatype lexical space.
Further, a DataProperty and ObjectProperty *are* explicitly disjoint. In
5.8.1:

   - No IRI *I* is declared in *Ax* as being of more than one type of
   property; that is, no *I* is declared in *Ax* to be both object and
   data, object and annotation, or data and annotation property.

See: https://www.w3.org/TR/owl2-syntax/#Typing_Constraints_of_OWL_2_DL

As a demonstration, I attach a minimal schema derived from the current RDFS.

Then, using rdflib in python, using only RDFS entailment:

from rdflib import ConjunctiveGraph

from owlrl import RDFSClosure


g = ConjunctiveGraph()

g.parse("Downloads/minimal_schema.rdfs.xml", format="xml")

rdfs_sems = RDFSClosure.RDFS_Semantics(g, axioms=True, daxioms=True,
rdfs=True)

rdfs_sems.closure()

out = rdfs_sems.graph.serialize(format="ttl")

print(out.decode('utf-8'))

 ...

"fish"@en a crm:E1_CRM_Entity,

crm:E41_Appellation,

crm:E90_Symbolic_Object,

rdfs:Literal,

rdfs:Resource .

As expected, it entails the nonsense that the literal "fish"@en is an E1,
E41, E90, etc. which is garbage caused by this pollution in the ontology,
as literals cannot be the subject of triples.

Hope that helps explain my unease!

Rob

On Thu, Sep 9, 2021 at 12:48 PM Martin Doerr via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear Francesco,
>
> This is a complex issue, which has been discussed in length in 2018 and
> basically was spelled out in the implementation guidelines for RDFS by
> Richrad Light and me.
>
> All these questions you pose have been taken into account carefully. The
> text may need improvements, but I'd kindly ask all CRM-SIG members having
> respective questions to read it carefully and give us feedback.
>
> Let me explain just a bit here from the side of logic, which is tricky and
> not the usual reasoning we apply within the CRM:
>
> A superproperty is not equivalent to a subproperty. A superproperty is
> only implied by a subproperty.
>
>  Therefore: Once E41 Appellation has no necessary property, an instance of
> E41 Appellation without having a property of its own does not violate the
> range of the superproperty. Its just a poor case.
>
> (But it is completely true that rdfs:label is without properties. From the
> time of RDFS 1.1 on, which recommends the use of xsd values in literals,
> there are hidden properties in the label, such as the language tags.)
>
> This statement does also 

Re: [Crm-sig] RDFS, XML and more

[Robert Sanderson via Crm-sig]

Hi Mark,

Could you expand a little about "OWL is RDFS anyway"? The advantage of the
current RDFS file is that it's easy to understand and process as XML
without a full semantic stack. Once decorated with all of the owl details,
it becomes more complex. Apart from owl:inverseOf and perhaps
owl:ObjectProperty vs owl:DataProperty, is there anything else that would
be added? Cardinality? Definition of shortcuts using axioms / rules?

I'm curious also as to your thoughts on the rdfs:label / P1_identifies
issue?

Many thanks!

Rob


On Thu, Sep 9, 2021 at 6:45 AM Mark Fichtner  wrote:

> Dear Pavlos,
>
> to my knowledge up to now the ecrm is the official OWL-implementation of
> the CIDOC CRM. Automation of the process seems to be a good idea, however
> in the last years we could provide many feedback while we were implementing
> cidoc crm (style/writing mistakes but also logical inconsistencies etc.).
> We are currently working on 7.1.1 but are not completely done yet. I think
> we should not mix owl and rdfs on the rdfs-level because that simply would
> make the rdfs-file obsolete. If we do that we could just use OWL because it
> is rdfs anyway.
>
> Best
>
> Mark
>
> Am Di., 7. Sept. 2021 um 12:45 Uhr schrieb Pavlos Fafalios via Crm-sig <
> crm-sig@ics.forth.gr>:
>
>> Dear Robert,
>>
>> Thank you for your comments and feedback. Some answers inline:
>>
>> On Wed, Sep 1, 2021 at 4:40 PM Robert Sanderson 
>> wrote:
>>
>>>
>>> Miel, all,
>>>
>>> 4 issues below:
>>>
>>> (1) There is a 7.1.1 compatible JSON-LD context at:
>>> https://linked.art/ns/v1/linked-art.json
>>> The description for how the JSON keys are derived from the ontology is:
>>> https://linked.art/api/1.0/json-ld/#context-design
>>> Comments welcome and happy to contribute it to the SIG, and make only a
>>> secondary linked art context for the profile specific features!
>>>
>>
>> Please see my reply to Miel.
>>
>>
>>>
>>> (2) A second request from me ... it would be great to have owl:inverseOf
>>> between each of the property pairs in the ontology.
>>>
>>> e.g.
>>>
>>>   >> xml:lang="en">identifies>> xml:lang="de">bezeichnetείναι 
>>> αναγνωριστικό>> xml:lang="fr">identifie>> xml:lang="pt">identifica>> xml:lang="ru">идентифицирует>> xml:lang="zh">标识>> rdf:resource="E41_Appellation" />>> rdf:resource="E1_CRM_Entity" />*>> rdf:resource="P1_is_identified_by" />*  
>>>
>>>
>>>
>> Our intention was to provide a 'pure' RDFS implementation, since one of
>> our next steps is to provide a rich OWL implementation (and also automate
>> its production, as we do for RDFS).
>> Nevertheless, including this OWL property does not seem to cause any
>> problem and allows for at least some basic reasoning. Not sure if it is
>> better to provide it as a separate module/file, or just enrich the existing
>> file.
>>
>>
>>> And (3) a minor typo:
>>>
>>>   
>>> Linguistic Appellation
>>> 
>>> 
>>>   
>>>
>>> It was agreed that this was going to be E33_E41 to keep the numbers in
>>> order, and to coincidentally correspond to the two parts of the label (E33
>>> -> linguistic, E41-> appellation)
>>> Great if this could be fixed.
>>>
>>
>> Thanks for spotting, we will fix it.
>>
>>
>>>
>>> And (4) a concern. I don't think that it is good practice to make
>>> assertions about other ontologies' predicates:
>>> Line 1176 asserts:
>>>
>>>   http://www.w3.org/2000/01/rdf-schema#label;>
>>> 
>>>   
>>>
>>> So this means that all of the objects of instances of rdfs:label are,
>>> due to the range of P1_is_identified_by, suddenly instances of
>>> E41_Appellation.
>>> A system that does even basic inferencing will produce very different
>>> results, by assigning E41_Appellation as another class for all of the
>>> literals which are the object of rdfs:label.
>>>
>>> This doesn't affect me, because while inferencing is a good idea in
>>> practice in some domains with very tightly controlled data and precisely
>>> applied ontologies and vocabularies, I have yet to see any benefit at all
>>> from it in ours.
>>>
>>> Might I suggest as a compromise instead having this assertion published,
>>> but in a different rdfs file? That would make it more noticeable to people
>>> who might otherwise have no clue why their system was misbehaving all of a
>>> sudden, and also make it easier for it to be omitted from processing if it
>>> was not useful in practice. Then we're still making the assertion in an
>>> official, public capacity, but we're also giving agency to our users as to
>>> whether they want to use it.
>>>
>>
>> The reason for making this assertion is the fact that rdfs:label has been
>> widely used for providing names/appellations (without making use of "P1 is
>> identified by"). However, all these labels are (semantically) appellations
>> of the corresponding resources. So, using this subproperty declaration, a
>> system can use P1 together with an inference rule for retrieving both names
>> expressed using rdfs:label and instances 

Re: [Crm-sig] RDFS, XML and more

[Robert Sanderson via Crm-sig]

Dear Miel, all,

On Wed, Sep 8, 2021 at 4:11 AM Miel Vander Sande via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Op di 7 sep. 2021 om 09:38 schreef Pavlos Fafalios  >:
>
>> Having a JSON-LD serialization seems useful, given the increasing
>> adoption of this encoding format. We can start considering its
>> implementation once the RDFS is approved by CRM SIG.
>>
>
> When done right, it can make complex models like CIDOC-CRM look a lot less
> scary. I think the goal should not be a complete implementation of
> CIDOC-CRM in a single context, but rather lead to an entry-level format
> that can be expanded when necessary (json-ld allows you to do this). I'm
> working on similar examples for PREMIS OWL.
>

I agree that a well crafted context can greatly improve usability of the
ontology in modern software frameworks. This has been demonstrated very
clearly in different domains since the standardization of JSON-LD 1.0 in
2014. I'm very happy to put as much effort as needed into this.

However, I disagree about the goal. I feel that the SIG should provide a
context that covers the same set of classes and predicates as in the RDFS.
Composing multiple contexts together with no overlap would be extremely
error-prone, with little way to detect those errors. For Linked Art, we
started with two contexts ... the terms that we recommend from CRM in the
profile, and the second was all the other terms. If you wanted to stick
with just Linked Art, you imported one. If you wanted to use anything
extra, you also imported the rest. And even that level of composition was
highly frustrating for implementation, as you needed to know all of the
terms used in the document in order to know whether you should use one or
both. The easy solution was to always use both... defeating the purpose of
splitting them.

And the errors are difficult to detect because if a key in JSON-LD doesn't
match an entry in an included context, it is silently ignored. So data
would just disappear, and you had to go hunting through other people's
documents (the contexts) to figure out why.

By sticking to the same divisions as the RDFS files (e.g. one context for
base, one for sci, one for geo, etc) it would be straightforward to manage
from a publishing and consumption perspective at the ontology level, rather
than at an application profile level.

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

Re: [Crm-sig] Argument for an Instrument Class (and its property)

[Robert Sanderson via Crm-sig]

I'm happy to take a homework to write up DNA measurement with CRM and
Instruments in mind :)

[My wife used to work for Illumina , and then
for one of their biggest customers, and was part of the team that
discovered the markers that led to Grail ]

Rob


On Tue, Sep 7, 2021 at 12:47 PM Martin Doerr via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear All,
>
> Just to give you a picture of the diversity and complexity we discuss.
>
> Probably the high-end in complexity is a DNA - taxonomic distance
> measurement, a procedure, even though straightforward and deterministic,
> as I understand, with an great number of steps, a series of instruments
> subsequently used and possible errors in each one.
>
> Interesting also a LIPS / Raman analysis of painting colorants, which
> uses multiple instruments until the final result,  not reliably
> quantitative and including assumptions about a limited set of possible
> colorants that might be wrong.
>
> As the most simple ones we may have yard sticks, but the most exotic in
> simplicity I can think of are pyrometric cones. They are used worldwide
> to monitor ceramic firings in industrial kilns, pottery kilns, for a
> one-time measurement of the maximum temperature reached by firing a
> kiln. They are calibrated to one temperature only, but normally
> destroyed by the measurement.
>
> What is "one instrument", and are pyrometric cones and yardsticks
> instruments? What about body parts (ells, feet)
>
> Best
>
> Martin
>
> On 9/6/2021 1:59 PM, Athanasios Velios via Crm-sig wrote:
> > I think this would be a useful discussion and class. It has also been
> > proposed within the PARCOURS model although perhaps a tighter proposal
> > can be made.
> >
> > Thanasis
> >
> > P.S. The example for P103 could do with updating...
> >
> > On 01/09/2021 20:47, Martin Doerr via Crm-sig wrote:
> >> Hi George,
> >>
> >> I think this is a good idea, of course, we should first look at a
> >> more specific property, since "instruments" can be very
> >> heterogeneous, or we concentrate on measurement devices in a narrower
> >> sense.
> >>
> >> Best,
> >>
> >> Martin
> >>
> >> On 8/25/2021 12:53 PM, George Bruseker via Crm-sig wrote:
> >>> Dear all,
> >>>
> >>> I am working on a conservation science modelling project in which
> >>> the users document also their machinery. Something that comes up is
> >>> that they want to document the kind of property or variable that is
> >>> measured by the machine. This is a property of the machine, what it
> >>> can do (dunamis).
> >>>
> >>> We of course already have p103 was intended for
> >>> http://www.cidoc-crm.org/Property/P103-was-intended-for/version-7.1.1
> >>>  >
> >>>
> >>> I already make use of this for the purpose of documenting the
> >>> general kind of method the machine can be used for.
> >>>
> >>> But when you run the machine, it tests for certain variables and
> >>> produces a resulting output which is a digital record of a signal
> >>> carrying that variable.
> >>>
> >>> This reminds me of some elements from CRMSci and from CRMdig
> >>>
> >>> CRMSci has observations that look for property types:
> >>>
> >>> S4 Observation
> >>> O9 observed property type E55
> >>>
> >>> http://www.cidoc-crm.org/crmsci/sites/default/files/CRMsci%20v.1.3.pdf
> >>> <
> http://www.cidoc-crm.org/crmsci/sites/default/files/CRMsci%20v.1.3.pdf>
> >>>
> >>> We also have in CRMdig both a class for instruments (digital ones)
> >>>
> >>> D8 Digital Device
> >>>
> >>> and we again have a notion of an observation kind of event measuing
> >>> a kind of thing
> >>>
> >>> D11 Digital Measurement Event
> >>> L17 measured thing of type E55
> >>>
> >>> http://www.cidoc-crm.org/crmdig/sites/default/files/CRMdig_v3.2.1.pdf
> >>>  >
> >>>
> >>> So, anyhow, putting that all together, I note:
> >>>
> >>> people document their scientific machines and what they do
> >>> some of the properties pertain to the machine (it may measure only
> >>> these things)
> >>> there are several references to such a property already in crmsci
> >>> and dig but placed on the event.
> >>>
> >>> So I wonder, for discussion, is there an interest in an instrument
> >>> class (possibly beginning a bridge between sci and dig) which would
> >>> not just be a leaf node but have its own substantial properties. I
> >>> suggest a first one might be something like 'measures
> >>> property/variable of type'.
> >>>
> >>> This is not yet a proposal for such a thing, just an invitation to
> >>> discussion for those who are interested on the potential utility of
> >>> such an addition.
> >>>
> >>> Best,
> >>>
> >>> George
> >>>
> >>>
> >>> ___
> >>> Crm-sig mailing list
> >>> Crm-sig@ics.forth.gr
> >>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
> >>
> >>
> >> --
> >> 

Re: [Crm-sig] RDFS, XML and more

[Robert Sanderson via Crm-sig]

Miel, all,

4 issues below:

(1) There is a 7.1.1 compatible JSON-LD context at:
https://linked.art/ns/v1/linked-art.json
The description for how the JSON keys are derived from the ontology is:
https://linked.art/api/1.0/json-ld/#context-design
Comments welcome and happy to contribute it to the SIG, and make only a
secondary linked art context for the profile specific features!

(2) A second request from me ... it would be great to have owl:inverseOf
between each of the property pairs in the ontology.

e.g.

  identifiesbezeichnetείναι αναγνωριστικόidentifieidentificaидентифицирует标识**  


And (3) a minor typo:

  
Linguistic Appellation


  

It was agreed that this was going to be E33_E41 to keep the numbers in
order, and to coincidentally correspond to the two parts of the label (E33
-> linguistic, E41-> appellation)
Great if this could be fixed.

And (4) a concern. I don't think that it is good practice to make
assertions about other ontologies' predicates:
Line 1176 asserts:

  http://www.w3.org/2000/01/rdf-schema#label;>

  

So this means that all of the objects of instances of rdfs:label are, due
to the range of P1_is_identified_by, suddenly instances of E41_Appellation.
A system that does even basic inferencing will produce very different
results, by assigning E41_Appellation as another class for all of the
literals which are the object of rdfs:label.

This doesn't affect me, because while inferencing is a good idea in
practice in some domains with very tightly controlled data and precisely
applied ontologies and vocabularies, I have yet to see any benefit at all
from it in ours.

Might I suggest as a compromise instead having this assertion published,
but in a different rdfs file? That would make it more noticeable to people
who might otherwise have no clue why their system was misbehaving all of a
sudden, and also make it easier for it to be omitted from processing if it
was not useful in practice. Then we're still making the assertion in an
official, public capacity, but we're also giving agency to our users as to
whether they want to use it.

Thanks for your hard work on this!

Rob







On Wed, Sep 1, 2021 at 8:44 AM Miel Vander Sande via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Thanks to all involved for this contribution. This is indeed an important
> step towards adoption.
>
> I was wondering: is a SHACL profile and a JSON-LD context being considered?
>
> Op wo 1 sep. 2021 om 10:19 schreef Pavlos Fafalios via Crm-sig <
> crm-sig@ics.forth.gr>:
>
>> Dear all,
>>
>> The "Resources" page of the CIDOC-CRM website (
>> http://www.cidoc-crm.org/versions-of-the-cidoc-crm) has been recently
>> updated to include:
>>
>> - An *RDFS implementation* (*not yet approved by SIG*) of the last
>> official version of CIDOC-CRM (7.1.1). The link points to a gitlab web page
>> which also includes the policies adopted for generating the RDFS file.
>> - An *XML file* for each version of CIDOC-CRM, including the classes and
>> properties of the corresponding version.
>> - An *HTML page* for each version of CIDOC-CRM, containing declarations
>> for all classes and properties (facilitating navigation to the classes and
>> properties of each version).
>> - An HTML page for each version of CIDOC-CRM, containing *translations *and
>> *versioning *information of all classes and properties.
>>
>> We (at FORTH) believe that the above will facilitate the adoption of
>> CIDOC-CRM.
>>
>> We will start gathering comments about errors, improvements, etc., so
>> please do not hesitate to provide your critical feedback.
>>
>> All the above will be presented and discussed during the next CIDOC-CRM
>> meeting.
>>
>> Best regards,
>> Pavlos
>>
>> --
>> Dr. Pavlos Fafalios
>> Postdoctoral research fellow
>> Project ReKnow  (MSCA Individual Fellowship
>> )
>>
>> Centre for Cultural Informatics / Information Systems Laboratory
>> Institute of Computer Science (ICS)
>> Foundation for Research and Technology (FORTH)
>>and
>> Visiting Lecturer
>> Department of Management Science & Technology (MST),
>> Hellenic Mediterranean University (HMU)
>>
>> Address: N. Plastira 100, Vassilika Vouton, 70013 Heraklion, Greece
>> Email: fafal...@ics.forth.gr
>> Tel: +30-2810-391619
>> Web: http://users.ics.forth.gr/~fafalios/
>>
>> ___
>> 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
>


-- 
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] Modelling 'Transcription' Advice?

[Robert Sanderson via Crm-sig]

What about:

 A a E33_Linguistic_Object ;
  P94i_was_created_by Creation .
Creation a E65_Creation ;
  p2_has_type or p32_used_general_technique  ;
  p16_used_specific_object B .

Rob



On Tue, Jul 20, 2021 at 5:58 AM George Bruseker via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear all,
>
> Just a general question to the crowd.
>
> Sometimes one has transcribed data of a very simple form.
>
> A is supposed to represent B and it has been copied by someone with the
> intention of so doing.
>
> A is a transcription of B
>
> A [E33] is a transcription of B [E33]
>
> This could be modelled numerous ways using CIDOC CRM. If one is looking
> for the most direct/binary way, I suppose that the only choice is "p130
> shows features of". If you wanted to capture the mode of relation then you
> would use p130.1 has type and indicate 'transcription'.
>
> I notice, however, that we do have 'has translation' as a sub property of
> P130 shows features of, as an apparently useful to the community binary
> property specializing P130 to that specific scenario.
>
> Has anyone else done modelling of transcriptions before with the aim of
> not recording the event but only the binary relation and if so, did you
> come up with any interesting solutions?
>
> A property would be handy in case anyone has created and published a
> specialization that could just be reused?
>
> Thanks for any insight! Maybe I miss an obvious trick from LRM?
>
> All the best,
>
> George
> ___
> 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

Re: [Crm-sig] Proposal/though: Add URLs to official documentation

[Robert Sanderson via Crm-sig]

Wholehearted agreement. Even if they're expressed in different ways by
different representations of the conceptual model, if we can standardize
the URI then an RDFS description and an OWL description of *the same URIs*
can be used by different communities without breaking interoperability. If
we get RDF*, or other declarative technological models for describing graph
structures, then they too could describe the use of the URIs in their
contexts.

Rob

On Tue, Jul 20, 2021 at 6:03 AM George Bruseker via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear all,
>
> Many people try to use the CIDOC CRM in order to build sustainable,
> reusable data sources and connect into a wider linked open data web.
>
> When they do so, they would like to easily be able to find / use the URIs
> for the classes and properties that the standard declares.
>
> The official documentation does not include this information in a handy
> way.
>
> Proposal for discussion: include the URIs for the classes and properties
> as clickable links that resolve to the online space where they are
> maintained in the word/pdf specification.
>
> Discuss!
>
> Best,
>
> George
> ___
> 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

Re: [Crm-sig] E-vote for issue 493 (example templates)

[Robert Sanderson via Crm-sig]

YES

On Fri, Jun 18, 2021 at 5:51 AM Athanasios Velios via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear all,
>
> This issue is about agreeing a rationale and a template based on which
> CRMbase and CRM extension examples will be produced. The working document
> for this issue is here:
>
>
> https://docs.google.com/document/d/1-PIIjXkDul1F0A7AoA4S95H0qY2CY9a7BKa1HK7wicA/edit?usp=sharing
>
> The homework including annotated templates is here:
>
> odt:
> https://drive.google.com/file/d/1YtZBSx5ZCOQ5ntFUf34TY-_aeR4OIrJY/view?usp=sharing
>
> docx:
> https://drive.google.com/file/d/1S6ZAy7Y3TO2ndNtJNkf-NrFeMpVNnXAj/view?usp=sharing
>
> The vote is to decide on whether to adopt the homework document.
>
> The possible votes are:
>
>- Yes = accept/agree
>- No = do not accept/agree
>- Other = With other you can either introduce a caveat (e.g.: 'Yes,
>but there is a typo on word x, fix it.') or you can write VETO, if you wish
>to stop the proposal, in which case you should also write a justification
>and reformulate the issue (e.g.: 'VETO, this change is unacceptable because
>it violates the following principle...')
>
> Please send your e-votes by the 28th of June.
>
> All the best,
>
> Thanasis
> ___
> 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

Re: [Crm-sig] E-vote for issue 384 (template for family models)

[Robert Sanderson via Crm-sig]

YES.

Happy (after the SIG, due to timing) test this out in practice by trying to
write up the Linked Art ontology extensions using it.

Rob


On Fri, Jun 18, 2021 at 6:02 AM Athanasios Velios via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear all,
>
> This issue is about agreeing a template based on which the specification
> documents of CRM family models will be produced. The working document for
> this issue is here:
>
>
> https://docs.google.com/document/d/1N09On4q4j4c8mIvSfMZTsWk-vsUIkdn2jRIzBlW8smU/edit?usp=sharing
>
> The proposed template is here:
>
>
> https://drive.google.com/file/d/1xWq1SIcoSNMmmwpO3TfE6LTC9cYsRapy/view?usp=sharing
>
> The vote is to decide on whether to adopt the template document. The main
> change from the existing template is the inclusion of a table for class and
> property dependencies to allow clear references to other models without
> repeating material and while keeping track of different versions.
>
> The possible votes are:
>
>- Yes = accept/agree
>- No = do not accept/agree
>- Other = With other you can either introduce a caveat (e.g.: 'Yes,
>but there is a typo on word x, fix it.') or you can write VETO, if you wish
>to stop the proposal, in which case you should also write a justification
>and reformulate the issue (e.g.: 'VETO, this change is unacceptable because
>it violates the following principle...')
>
> Please send your e-votes by the 28th of June.
>
> All the best,
>
> Thanasis
> ___
> 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] NEW ISSUE: Groups and carried out by

[Robert Sanderson via Crm-sig]

Dear all,

A recent discussion in the Linked Art group led to a question that we
couldn't resolve about the nature of Groups with respect to activities.

It seems to us that there are some distinct use cases for Group, that have
different implications for what is meant by an Activity is carried out by
that Group.

There is a formal or informal organization that can, as a single entity, be
reasonably attributed with the carrying out of some activity. Some examples:

Offices -- The President of the US wrote an executive order. Assuming
(surely incorrectly) that the president actually wrote the order rather
than an aide, then only one actual Person did the work as there's only one
member of the group at the time the activity was carried out. So having the
knowledge of Joinings and Leavings of the Group, we would know exactly
which person was involved.

Small, Named Groups --  "The Beatles" (E74 Group) carried out (p14) the
performance (E7) of their song "Hey Jude" (Exx Auditory Item). Here it
seems reasonable to attribute the performance to the group as a whole,
rather than the individual members ... Ringo, Paul, George & John.
Attributing the Group doesn't let us know which individuals actually
participated, but if we had the Joining and Leaving activities, we could
calculate the possible participants with a reasonable assumption that they
all participated to some degree.

Scriptorium of, Workshop of, Circle of, Studio of, ... -- The painting was
created by the workshop of Rembrandt.  We know that some member(s) of the
group carried out the activity, but also that not all members of the group
did it, and the group is not necessarily "named", rather constructed.

Organizations -- The Getty published AAT. Here the attribution of the group
seems reasonable, but there's no reasonable assumption that all members of
the group had anything to do with the activity. We probably don't know who
was involved, other than it's not everyone. So here carried out by is
really "This was carried out by one or more contemporary members of the
group in the name of the group"

Nationalities -- Arguable as to whether there is any coherent action of a
nationality, but assuming that an election is such a thing, then "The US
elected Joe Biden as President" definitely doesn't mean that all members,
even members at the time of the activity, participated.
Cultures seem similar, with regards to carried out.

Subsets of Groups -- "Anonymous 17th Century Italians" seems to fall into
the Nationality use -- 17th C Italians is a subset of Italians -- but the
intent is that some small number of members of the group carried it out
rather than some large number of members.

This doesn't seem like a use for P14.1, as it's orthogonal to roles like
"master craftsman" or "translator" or "illuminator".

This also seems property rather than class specific: the ownership by a
group is clear as to the nature of the participation. Saying that the Getty
is current_owner_of a Painting really is The Getty as a legal entity, and
absolutely not the current people employed there.

So ...

Is there a need to distinguish the type of carried_out-ness further than we
already have for Groups?  For example something like 
Pxx_carried_out_by_member_or_members_of  meaning that the group is
standing for the set of possible actors that carried out the activity, as a
subPropertyOf P14 ?

Thoughts?  (And no need to add this to the coming SIG agenda unless there's
time and desire to discuss sooner rather than later)

Many thanks!

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] 50th CIDOC CRM SIG Meeting (22-25 June 2021)

[Robert Sanderson via Crm-sig]

My regrets, as mentioned at the last SIG, this conflicts with the IIIF
Conference: https://iiif.io/event/2021/annual_conference/

Rob

On Fri, Jun 11, 2021 at 3:44 AM Eleni Tsoulouha via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear all,
>
> As announced earlier on the SIG list, the* 50th CIDOC CRM & 43rd FRBR CRM
> SIG meeting* will take place between *22-25 June 2021* on Zoom.
> Below you may find a (very) draft outline of the meeting (i.e. subject to
> changes):
>
> 22 June: CIDOC CRM issues (14.00-18.00 CEST)
> 23 June: CRMsoc (& Business Model & Activity Plans), CRMsci (14.00-18.00
> CEST)
> 24 June: CIDOC CRM & LRMoo (14.00-18.00 CEST)
> 25 June: CRMarchaeo, CRMdig (14.00-18.00 CEST)
> Like last time, each day will be split into two sessions.
>
> *Please take a moment to fill in the **registration form
> **,
> if you haven't done so already*.
>
> The SIG would like to highlight that *there is room in the schedule for
> presentations on research and on-going projects / work related to CIDOC CRM*
> .
> If groups or individuals would like to present their work (and questions)
> involving CIDOC CRM, please contact Chrysoula
> or myself, to indicate that you would like
> to present, along with the topic of your presentation by Monday 13 June.
> Just a title for your presentation is needed, no abstract of additional
> information. Presentations usually take approximately half an hour and can
> be used as a means to engage the CRM community  as well as to receive input
> from  and offer experience to the CIDOC CRM SIG.
>
> Looking forward to seeing you at our next virtual CRM SIG.
>
> All the best,
> Eleni
> ___
> 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

Re: [Crm-sig] HW 496 - Recommending Types

[Robert Sanderson via Crm-sig]

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

[Crm-sig] HW 496 - Recommending Types

[Robert Sanderson via Crm-sig]

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

[Robert Sanderson via Crm-sig]

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

[Robert Sanderson via Crm-sig]

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

Re: [Crm-sig] Relationship CRMDig & PREMIS OWL

[Robert Sanderson via Crm-sig]

George Bruseker and I have also done some work to try and align the
Parthenos model with Linked Art, as a first step toward (hopefully)
bringing the results back to CRMdig.

CRMdig, in my opinion, is very messy and needs a complete overhaul.
Comparing Premis (v3), Parthenos and the Linked Art extension could be a
nice process to clean it up a bit.

Rob


On Tue, Apr 27, 2021 at 8:10 AM Franco Niccolucci via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear Miel
>
> the project PARTHENOS has developed a CRM-compliant extension of CRMdig
> which could be useful for you, called the PARTHENOS Entity Model (PEM).
>
> It adds several useful entities such as Project, Service, Software etc.
> further developing and specializing concepts already defined in CRMdig. It
> does not address explicitly the audiovisual domain, which could be an
> interesting add-on easily developed.
>
> PEM is fully described in the project deliverable D5.1, available from
> here:
>
> https://doi.org/10.5281/zenodo.2668433
>
> For any further information/clarification you can contact directly the
> deliverable authors or myself.
>
> Best wishes
>
> 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 27 apr 2021, alle ore 13:25, Miel Vander Sande via Crm-sig <
> crm-sig@ics.forth.gr> ha scritto:
> >
> > Hi all,
> >
> > I'm starting a datamodelling excersise at my organisation. We are an
> audiovisiual archive in Flanders, Belgium; we digitize, preserve and
> disseminate audiovisual material from Flemish cultural organisations.
> > I was looking into way to model our digitization and preservation flows.
> We use PREMIS to a certain extent, but the material we ingest is (or
> rather: could be) described using CIDOC CRM, hence CRMdig is quite
> interesting.
> >
> > Does anyone have some input on:
> > - what the current status of CRM dig is?
> > - whether there are efforts to align PREMIS/PROV to CRMdig?
> >
> > Best,
> >
> > Miel
> >
> > --
> >
> >
> >
> >
> >  Miel Vander Sande
> >  Data architect
> >
> > meemoo vzw | Kleindokkaai 9a | 9000 Gent | België | www.meemoo.be
> > T: +32 9 298 05 01 | M: +32 496 83 21 29
> >
> >
> > ___
> > 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
>


-- 
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] 511 e-vote

[Robert Sanderson via Crm-sig]

YES

Thanks everyone!

On Fri, Mar 19, 2021 at 6:42 AM Athanasios Velios via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear all,
>
> At the last session of the last CRM SIG meeting we discussed issue 511 and
> voted to accept the reduction of the range of property P39 measured from E1
> CRM Entity to E18 Physical Thing. Homework was assigned to check how scope
> notes and related properties are affected, recommend changes and call an
> e-vote for those. I am listing the required changes below. With regards to
> those changes, the possible votes are:
>
>- Yes = accept/agree
>- No = do not accept/agree
>- Other = With other you can either introduce a caveat (e.g.: 'Yes,
>but there is a typo on word x, fix it.') or you can write VETO, if you wish
>to stop the proposed change from happening, in which case you should also
>write a justification and reformulate the issue (e.g.: 'VETO, this change
>is unacceptable because it violates the following principle...')
>
>
> *1. E16 Measurement*
>
>
> Changed to clarify that E16 Measurement requires observation, including an
> update to an example and the removal of two examples.
>
> *From:*
>
> Subclass of:
>
> E13 <#m_-2834491951268162862__toc7577> Attribute Assignment
>
> Scope note:
>
> This class comprises actions measuring quantitative physical properties
> and other values that can be determined by a systematic, objective
> procedure of direct observation of particular states of physical reality.
> Properties of instances of E90 Symbolic Object may be measured by observing
> some of their representative carriers which may or may not be named
> explicitly. In the case that the carrier can be named, the property P16
> used specific object (was used for): should be used to indicate the
> instance(s) of E18 Physical Thing that was used as the empirical basis for
> the measurement activity.
>
> Examples include measuring the nominal monetary value of a collection of
> coins or the running time of a movie on a specific video cassette.
>
> The E16 Measurement may use simple counting or tools, such as yardsticks
> or radiation detection devices. The interest is in the method and care
> applied, so that the reliability of the result may be judged at a later
> stage, or research continued on the associated documents. The date of the
> event is important for dimensions, which may change value over time, such
> as the length of an object subject to shrinkage. Methods and devices
> employed should be associated with instances of E16 Measurement by
> properties such as P33 used specific technique: E29 Design or Procedure,
> P125 used object of type: E55 Type, P16 used specific object (was used
> for): E70 Thing, whereas basic techniques such as "carbon 14 dating" should
> be encoded using P2 has type (is type of): E55 Type. Details of methods and
> devices reused or reusable in other instances of E16 Measurement should be
> documented for these entities rather than the measurements themselves,
> whereas details of particular execution may be documented by free text or
> by instantiating adequate sub-activities, if the detail may be of interest
> for an overarching query.
>
> Regardless whether a measurement is made by an instrument or by human
> senses, it represents the initial transition from physical reality to
> information without any other documented information object in between
> within the reasoning chain that would represent the result of the
> interaction of the observer or device with reality. Therefore, inferring
> properties of depicted items using image material, such as satellite
> images, is not regarded as an instance of E16 Measurement, but as a
> subsequent instance of E13 Attribute Assignment. Rather, only the
> production of the images, understood as arrays of radiation intensities, is
> regarded as an instance of E16 Measurement. The same reasoning holds for
> other sensor data.
>
> Examples:
>
>- measurement of height of silver cup 232 on the 31st August 1997
>(fictitious)
>- the carbon 14 dating of the “Schoeninger Speer II” in 1996 [an about
>400.000 year old complete Old Palaeolithic wooden spear found in
>Schoeningen, Niedersachsen, Germany in 1995] (Kouwenhoven, 1997)
>- The pixel size of the jpeg version of Titian’s painting Bacchus and
>Ariadne from 1520–3, as freely downloadable from the National Gallery in
>London’s web page
>
>
>is 581600 pixels.
>- The scope note of E21 Person in the Definition of the CIDOC
>Conceptual Reference Model Version 5.0.4 as downloaded from
>
>
>consists of 77 words.
>
>
> In First Order Logic:
>
> E16(x) ⇒ E13(x)
>
> Properties:
>
> 

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
>