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
><https://ontome.net/class/262/namespace/6> which, as a subclass of crm:E7
>Activity <https://ontome.net/class/7/namespace/1>, 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 <https://ontome.net/class/365/namespace/3> 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
><https://ontome.net/class/365/namespace/3> 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) <https://ontome.net/property/1/namespace/1> 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
> <https://ontome.net/class/365/namespace/3> (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

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 <https://en.wikipedia.org/wiki/Yeshua>.[1]
>> <https://en.wikipedia.org/wiki/Josua#cite_note-1>[2]
>> <https://en.wikipedia.org/wiki/Josua#cite_note-2> Notable people with
>> this name include:
>>
>>- Josua Bühler <https://en.wikipedia.org/wiki/Josua_B%C3%BChler>
>>(1895–1983), Swiss philatelist
>>- Josua de Grave <https://en.wikipedia.org/wiki/Josua_de_Grave>
>>(1643–1712), Dutch draughtsman and painter
>>- Josua Harrsch <https://en.wikipedia.org/wiki/Josua_Harrsch>
>>(1669–1719), German missionary
>>- Josua Hoffalt <https://en.wikipedia.org/wiki/Josua_Hoffalt> (born
>>1984), French ballet dancer
>>- Josua Järvinen <https://en.wikipedia.org/wiki/Josua_J%C3%A4rvinen>
>>(1871–1948), Finnish politician
>>- Josua Koroibulu <https://en.wikipedia.org/wiki/Josua_Koroibulu>
>>(born 1982), Fijian rugby league footballer
>>- Josua Heschel Kuttner
>><https://en.wikipedia.org/wiki/Josua_He

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
>>> <https://cidoc-crm.org/Issue/ID-363-form-and-persistence-of-rdf-identifiers>
>>> ,
>>> 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
>>> ling

[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
&g

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>
> > <mailto:thana...@softicon.co.uk <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
> > 

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

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
> >  > <https://cidoc-crm.org/Entity/e80-part-removal/version-7.1.1
> > <https://cidoc-crm.org/Entity/e80-part-removal/version-7.1.1>>
> 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.
> >

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]

 I am not sure if we required a biologist to
>>> > be able to model the notion of Birth or Death. Did we not use a middle
>>> > level understanding of everyday objects and their documentation in
>>> > systems in order to be support the recording of standard kinds of
>>> > facts of interest to a researcher? Birth and Death are not high
>>> > concepts of when conception begins or when the soul leaves the body,
>>> > they are rough and ready everyday ideas of, there was a person and an
>>> > event led to its end, there was a person and an event led to its
>>> > death. How the case of modelling animals differs is not clear to me.
>>> > Did we bring in financial experts model the payment class? On which
>>> > issues we need an expert and on which issues not is not clear, nor is
>>> > that expertise counts. As Rob says, having many years of experience in
>>> > cultural heritage documentation and analysis of such systems does not
>>> > count? I would think in basic matters like this, it goes back to the
>>> > ground of coming to a common sense modelling in line with what is
>>> > considered the best state of knowledge regarding the world. We KNOW
>>> > that the best state of knowledge is not represented by the present
>>> > modelling because agency is not just attributed to human beings.
>>> > Therefore, we are presently deliberately out of synch with the best
>>> > state of knowledge. I would think it behooves (pun intended) us to
>>> > step up to the plate and get on to making it possible to express basic
>>> > facts about the world that can be and are referenced in CH data
>>> > systems (such as the existence of animals!).
>>> >
>>> > Best,
>>> >
>>> > George
>>> >
>>> > On Tue, Oct 12, 2021 at 1:19 AM Pat Riva 
>>> > wrote:
>>> >
>>> >> Hi Rob,
>>> >> Looking at the dates on Lassie and Misha, I see that they were
>>> >> created during the phase when people were trying this under an
>>> >> unwise modification to RDA, and not been revised since. This would
>>> >> no longer be valid under the latest RDA. And no one has bothered to
>>> >> propose MARC coding specific to this type of heading, leading to the
>>> >> ones that were created being shoe-horned into the personal name
>>> >> coding. The proportion of the huge LC names file is too small.
>>> >>
>>> >> As for the fictitious, that was a completely different argument
>>> >> that has also lasted years. Stems from a difficulty in
>>> >> distinguishing between a name and the reality behind it.
>>> >>
>>> >> But these two issues are frequently conflated in the library world
>>> >> by people trying to use discussion related to why one was invalid to
>>> >> imply the position on the other issue didn't make sense.
>>> >>
>>> >> The thing is that there is no problem about having a work about an
>>> >> animal or about a character (as a concept), or have photographs,
>>> >> films or sound recordings of an animal. but it doesn't make sense to
>>> >> set up a relationship where these own an item, publish a
>>> >> manifestation, write, compose or translate an expression, or create
>>> >> a work. So the relationship is other.
>>> >>
>>> >> And a person can choose a pseudonym of any sort (even one that
>>> >> evokes a pet name or is the same as a fictional character), that
>>> >> still doesn't make the person into a pet. Same as two people having
>>> >> the "same" name doesn't fuse them into a single human being in some
>>> >> sort of weird siamese twin situation.
>>> >>
>>> >> Anyhow, I just wanted to to point out that there has been a lot of
>>> >> ink spilled over these issues, to no real result.
>>> >>
>>> >> Pat
>>> >>
>>> >> Pat Riva
>>> >>
>>> >> Associate University Librarian, Collection Services
>>> >>
>>> >> Concordia University
>>> >>
>>> >> Vanier Library (VL-301-61)
>>> >>
>>> >> 7141 Sherbrooke Street West
>>> >>
>>> >> Montreal, QC H4B 1R6
>>> >>
>>> >> Canada
>>> >>
>>> >

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

[Robert Sanderson via Crm-sig]

d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=NJHbjnrxhwJY3hudaCNkl%2F8B0QFMo5lqKXqiir2RyhM%3D=0>
>
>
> https://www.theatlantic.com/magazine/archive/2019/03/what-the-crow-knows/580726/?utm_campaign=the-atlantic_medium=social_source=facebook
> <https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.theatlantic.com%2Fmagazine%2Farchive%2F2019%2F03%2Fwhat-the-crow-knows%2F580726%2F%3Futm_campaign%3Dthe-atlantic%26utm_medium%3Dsocial%26utm_source%3Dfacebook=04%7C01%7Cpat.riva%40concordia.ca%7C3d1d139359704ba3a2fa08d98cea74cd%7C5569f185d22f4e139850ce5b1abcd2e8%7C0%7C0%7C637695760889156001%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=otC6lhsQU9HtCPECQy%2BN1LWTv%2BA98AbIbggAfRUo2wQ%3D=0>
>
>
> https://www.theguardian.com/artanddesign/2021/oct/06/anicka-yi-tate-modern-turbine-hall-commission
> <https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.theguardian.com%2Fartanddesign%2F2021%2Foct%2F06%2Fanicka-yi-tate-modern-turbine-hall-commission=04%7C01%7Cpat.riva%40concordia.ca%7C3d1d139359704ba3a2fa08d98cea74cd%7C5569f185d22f4e139850ce5b1abcd2e8%7C0%7C0%7C637695760889156001%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=%2FRwZGzdfpyOdxUfCpLbg7NB9LWqOqsg1oA6Y4Tq%2FgC4%3D=0>
>
>
> All best,
>
> George
>
> On Mon, Oct 11, 2021 at 9:44 PM Martin Doerr  wrote:
>
> Dear Robert,
>
> Having collaborated with natural history museum colleagues for some years
> and designed a research infrastructure for biodiversity in Greece, I
> understand that they normally do not describe the actions of an individual
> in a way that information integration on the base of the individual's
> animal actions would be needed. They would rather state the fact that an
> individual of type A, showed individual behavior pattern B. They would
> integrate these data on a type base, and not on an individual base. We have
> at FORTH converted Darwin Core data of occurrences of individuals into
> CRMsci representations. That had so far covered the needs.
>
> A colleague in Britain had used, I think, CRM for modelling observations
> of Caledonian Crow observations. Since these crows do not travel, the
> relevant information access and exchange is still on a categorical level.
>
> Migratory birds tracking may be an application, but normally they do not
> describe other behavior than move, in which case we can use a Presence
> construct for the migration paths.
>
> Our collaboration with NHM showed that they often prefer not to use CRM
> for their observation data. In a large European Project, we were forced to
> cheat and rename all CRM concepts, so that they appeared under a "BIO"
> title.
>
> So, in short, we need an expert that would show us practice of modelling
> animal actions individually, and be willing to consider CRM...
>
> Cheers,
>
> Martin
>
> On 10/11/2021 9:13 PM, Robert Sanderson wrote:
>
>
> 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

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]

Yes, understood and agreed :) Was just trying to clarify the process. And
in particular, the properties (and class hierarchy) are very important.
Scope notes can be ignored by humans (at their peril), but it's much harder
to ignore the ontology definition.

For documentation practice, I think most systems I've seen would say that
software does things, especially in digital preservation where the
software's actions must be  auditable (if not accountable).  I do worry
about legal responsibility as a factor in deciding agency/non-agency
however, given different jurisdictions and legal systems, but I also
understand the rationale.

R


On Tue, Sep 28, 2021 at 8:34 AM Martin Doerr  wrote:

> Dear Robert,
>
> Please excuse my sloppy shorthand! Of course I meant that a machine
> capable of causing events in reaction to external stimuli in a controlled
> manner is a new class model, AND the reactive events are another new class
> which should be related, it didn't come to my mind it could be one
>
> I just expressed my opinion. I have not made any decision. E39 Actor
> clearly excludes machines and animals so far. My argument is neither
> philosophy about free will, nor an interpretation of the word "agency",
> which would be a linguistic argument.
>
> From a methodological point of view, the only thing  that matters are the
> properties we associate with these things in documentation practice.
> Practice, and not philosophy, is, e.g., that a machine cannot be sued, but
> those setting them up in this manner. This is different from suing the
> owner of a tiger.
>
> The first thing to look at, in a bottom-up manner we are committed to, is
> to make ontological distinctions, not extending existing concepts into new
> domains. There are, to my opinion, much more things that differentiate
> Actors and Activities from robots and their reactions which I have not
> listed.
>
> Only after we have carefully investigated that there are enough
> commonalities between originally distinct concepts, we can decide if they
> warrant a common superclass.
>
> Both I have not seen yet.
>
> Would that make sense?
>
> All the best,
>
> Martin
>
> On 9/27/2021 11:31 PM, Robert Sanderson wrote:
>
>
> 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 Menende

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 

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
> 

[Crm-sig] Issue 476: PXX represents entity of type

[Robert Sanderson]

Dear all,


The proposed, revised scope note, copied mostly from the issue which I
believe fulfils the requests from last SIG meeting's discussion, but please
let me know if any additional edits are needed:

This property establishes the relationship between an E36 Visual Item and
an E55 Type that represents the class of an entity which it visually
represents.  This property is used when the identity of the specific entity
being represented is unknown or unidentified beyond the content of the E36
Visual Item. Pxx represents entity of type is a shortcut of the more fully
developed path from the domain E36 Visual Item through P138 represents, E1
Entity, P2 has type, to the range E55 Type.

This property is most useful when there is an entity of some type being
depicted that is not identifiable as any particular individual, but is
clearly of a particular type. The image carried by a photograph of an
unknown garden would depict many flowers, but none of which are known as
entities beyond the photograph. Conversely, if there isn't an individual
that could fill the role of the E1 Entity in the fully developed path, then
this property is not appropriate, and a direct relationship of P138
represents from the E36 Visual Item to the E55 Type is recommended.

The manner or mode of the representation can be captured using Pxx.1 mode
of representation.

Examples:

The photograph’s visual content (E36) represents an entity of type
beach (E55)

The sculpture’s visual content (E36) represents an entity of type woman
(E55)

The landscape painting’s image content (E36) represents an entity of
type field (E55) in the manner of background (E55)


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

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

[Robert Sanderson]

Dear all,

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

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

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

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

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

Rob

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

Re: [Crm-sig] Issue 511

[Robert Sanderson]

On Wed, Mar 3, 2021 at 5:54 AM Martin Doerr  wrote:

> My argument about measuring non-physical things is that it does not
> constitute an observation process, but an abstraction from observable
> things. We can always use Attribute Assignment for such evaluations. So, we
> can assign the word count to a text, without using E16 Measurement.
>

Understood, and agreed. The scope note for E16 is clear that is for
measuring "physical properties ... by ... direct observation of particular
states".

A word count would be an Attribute Assignment of the Dimension to the
Linguistic Object, potentially using a particular specific object as a
witness for the symbols. Of course, I can count symbols in my head, but
then I am not observing the symbols physically, and therefore it is not a
Measurement.

If I am not able to be at the SIG session where this is discussed, please
count this as my vote in favor of the resolution of the issue.

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 511

[Robert Sanderson]

Martin wrote in particular:
  Reduce in CRMbase Mesaurement , P40 observed dimension, to E18 Physical
Thing. Add 3 different properties “has dimension” in CRMBase to E70 Thing,
E53 Place, E4 Period (or E2 Temp Entity).

I agree with your argumentation, and believe that the changes in CRM Base
would be:

P39 measured:
  Range changes from E1 CRM Entity to E18 Physical Thing

PXX1_has_dimension
  Domain: E53 Place
  Range: E54 Dimension

PXX2_has_dimension
  Domain: E4 Period
  Range: E54 Dimension

to be cognate with P43 has dimension for E70s.

The question would remain about the measuring of Non-physical Things, such
as the number of symbols in a E90 symbolic object... but I don't have that
use case, so am happy to leave the discussion to someone that does :)

Rob

On Tue, Mar 2, 2021 at 4:31 PM Martin Doerr  wrote:

>
>
> *Posted by Robert Sanderson on 9/9/2020*
>
> I believe that there is an inconsistency in the model for measurements and
> dimensions.
>
> E54 Dimensions are associated directly with E70 Things using P43 has
> dimension.  So not every class can have dimensions, only those that are
> descendents of E70.
>
> However E16 Measurement's property P39 measured has a range of E1 CRM
> Entity, meaning that while (for example) an E53 Place cannot have a
> dimension, it can be measured to have a dimension. This seems inconsistent
> that an entity that cannot have dimensions can still be measured.
>
> I propose that the range of P39 measured be changed to E70 Thing to
> resolve this inconsistency.
>
>
>
> We have to distinguish measurement from dimension. In order to measure
> something in a narrower sense, I need an observation of something material.
> Dimensions can also be result of computation, evaluation and estimation
> (forms of Attribute Assignment).
>
> If we look at measuring in the narrower sense, we can count the characters
> of a text on paper, but not the abstract text. The logical representation
> of a text can be evaluated for its dimensions.
>
> We cannot measure a place, but features at a place. See also Issue 388.
> But clearly, we can measure duration and extent of processes, and comparing
> a clock, which provides a duration from the last sync event, with some
> other transient situation or microevent, in order to calculate absolute
> time.
>
> So, we may assign the ability to be observed to E18 physical things and E4
> Period, or more narrowly to E5 Event.  The ability to be observed appears
> to need some common ontological nature, a certain materiality interacting
> with measurable signals. Even the lightning creates a plasma hose lasting
> some milliseconds. That would need a new class “Observable Entity” as range.
>
> Otherwise, we may regard measuring physical things and measuring processes *as
> independent*. Then, we would need *another measurement class*, such as
> “static measurement” versus “dynamic measurement”.
>
> Dimensions of other things, such as places in the abstract geometric sense
> of the CRM, need not be based on a common property. The place can only have
> diameters and areas as dimentions, and may be some more exotic ones. The
> dimension in the phenomenal timespan is of course that of the respective
> period etc. So, my argument being that E53 Place, E52 Time-Span have their
> own properties with range Dimension, without being regarded as observable
> (rather results of observation).
>
> I’d propose the following:
>
> Reduce in CRMbase Mesaurement , P40 observed dimension, to E18 Physical
> Thing. Add 3 different properties “has dimension” in CRMBase to E70 Thing,
> E53 Place, E4 Period (or E2 Temp Entity).
>
> Extent CRMSci by E18, E4 IsA Observable Entity, and extend Mesaurement P40
> observed dimension,  from E18 to Observable Entity.
>
> Alternatively, introduce “Dynamic Measurement”  in CRMSci.
> Best,
>
> Martin
>


-- 
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: Modelling provenance of Intangible Heritage

[Robert Sanderson]

Very interesting!

>From the wikipedia article, the Radif is:
a collection of old melodies that have been handed down by the masters
to the students through the generations

Which is very interesting if taken literally as it requires *two* classes
we don't have -- a collection class for non-physical things [dare I say in
this context that yes I am banging that drum?] and a class for a Melody to
parallel Visual and Linguistic sub-classes of Information Object.  Once
there is a set of melodies, this can be the specific object of the
activities where the tradition is passed on.

I wonder about the use of Type without further properties or activities, as
it's currently impossible to relate a concept to other classes.  An example
which came up here recently is the precoordinated headings with temporal,
personal and geographic facets ... for example "History (E55 Type) of 15th
Century (E4 Period) France (E53 Place)". Clearly History of 15th Century
France is a Type, but one that should be able to be related to the Period
and Place.

Rob




On Tue, Feb 23, 2021 at 3:10 PM Martin Doerr  wrote:

> Dear All,
>
> Massoomeh Niknia from Kharazmi University| Tehran, Iran brought this to my
> attention:
>
> "I have a list of Iranian Intangible cultural heritage works (E71) and
> each of them has an origin from one or more than one province (E53) of
> Iran. for example "Radif of Iranian music" belongs to a province which is
> called "Khorasan".
>
> I would like to know how can I make a relationship between the works (
> Iranian Intangible cultural heritage) to their origins. I suppose I need to
> show their relations by making an special activity (like belonging,
> influencing, etc.) but unfortunately I couldn't find such a property in the
> Model. "
>
> See also https://en.wikipedia.org/wiki/Radif_(music) and
> https://ich.unesco.org/en/RL/radif-of-iranian-music-00279 .
>
> I think that we have o consider a combination of the LRM concept of Work
> and modelling collective behavior. It may reach the limits of what we can
> do with modeling the past by identifiable individuals. It may also be
> regarded as an E55 Type? It should be connected to particular performance
> modelling, particular artists, may be even particular instruments.
>
> All the 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] Issue Visual Item 3D

[Robert Sanderson]

+1 -- in Linked Art we have already adopted this approach :)

(I think we already discussed in the SIG?)

R



On Thu, Dec 10, 2020 at 12:31 PM Martin Doerr  wrote:

> Dear All,
>
> I believe that E36 Visual Item should include the surface of statues.
> Therefore,
> I propose to change the scope note to:
>
> *NEW:*
> This class comprises the intellectual or conceptual aspects of
> recognisable marks*, images and other visual works.*
>
> This class does not intend to describe the idiosyncratic characteristics
> of an individual physical embodiment of a visual item, but the underlying
> prototype. For example, a mark such as the ICOM logo is generally
> considered to be the same logo when used on any number of publications. The
> size, orientation and colour may change, but the logo remains uniquely
> identifiable. The same is true of images that are reproduced many times.
> This means that visual items are independent of their physical support.
>
>  The class E36 Visual Item provides a means of identifying and linking
> together instances of E24 Physical Human-Made Thing that carry the same
> visual symbols, marks or images etc. The property *P62 depicts (is
> depicted by)* between E24 Physical Human-Made Thing and depicted subjects
> (E1 CRM Entity) is a shortcut of the more fully developed path from E24
> Physical Human-Made Thing through *P65 shows visual item (is shown by)*,
> E36 Visual Item, *P138 represents (has representation)* to E1CRM Entity,
> which in addition captures the optical features of the depiction.
>
> -
>
> And add the example:
>
> "The surface shape of Auguste Rodin's statue "Le Penseur" [there exist
> more than 20 copies, even of different size]
>
>
> *OLD:  *
>
> This class comprises the intellectual or conceptual aspects of
> recognisable marks, and visual  images.
>
> This class does not intend to describe the idiosyncratic characteristics
> of an individual physical embodiment of a visual item, but the underlying
> prototype. For example, a mark such as the ICOM logo is generally
> considered to be the same logo when used on any number of publications. The
> size, orientation and colour may change, but the logo remains uniquely
> identifiable. The same is true of images that are reproduced many times.
> This means that visual items are independent of their physical support.
>
>
>
> The class E36 Visual Item provides a means of identifying and linking
> together instances of E24 Physical Human-Made Thing that carry the same
> visual symbols, marks or images etc. The property *P62 depicts (is
> depicted by)* between E24 Physical Human-Made Thing and depicted subjects
> (E1 CRM Entity) is a shortcut of the more fully developed path from E24
> Physical Human-Made Thing through *P65 shows visual item (is shown by)*,
> E36 Visual Item, *P138 represents (has representation)* to E1CRM Entity,
> which in addition captures the optical features of the depiction.
>
> --
> 
>  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] quantification of .1 properties

[Robert Sanderson]

See my question here:
http://lists.ics.forth.gr/pipermail/crm-sig/2019-December/004100.html. ;)

If this is the case, can we change the example for P16.1 to not have the
";" ?  Instead it should be two different P16s to the same Object, each
with a different .1 ?

Rob


On Wed, Nov 18, 2020 at 4:59 AM Christian-Emil Smith Ore <
c.e.s@iln.uio.no> wrote:

> ​Sounds right. We should make a note somewhere in the introduction.
>
> Christian-Emil
> --
> *From:* Stephen Stead 
> *Sent:* 18 November 2020 09:50
> *To:* Christian-Emil Smith Ore; Crm-sig@ics.forth.gr
> *Subject:* RE: [Crm-sig] quantification of .1 properties
>
>
> Hi Christian-Emil
>
> I have always considered there to be only one possible .1 per instance of
> the base property. Any additional “complexity” can be dealt with in the
> Thesaurus supporting the E55 Type. Of course if you implement with the PC
> class then the world is your oyster!
>
> TTFN
>
> SdS
>
>
>
> Stephen Stead
>
> Tel +44 20 8668 3075
>
> Mob +44 7802 755 013
>
> E-mail ste...@paveprime.com
>
> LinkedIn Profile https://www.linkedin.com/in/steads/
>
>
>
> *From:* Crm-sig  *On Behalf Of *Christian-Emil
> Smith Ore
> *Sent:* 18 November 2020 08:27
> *To:* Crm-sig@ics.forth.gr
> *Subject:* [Crm-sig] quantification of .1 properties
>
>
>
> Dear all,
>
> What is the quantification of .1 properties? For example for  P3 has Note
> it can be useful to use more than one instanc eof the P3.1 has type: E55 Type​
> specifying.
>
> Best,
>
> Christian-Emil
>
>
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_7897990095516973258_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> 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] Homework from Issue 486: Scope note of O19, O21

[Robert Sanderson]

HW from the Oct 2020 SIG to review the scope notes for O19 and O21, given
the relabeling of the properties to use "encounter" rather than "found".

O19 current scope note:

This property associates an instance of S19 Encounter Event with an
instance of E18 Physical

Thing that has been found.


Proposed new scope note:

This property associates an instance of S19 Encounter Event with an
instance of E18 Physical Thing that was encountered or observed as present
during the event.

O21 current scope note:

This property associates an instance of S19 Encounter Event with an
instance of E53 Place at which an encounter event found things. It
identifies the narrower spatial location in which a thing was found at.
This maybe known or given in absolute terms or relative to the thing found.
It describes a position within the area in which the instance of the
encounter event occurred and found something.


Proposed new scope note:

This property associates an instance of S19 Encounter Event with an
instance of E53 Place at which the things which were encountered were
observed to be present. This may be given in absolute terms or in terms
relative to the observed thing. The referenced place must be within the
boundaries of the E53 Place at which the S19 Encounter Event P7 took place
at, if that is given.


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 426 Homework: Work on scope note for Pxx holds or supports

[Robert Sanderson]

Revised homework to make the examples real:


   -

   Archival folder “6” (E22) _holds or supports_ the piece of paper (E22)
   carrying the text of a letter from Lawrence Alloway to Sylvia Sleigh
   [reference:
   
http://archives2.getty.edu:8082/xtf/view?docId=ead/2003.M.46/2003.M.46.xml;chunk.id=aspace_ref12_kf7;brand=default
   ]
   - Archival folder "17" (E22) _holds or supports_ the daguerreotype (E22)
   that shows the image of Henry Ward Beecher as a young man [reference
   https://archives.yale.edu/repositories/12/archival_objects/1402266 ]
   - Box "88" (E22) _holds or supports_ folder "17" (E22) [Same reference]
   - Bookshelf “GRI-708.1” (E22) _holds or supports_ the book entitled
   “Catalog of Paintings in the J. Paul Getty Museum” (E22)


R


On Thu, Jun 25, 2020 at 9:50 AM Robert Sanderson 
wrote:

>
> Scope Note
>
> This property relates one instance of E18 Physical Thing which acts as a
> container or support for another instance of E18 Physical Thing. Typical
> examples of E18 Physical Things which are intended to function as a
> container or support include shelves, folders or boxes. These containers or
> supports provide a stable surface which is intended for other physical
> objects to be placed upon for storage, display, transport or other similar
> functions. Pxxx holds or supports is a shortcut of the more fully developed
> path from the domain E18 Physical Thing through P59 has section, E53 Place,
> P53i is former or current location of, to the range E18 Physical Thing.  It
> is not a sub-property of P46 is composed of, as the held or supported
> object is not a component of the container or support.
>
> This property can be used to avoid explicitly instantiating the E53 Place
> which is defined by an instance of E18 Physical Thing, especially when the
> only intended use of that instance of E18 Physical Thing is to act as a
> container or surface for the storage of other instances of E18 Physical
> Thing. The place’s existence is defined by the existence of the container
> or surface, and will go out of existence at the same time as the
> Destruction of the container or surface.
>
> Examples
>
>
>-
>
>Archival folder “6” (E22) _holds or supports_ the piece of paper (E22)
>carrying the text of a letter from Alloway to Sleigh
>-
>
>Artist’s materials box “VG6” (E22) _holds or supports_ Van Gogh’s
>paint brush 23 (E22)
>-
>
>Storage box “VG” (E22)  _holds or supports_ the artist’s materials box
>“VG6” (E22)
>-
>
>Bookshelf “GRI-708.1” (E22) _holds or supports_ the book “Catalog of
>Paintings in the J. Paul Getty Museum” (E22)
>
>
>
> And Christian-Emil kindly provided the first order logic:
>
> Pxx(x,y) ⊃ E18(x)
> Pxx(x,y)⊃ E18(y)
> Pxx(x,y) ⊂ (∃z) [E53(z) ˄ P59(x,z) ˄ P53i(z,y)]
>
>
> --
> Rob Sanderson
>


-- 
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: Change of Scope Note E10 Transfer of Custody (Issue 475)

[Robert Sanderson]

YES


On Tue, Oct 6, 2020 at 1:47 AM George Bruseker 
wrote:

> Dear all,
>
> In the last CRM SIG (47) we discussed issue 475
>  which has to
> do with a change to the scope note of E10 Transfer of Custody. R. Sanderson
> noted that the scope note seemed to contain a contradiction since the first
> line indicated that the transfer of custody was of 'physical possession'
> while the second paragraph indicated that it could be of physical
> possession OR only of legal custody.
>
> R. Sanderson proposed to update the scope note in order to consistently
> express that the base line case is that BOTH physical and legal custody are
> transferred and in the case that it is only one or the other this would be
> expressed using the p2 has type property.
>
> This proposal was generally accepted and the work of creating the precise
> wording was left as homework. This HW has been provided by R Sanderson and
> is in a good state for voting on.
>
> Please find below the text of the old and the new scope note. After having
> read them, please vote by replying to this email whether to accept this
> change.
>
> You may vote Yes, Yes with a caveat or No, indicating the reason for
> rejecting the proposal.
>
> Please indicate your vote by October 16th.
>
> Changes marked in *blue*
> -
>
> *OLD scope note*
>
> *E10 Transfer of Custody *
>
> Subclass of: E7 Activity
>
> Scope note: This class comprises transfers of physical custody of objects
> between instances of E39 Actor. The recording of the donor and/or recipient
> is optional. It is possible that in an instance of E10 Transfer of Custody
> there is either no donor or no recipient. Depending on the circumstances it
> may describe:
>
> 1. the beginning of custody
>
> 2. the end of custody
>
> 3. the transfer of custody
>
> 4. the receipt of custody from an unknown source
>
> 5. the declared loss of an object
>
> The distinction between the legal responsibility for custody and the
> actual physical possession of the object should be expressed using the
> property P2 has type (is type of). A specific case of transfer of custody
> is theft. The sense of physical possession requires that the object of
> custody is in the hands of the keeper at least with a part representative
> for the whole. The way, in which a representative part is defined, should
> ensure that it is unambiguous who keeps a part and who the whole and should
> be consistent with the identity criteria of the kept instance of E18
> Physical Thing. For instance, in the case of a set of cutlery we may
> require the majority of pieces having been in the hands of the actor
> regardless which individual pieces are kept over time.
>
> The interpretation of the museum notion of "accession" differs between
> institutions. The CIDOC CRM therefore models legal ownership and physical
> custody separately. Institutions will then model their specific notions of
> accession and deaccession as combinations of these.
>
> Examples:
>
>- the delivery of the paintings by Secure Deliveries Inc. to the
>National Gallery the return of Picasso’s “Guernica” to Madrid’s Prado in
>1981 (Chipp, 1988)
>
> In First Order Logic:
>
> E10(x) ⊃ E7(x)
>
> Properties:
>
> P28 custody surrendered by (surrendered custody through): E39 Actor
>
> P29 custody received by (received custody through): E39 Actor
>
> P30 transferred custody of (custody transferred through): E18 Physical
> Thing
>
> *NEW scope note*
>
> *E10 Transfer of Custody *
>
> Subclass of: E7 Activity
>
> Scope note: This class comprises transfers of the physical custody, or
> the legal responsibility for the physical custody, of objects. The
> recording of the donor or recipient is optional. It is possible that in
> an instance of E10 Transfer of Custody there is either no donor or no
> recipient. Depending on the circumstances it may describe:
>
> 1. the beginning of custody (there is no previous custodian)
>
> 2. the end of custody (there is no subsequent custodian)
>
> 3. the transfer of custody (transfer from one custodian to the next)
>
> 4. the receipt of custody from an unknown source (the previous custodian
> is unknown)
>
> 5. the declared loss of an object (the current or subsequent custodian is
> unknown)
>
> In the event that only a single kind of transfer of custody, either the
> legal responsibility for the custody or the actual physical possession of
> the object but not both, this difference should be expressed using the
> property P2 has type (is type of).  A specific case of transfer of
> custody is theft. The sense of physical possession requires that the object
> of custody is in the hands of the keeper at least with a part
> representative for the whole. The way, in which a representative part is
> defined, should ensure that it is unambiguous who keeps a part and who the
> whole and should be consistent with the identity criteria of the kept
> instance of E18 Physical Thing. For 

Re: [Crm-sig] E-Vote ( Issue 508 ): First Order Logic Representation of p170

[Robert Sanderson]

YES

On Tue, Oct 6, 2020 at 8:08 AM George Bruseker 
wrote:

> Dear all,
>
> In the last SIG, the issue of the accuracy of the FOL representation of
> P170 defines time (time is defined by) was raised in issue 508
> . A better FOL
> representation was sought for. MD was assigned the HW.
>
> The previous state was:
>
> P170 defines time (time is defined by)
> Domain: E61Time Primitive
> Range: E52 Time Span
> Quantification: many to one (0,1:0,n )
>
> Scope note: This property associates an instance of E61 Time
> Primitive with the instance of E52 Time-Span that constitutes the
> interpretation of the terms of the time primitive as an extent in absolute,
> real time.
>
> Examples:
> ▪(1800/1/1 0:00:00 – 1899/31/12 23:59:59)(E61) defines time The
> 19th century (E52)
> ▪(1968/1/1 – 2018/1/1)(E61) defines time “1968/1/1 – 2018/1/1”
> (E52) [an arbitrary time-span during which the Saint Titus reliquary was
> present in the Saint Titus Church in Heraklion, Crete]
>
> In First Order Logic:
>P170(x,y) ⇒ E61(x)
>P170(x,y) ⇒ E52(y)
>
> It is proposed to introduce:
>
>  P170(x,y) ⇒ P81(y,x) ˄ P82(y,x)
>
> Meaning: the respective time-span is exactly ongoing and within the given
> time primitive.
>
> Please vote on this change. Options: Yes, Yes with Caveat, No with
> Explanation, to this list.
>
> The vote should be received by Oct 16, 2020.
>
> Thank you for your effort.
>
> Sincerely,
>
> George Bruseker
> Vice Chair CIDOC 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] E Vote (Issue 404): Examples for E81-P123-P124

[Robert Sanderson]

NO

The examples are inconsistent with regards to the use of the class numbers,
both internally and in relation to other examples.

Secondly, the transformation should be physical -- the /use/ of a church as
a stable is not /necessarily/ a physical transformation. A clearer example
should be selected please.

Rob


On Tue, Oct 6, 2020 at 8:35 AM George Bruseker 
wrote:

> Dear all,
>
> In 11/2018 a discussion was started to revise the scope note of E81
> Transformation and to change the ranges of its relative properties p123 and
> p124. In brief, it was argued that the range of the class was too broad
> (E77 Persistent Item) and that it should be limited to E18 Physical Thing.
> This change was accepted. You can find the history here:
>
>
> http://www.cidoc-crm.org/Issue/ID-404-modification-of-scope-notes-and-ranges-for-e81-p123-p124
>
> To support the new definition of the class and its properties new examples
> were sought after. The HW was assigned to ET and AK. They have come up with
> the following examples for the classes and relations in question.
>
> The proposed examples are to be found in the text pasted below.
>
> Please vote if you accept the examples. You can vote yes, yes with caveat
> or no with explanation. Please vote by October 16, 2020.
>
> E81 Transformation
>
> Subclass of:  E63 Beginning of Existence
>
> E64 End of Existence
>
>
> Scope note:
>
> This class comprises the events that result in the simultaneous
> destruction of one or more than one E18 Physical Thing and the creation of
> one or more than one E18 Physical Thing that preserves recognizable
> substance and structure from the first one(s) but has fundamentally
> different nature or identity.
>
> Although the old and the new instances of E18 Physical Thing are treated
> as discrete entities having separate, unique identities, they are causally
> connected through the E81 Transformation; the destruction of the old E18
> Physical Thing(s) directly causes the creation of the new one(s) using or
> preserving some relevant substance and structure. Instances of E81
> Transformation are therefore distinct from re-classifications (documented
> using E17 Type Assignment) or modifications (documented using E11
> Modification) of objects that do not fundamentally change their nature or
> identity. Characteristic cases are reconstructions and repurposing of
> historical buildings or ruins, fires leaving buildings in ruins, taxidermy
> of specimen in natural history.
>
> Examples:
>
>- the death and mummification of Tut-Ankh-Amun (transformation of
>Tut-Ankh-Amun from a living person to a mummy) (E69, E81, E7)
>- The death and petrification of the people of Pompeii during the
>eruption of Vesuvius in the first century B.C (E69, E81, E7)
>- The transformation of the Dominicaner Kerk building in Maastricht
>from a church to a stable for the French cavalry in 1795 (following
>Napoleon’s invasion)
>- The transformation of the Dominicaner Kerk building in Maastricht
>building from printing house to a bookshop in 2006
>
>
> In First Order Logic:
>   E81(x) ⊃ E63(x)
>   E81(x) ⊃ E64(x)
>
> Properties:
> P123 resulted in (resulted from): E18 Physical Thing
> P124 transformed (was transformed by): E18 Physical Thing
>
> P123 resulted in (resulted from)
>
> Domain:  E81 Transformation
> Range:  E18 Physical Thing
> Subproperty of: E63 Beginning of Existence. P92 brought into existence
> (was brought into existence by): E77 Persistent Item
> Quantification: many to many, necessary (1,n:0,n)
>
> Scope note: This property identifies the E18 Physical Thing or things that
> are the result of an E81 Transformation. New items replace the transformed
> item or items, which cease to exist as units of documentation. The physical
> continuity between the old and the new is expressed by the link to the
> common Transformation.
>
> Examples:
>
>- the transformation of the Venetian Loggia in Heraklion into a city
>hall (E81) resulted in the City Hall of Heraklion (E22)
>- the death and mummification of Tut-Ankh-Amun (E81) resulted in the
>Mummy of Tut-Ankh-Amun (E22 and E20)
>- The death and the carbonization by the intense heat of a 300 °C gas
>cloud (E69) of the people of Pompeii resulted in  petrified and later
>preserved in plaster bodies (E22).
>- The transformation of the Dominicaner Kerk building in Maastricht
>into a stable (E81) resulted in Stable for the French Cavalry (E22)
>- The transformation of the Dominicaner Kerk building in Maastricht
>into a bookstore (E21) resulted in the Selexyz Dominicanen bookstore (E22)
>
> In First Order Logic:
>   P123(x,y) ⊃ E81(x)
>   P123(x,y) ⊃ E18(y)
>   P123(x,y) ⊃ P92(x,y)
>
> P124 transformed (was transformed by)
>
> Domain:  E81 Transformation
>
> Range:  E18 Physical Thing
>
> Subproperty of: E64 End of Existence. P93 took out of existence (was taken
> out of existence by): E77 Persistent Item
>
> Quantification: one to many, 

Re: [Crm-sig] Announcement for 48th crm-sig meeting

[Robert Sanderson]

The same comment as last time ... only the 3/3:30pm CET slot is possible
for non European participation, and thus could the scheduling of issues
please take that into account?

Rob

On Fri, Sep 18, 2020 at 12:23 PM Bekiari Chryssoula 
wrote:

> Dear all,
>
> Due to covid19 pandemia, the 48th crm-sig meeting will be virtual. The
> proposed days and sessions  are the following:
>
> 20 Oct: CIDOC CRM 7.0.1 issues: sessions *10:00 - 11:30, 12:00 - 13:30,
> 15:00 - 16:30* (CET)
> 21 Oct: work offline on HW for CIDOC CRM 7.0.1
> 22 Oct: wrap 7.0.1 and  presentations: *10:00 - 11:30, 12:00 - 13:30,
> 15:30 - 17:00* (CET)
> 23 Oct: other  issues processing *10:00 - 11:30, 12:00 - 13:30, 15:30 -
> 17:00 *(CET)
>
> Please let us know if you have any comments for the  times of sessions
> or  suggestions for presentations
>
> best regards
> Chryssoula
>
> --
> --
> Chryssoula Bekiari
> Research and Development Engineer
>
> Center for Cultural Informatics / Information Systems Laboratory
> Institute of Computer Science
> Foundation for Research and Technology - Hellas (FORTH)
>
> N. Plastira 100, Vassilika Vouton, GR-700 13 Heraklion, Crete, Greece
> Phone: +30 2810 391631, Fax: +30 2810 391638, Skype: xrysmp
> E-mail: beki...@ics.forth.gr
> ---
>
>
>
> ___
> 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: Measurements and Dimensions

[Robert Sanderson]

Oh, I'm sorry for duplicating your original issue 229 Athina! Great minds
think alike, perhaps?

It seems like 229 was closed in favor of discussing it as part of 307, but
that discussion didn't happen. 293 does seem like a good venue, but
ultimately there is an inconsistency right now (as you recognized long
ago!) that should not persist in version 7.0 regardless of whether
ObservableEntity / Observation are moved into CRM Core or not.

Rob


On Wed, Sep 9, 2020 at 10:57 AM athinak  wrote:

> As I remember, this problem was discussed in issues 229 and 307, which
> are declared closed. However, I am wondering, if it is related to the
> issue 293?
>
> Athina
>
> Στις 2020-09-09 17:26, Athanasios Velios έγραψε:
> > Good point, but it seems to me that being able to measure a Place is
> > pretty important. Otherwise we have to measure through the physical
> > object/site reference or the declarative space as part of a conceptual
> > thing.
> >
> > Thanasis
> >
> >
> >
> > On 09/09/2020 13:39, Robert Sanderson wrote:
> >>
> >> Dear all,
> >>
> >> I believe that there is an inconsistency in the model for measurements
> >> and dimensions.
> >>
> >> E54 Dimensions are associated directly with E70 Things using P43 has
> >> dimension.  So not every class can have dimensions, only those that
> >> are descendents of E70.
> >>
> >> However E16 Measurement's property P39 measured has a range of E1 CRM
> >> Entity, meaning that while (for example) an E53 Place cannot have a
> >> dimension, it can be measured to have a dimension. This seems
> >> inconsistent that an entity that cannot have dimensions can still be
> >> measured.
> >>
> >> I propose that the range of P39 measured be changed to E70 Thing to
> >> resolve this inconsistency.
> >>
> >> I would also be okay with the other direction by changing the domain
> >> of P43 has dimension to be E1 CRM Entity, however that seems like a
> >> much more significant change, and would result in quite strange side
> >> effects such as Dimensions having Dimensions.
> >>
> >> Rob
> >>
> >> -- Rob Sanderson
> >> Director for Cultural Heritage Metadata
> >> Yale University
> >>
> >> ___
> >> Crm-sig mailing list
> >> Crm-sig@ics.forth.gr
> >> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
> >>
> > ___
> > Crm-sig mailing list
> > Crm-sig@ics.forth.gr
> > http://lists.ics.forth.gr/mailman/listinfo/crm-sig
> ___
> Crm-sig mailing list
> Crm-sig@ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>


-- 
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: Measurements and Dimensions

[Robert Sanderson]

Thanks Thanasis.  Yes, there's various dimensions that are associated with
non-Things, and I agree that Place is particularly easy to justify.

Place:  Area. The county of Los Angeles has a dimension of 4751 square
miles. If the place is approximate, then the radius of a centroid would be
an obvious dimension to record, or height/width for bounding box defined
Places.
Time-Span:  Duration is already a property of a Time-Span that refers to a
dimension (P191). This could then be a subproperty of P43, or deprecated in
favor of a classification on the Dimension.

Temporal Entity and Spacetime Volume are a bit strange in relation to
Time-Span. Does the Period have the duration or the Time-Span, or both?
What if they're different
Conversely Dimensions seem like they should not have Dimensions.

Rob


On Wed, Sep 9, 2020 at 10:33 AM Athanasios Velios 
wrote:

> Good point, but it seems to me that being able to measure a Place is
> pretty important. Otherwise we have to measure through the physical
> object/site reference or the declarative space as part of a conceptual
> thing.
>
> Thanasis
>
>
>
> On 09/09/2020 13:39, Robert Sanderson wrote:
> >
> > Dear all,
> >
> > I believe that there is an inconsistency in the model for measurements
> > and dimensions.
> >
> > E54 Dimensions are associated directly with E70 Things using P43 has
> > dimension.  So not every class can have dimensions, only those that are
> > descendents of E70.
> >
> > However E16 Measurement's property P39 measured has a range of E1 CRM
> > Entity, meaning that while (for example) an E53 Place cannot have a
> > dimension, it can be measured to have a dimension. This seems
> > inconsistent that an entity that cannot have dimensions can still be
> > measured.
> >
> > I propose that the range of P39 measured be changed to E70 Thing to
> > resolve this inconsistency.
> >
> > I would also be okay with the other direction by changing the domain of
> > P43 has dimension to be E1 CRM Entity, however that seems like a much
> > more significant change, and would result in quite strange side effects
> > such as Dimensions having Dimensions.
> >
> > Rob
> >
> > --
> > Rob Sanderson
> > Director for Cultural Heritage Metadata
> > Yale University
> >
> > ___
> > Crm-sig mailing list
> > Crm-sig@ics.forth.gr
> > http://lists.ics.forth.gr/mailman/listinfo/crm-sig
> >
> ___
> Crm-sig mailing list
> Crm-sig@ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>


-- 
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: Measurements and Dimensions

[Robert Sanderson]

Dear all,

I believe that there is an inconsistency in the model for measurements and
dimensions.

E54 Dimensions are associated directly with E70 Things using P43 has
dimension.  So not every class can have dimensions, only those that are
descendents of E70.

However E16 Measurement's property P39 measured has a range of E1 CRM
Entity, meaning that while (for example) an E53 Place cannot have a
dimension, it can be measured to have a dimension. This seems inconsistent
that an entity that cannot have dimensions can still be measured.

I propose that the range of P39 measured be changed to E70 Thing to resolve
this inconsistency.

I would also be okay with the other direction by changing the domain of P43
has dimension to be E1 CRM Entity, however that seems like a much more
significant change, and would result in quite strange side effects such as
Dimensions having Dimensions.

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] P127 vs skos:broader

[Robert Sanderson]

Dear all,

I see in the 7.0 PDF that P127 is still available for use.  I recalled that
we thought to deprecate its use on the grounds that thesaurus management is
out of scope of CRM, and thus we should use skos:narrower / skos:broader.
This was in the discussion about the proposed ordinal types (to say that
something is good or bad, and have those ordered) which were rejected on
the same grounds of being out of scope.

Many thanks for clarifying!

Rob

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

Re: [Crm-sig] Modes / Styles of Representing CRM / Ontologies in Diagrams

[Robert Sanderson]

Here are the annotated guidelines that we came up with over about 10 years
of trying different styles across several projects.


   - Colored ovals for resources, with the URI slug within the oval. The
   color is an indication of the sort of resource, but is not the only source
   of the information (re color blindness)

Ovals are important because they give enough space to have text within
them, without taking up too much vertical space. Also enough room to have
multiple lines leading in and out.
Colors are important for most people to see patterns, but need to be
careful of accessibility.


   - Boxes for classes.

But not everything should be boxes, or it looks very square and blocky. The
distinction between class and instance is important, and easy to see with
this.


   - Lozenges for literals. Put strings in ""s inside the lozenge to
   distinguish from numbers, dates, etc.

Lozenge has enough horizontal space, without looking like a stretched class.


   - Black lines with arrows between shapes to establish the connections,
   with labels centered on or above the line.

Obviously.


   - Able to be generated and laid out automatically in a non-terrible way

When you have a lot of diagrams, this becomes important!


We tried having hollow arrow heads for type and filled arrow heads for
other properties, but the distinction is clearer with the class being a box
so we removed it.
We never ran into a need for colored lines or line labels, as the colors
are too subtle to distinguish, so black is better for a11y.

The colors of the ovals should be consistent. We've tried to align across a
few projects now:
  Time:  blue
  Actor: red
  Conceptual: yellow
  Physical: brown
  Place: green
  Data: grey
  Digital: Purple
  Class box:  white


Examples:

https://linked.art/model/base/#names-and-identifiers-for-a-resource
(Scroll down a little past the JSON -- this is generated automatically from
the RDF)
https://linked.art/api/1.0/endpoint/place/#property-diagram  (This is
generated by hand in Omnigraffle)


You can see the evolution of this:

First:  http://openarchives.org/ore/1.0/datamodel#Metadata_about_the_ReM
Evolved to: http://www.openannotation.org/documents/CNI_Dec-OAC_Handout.pdf
Evolved to: http://openannotation.org/spec/beta/
Evolved to: https://www.w3.org/TR/annotation-vocab/#datapositionselector
Evolved to the above.

HTH

Rob



On Wed, Jul 8, 2020 at 6:49 AM George Bruseker 
wrote:

> Dear all,
>
> In the context of Issue 457
>
>
> http://www.cidoc-crm.org/Issue/ID-457-harmonization-of-graphical-documentation-about-crm
>
> We are looking to create style guides for the CRM SIG on how to formulate
> the diagrams that will go in the documentation (e.g. publication of the
> standard, web publications etc.). The goal is to create consistent looking
> documentation that is easily accessible to the CIDOC CRM audience (domain
> specialists, developers, ontological modellers etc.) This would be an
> effort to both create a clean and consistent look for the representations,
> to lower barriers to understanding/adopting CRM, and to more efficiently
> produce this documentation.
>
> Currently we are looking to put together proposals on the possible
> parameters of the style guide, such as which kinds of arrows to use for
> general properties, for IsA property, which kinds of boxes/bubbles to use
> for classes and instances etc.
>
> If you have best practice in mind that should be taken into account, can
> you please share to the list. We will take on board what is shared and make
> a proposal of different possibilities for voting on by the SIG membership.
>
> All best,
>
> George
> ___
> Crm-sig mailing list
> Crm-sig@ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>


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

Re: [Crm-sig] Issue 475 Example addition

[Robert Sanderson]

True, apologies for that!

How about:

* The legal responsibility for physical custody of a large marble statue of
Aphrodite (E22) was transferred from the 12th Duke of Northumberland (E21)
to Sotheby's Auction House (E74) in July 2014

Rob


On Thu, Jun 25, 2020 at 10:11 AM Martin Doerr  wrote:

> Dear Robert,
>
> This is a correct example, but it is categorical. By rule, such examples
> may go into the scope note, if particularly useful. Please find a real,
> particular example.
>
> Kind regards,
>
> martin
>
> On 6/25/2020 4:39 PM, Robert Sanderson wrote:
>
>
> As noted in the working document for 475, the changes are generally
> accepted, and thus we should also add an example.
>
> I propose:
>
> * The legal responsibility for physical custody (but not actual physical
> custody) of a large statue is transferred from the statue's private owner
> to the Sotheby's auction house to facilitate its sale.
>
> Rob
>
> --
> Rob Sanderson
>
> ___
> 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
___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

[Crm-sig] Issue 426 Homework: Work on scope note for Pxx holds or supports

[Robert Sanderson]

Scope Note

This property relates one instance of E18 Physical Thing which acts as a
container or support for another instance of E18 Physical Thing. Typical
examples of E18 Physical Things which are intended to function as a
container or support include shelves, folders or boxes. These containers or
supports provide a stable surface which is intended for other physical
objects to be placed upon for storage, display, transport or other similar
functions. Pxxx holds or supports is a shortcut of the more fully developed
path from the domain E18 Physical Thing through P59 has section, E53 Place,
P53i is former or current location of, to the range E18 Physical Thing.  It
is not a sub-property of P46 is composed of, as the held or supported
object is not a component of the container or support.

This property can be used to avoid explicitly instantiating the E53 Place
which is defined by an instance of E18 Physical Thing, especially when the
only intended use of that instance of E18 Physical Thing is to act as a
container or surface for the storage of other instances of E18 Physical
Thing. The place’s existence is defined by the existence of the container
or surface, and will go out of existence at the same time as the
Destruction of the container or surface.

Examples


   -

   Archival folder “6” (E22) _holds or supports_ the piece of paper (E22)
   carrying the text of a letter from Alloway to Sleigh
   -

   Artist’s materials box “VG6” (E22) _holds or supports_ Van Gogh’s paint
   brush 23 (E22)
   -

   Storage box “VG” (E22)  _holds or supports_ the artist’s materials box
   “VG6” (E22)
   -

   Bookshelf “GRI-708.1” (E22) _holds or supports_ the book “Catalog of
   Paintings in the J. Paul Getty Museum” (E22)



And Christian-Emil kindly provided the first order logic:

Pxx(x,y) ⊃ E18(x)
Pxx(x,y)⊃ E18(y)
Pxx(x,y) ⊂ (∃z) [E53(z) ˄ P59(x,z) ˄ P53i(z,y)]


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

[Crm-sig] Issue 475 Example addition

[Robert Sanderson]

As noted in the working document for 475, the changes are generally
accepted, and thus we should also add an example.

I propose:

* The legal responsibility for physical custody (but not actual physical
custody) of a large statue is transferred from the statue's private owner
to the Sotheby's auction house to facilitate its sale.

Rob

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

[Crm-sig] Homework Issue 475: Transfer of Custody scope note

[Robert Sanderson]

Homework from yesterday for issue 475 -- fix the first sentence of the
second paragraph of the scope notes for Transfer of Custody to reflect the
new understanding as described in the new first sentence of the first
paragraph.

Old sentence:

The distinction between the legal responsibility for custody and the actual
physical possession of the object should be expressed using the property P2
has type (is type of).

New sentence:

In the event that only a single kind of transfer of custody, either the
legal responsibility for the custody or the actual physical possession of
the object but not both, is represented by the E10 Transfer of Custody,
this difference should be expressed using the property P2 has type (is type
of).

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

[Crm-sig] Homework Issue 476 (represents entity of type)

[Robert Sanderson]

Yesterday we agreed that the scope note for Pxx represents entity of type
should be clarified to separate it from just P138 directly to an E55 type.

My attempt to do so for discussion in session 3 tomorrow:

Scope Note:

This property establishes the relationship between an E36 Visual Item and
an E55 Type that represents the class of entity which it visually
represents.  This property is used when the identity of the specific entity
being represented is unknown or unidentified beyond the content of the E36
Visual Item. Pxx represents entity of type is, thus, a shortcut of the more
fully developed path from the domain E36 Visual Item through P138
represents, E1 Entity, P2 has type, to the range E55 Type.

This property is most useful when there is an entity of any type being
depicted that is not identifiable as any single individual, but is clearly
of a particular type. The image carried by a photograph of an unknown
garden would depict many flowers, but none of which are known as entities
beyond the photograph. Conversely, if there isn't an individual that could
fill the role of the E1 Entity in the fully developed path, then this
property is not appropriate, and a direct relationship of P138 represents
from the E36 Visual Item to the E55 Type is recommended.

 The manner or mode of the representation can be captured using Pxx.1 mode
of representation.

Examples:

The photograph’s visual content (E36) represents an entity of type
beach (E55)

The sculpture’s visual content (E36) represents an entity of type woman
(E55)

The landscape painting’s image content (E36) represents an entity of
type field (E55) in the manner of background (E55)



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

Re: [Crm-sig] Activity Partitioning (was Actors acting for other Actors)

[Robert Sanderson]

Oh, I am definitely dubious of the potential about using AI over cultural 
heritage data for even inferencing based on axioms like this. I am entirely 
unsurprised that the effort required was unrealistically high. This is why, in 
the discussion in the Linked Art space, we put it aside as being a theoretical 
problem, but not one that would cause any real errors.

I think you expressed it perfectly – it is reasonable to assume that properties 
hold from the whole to the part unless it is otherwise stated. If the whole has 
a timespan, then the part can be assumed to have that timespan as well (even if 
an edge case allows it to not in fact have that timespan). With cultural 
heritage everything is uncertain to a large degree, compared to physical 
sciences and especially to mathematics, and expecting all assertions to be 
verified as true is simply impossible.

That said … if there was a sub-property of P9 that was used for activities, we 
could be more explicit in the scope notes about some of these implications 
about the actors, rather than just the time and space. If there’s interest in 
pursuing this, I’m happy to participate and channel use cases. If there isn’t, 
I’m just as happy to leave the sleeping dog alone 

Rob


From: Crm-sig  on behalf of Martin Doerr 

Date: Friday, April 17, 2020 at 10:15 AM
To: "crm-sig@ics.forth.gr" 
Subject: Re: [Crm-sig] Activity Partitioning (was Actors acting for other 
Actors)

Dear Robert,

Very good remarks! but...
I may say that this discussion runs headlong against the wall of providing 
enough information from the real world in order to feed artificial intelligence 
- you seem yourself to be critical about it.

I can make a qualified statement about that, because I assigned a whole Master 
thesis about reasoning from parts to wholes in activities, and teams and 
instrumentation used in activities to a student.  In the framework of the 
European Project 3D-COFORM, about digitization and creation of 3D models, we 
could show that even when you intend to monitor completely manually what is 
going on in a technical process, the effort becomes unrealistically high. If 
you are interested, I can make the whole thesis available.

Therefore we need inferences that provide reasonable likelihoods: " if there is 
the activity of writing a book which was carried out by a Person, I don’t think 
it is legitimate to conclude that the part of writing a chapter was also 
carried out by that same person." Correct, but it is most reasonable to assume 
in absence of other evidence. Indeed, historical information almost exclusively 
of such kind of reasoning, and a large part of empirical natural science as 
well.

Extending inferences in binary logic with inferences  of likelihood is in my 
eyes the challenge of the future, and not attempting to model the world until 
binary logic can deal with it completely. Likelihoods of such inferences can, 
in enough cases, be approximated by actual distributions. For instance, in a 
certain context, you may be able to estimate how many writers let chapters 
write by other people. This is a research agenda I share with other computer 
scientists.

Please also note, that E4 Period continues to be IsA STV.

Please also note, that the formalization of the CRM does NOT take inverse 
properties to support different inferences from forward ones, and always imply 
each other. Hence, using P9i does not make any difference in CRM logic.

All the best,

Martin

On 4/17/2020 6:53 PM, Robert Sanderson wrote:

Dear all,

This discussion (and the partitioning aspect of it) reminds me of a niggling 
concern that came up in the Linked Art work about scope note of P9 when applied 
to activities.

In particular, P9 only talks about the part being a subset of the phenomena of 
the whole:

This property associates an instance of E4 Period with another instance of E4 
Period that is defined by a subset of the phenomena that define the former.

To what extent can we infer knowledge through the P9 link, if any? For example, 
if there is the activity of writing a book which was carried out by a Person, I 
don’t think it is legitimate to conclude that the part of writing a chapter was 
also carried out by that same person.

If X consists_of Y, and X carried_out_by Z, then it is not necessarily the case 
that Y carried_out_by Z, due to the open world assumption.  It could be that X 
was also carried out by A, B and C, but that was just not stated. Therefore Y 
could have been carried out by anyone.   And the same argument for all other 
relationships and properties.

Do we even know that the part is within the same temporal period as the whole? 
I don’t think so, given that P4 allows alternative opinions about it expressed 
by assigning multiple Time-Spans to the same E2 Temporal Entity, rather than 
creating a new E2 and having a 1:1 relationship with TimeSpan. So the part 
could occur temporally within an undocumented alternative opinion abo

[Crm-sig] Activity Partitioning (was Actors acting for other Actors)

[Robert Sanderson]

Dear all,

This discussion (and the partitioning aspect of it) reminds me of a niggling 
concern that came up in the Linked Art work about scope note of P9 when applied 
to activities.

In particular, P9 only talks about the part being a subset of the phenomena of 
the whole:

This property associates an instance of E4 Period with another instance of E4 
Period that is defined by a subset of the phenomena that define the former.

To what extent can we infer knowledge through the P9 link, if any? For example, 
if there is the activity of writing a book which was carried out by a Person, I 
don’t think it is legitimate to conclude that the part of writing a chapter was 
also carried out by that same person.

If X consists_of Y, and X carried_out_by Z, then it is not necessarily the case 
that Y carried_out_by Z, due to the open world assumption.  It could be that X 
was also carried out by A, B and C, but that was just not stated. Therefore Y 
could have been carried out by anyone.   And the same argument for all other 
relationships and properties.

Do we even know that the part is within the same temporal period as the whole? 
I don’t think so, given that P4 allows alternative opinions about it expressed 
by assigning multiple Time-Spans to the same E2 Temporal Entity, rather than 
creating a new E2 and having a 1:1 relationship with TimeSpan. So the part 
could occur temporally within an undocumented alternative opinion about the 
timespan. We would thus instead need to also assert P117 occurs during … which 
is not a sub-property of P9 or vice versa.

P9 is a sub property of P10, which has a domain and range of Spacetime Volume… 
so this will need to change with the change of STVs no longer being a parent 
class of Period? At which point we could ensure that P9 implies both P117 and 
some spatial equivalent?

Conversely, it seems that P9i forms part of IS a strong assertion. If we assert 
that the part was carried out by A, then the whole MUST have been carried out 
by at least A, because the carrying-out of the part is a subset of the 
carrying-out of the whole.  Thus, we should prefer to use P9i, as it enables 
stronger inferences and understanding.  But … then if we assert that an 
Activity is part of a Period (rather than merely occurs during it), then the 
carrying-out-ness is a part of the phenomena of the Period … which cannot be 
carried out as it’s not an activity.

Result::head-exploding-emoji:

For now we have chosen to ignore these issues in linked art for the sake of 
sanity and convenience. However if there is guidance or improvements that can 
be made, we would be happy to contribute to those discussions! 

Rob

The original issue: https://github.com/linked-art/linked.art/issues/316








--
Dr. Robert Sanderson,  Semantic Architect  |  Getty Digital  |  
getty.edu<http://getty.edu/>
[signature_1056976797]
___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

Re: [Crm-sig] E-Votes , rules

[Robert Sanderson]

Thanks George, Martin!

For the form, perhaps we could split out a comment section for each, to avoid 
having to manually count YES in the Other field?
Or for general discussion, perhaps we bring it back to the list directly?

In particular:

The examples for P130 and P156 would benefit from the Exx numbers in 
parentheses, as per other property examples.

I agree that the coffee cup shows features of the starbucks logo, in that it 
shows the Visual Item so it is technically correct … but I’m not sure that it 
sets the right precedent, as there is a better property for that (P65, a 
sub-sub-property of P130). I think that examples should be examples of the 
current class or property whenever possible.

Rob



From: Crm-sig  on behalf of Martin Doerr 

Date: Thursday, April 16, 2020 at 5:50 AM
To: "crm-sig@ics.forth.gr" 
Subject: [Crm-sig] E-Votes , rules

Dear All,

I'd like to add that the VETO function is meant to start a discussion for 
reformulation of the proposed solution, typically related to controversial 
evidence, lacking evidence, a proposal for a more effective solution, or 
violation of modelling principles, as mentioned below. After due discussion, 
the issue can be put for e-mail vote in a different form, or will be discussed 
in face-to-face meetings.

I may remind you that all crm-sig members are entitled to call for an e-mail 
vote, if the issue has been presented in a decidable form.

Thank you George for setting this up!

Best,

Martin

On 4/16/2020 10:37 AM, George Bruseker wrote:
Dear all,

After our last meeting of the CIDOC CRM SIG (25-28 February, 2020, Athens, 
Hellenic National Committee of ICOM), we are very close to releasing a new 
official, community version of CIDOC CRM (Version 7) which will enable the 
release of official, community encodings of the standard taking into account 
the significant development work that has taken place over the past few years.

Several issues, however, have remained open which we hope to tie up as 
efficiently as possible, especially engaging e-voting wherever possible to 
speed up the process. Therefore, with this mail, I am sending you a number of 
forms on which I would like to solicit your vote regarding several proposed 
changes.

With regards to a proposed change, 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 (e.g.: 'VETO, this change is unacceptable because it violates the 
following principle...')

In order to make vote counting easier, we have organised the vote questions 
into google forms. We really appreciate you taking the time to support the 
standard by contributing your voice.

Every CIDOC CRM class or property should be accompanied by at least one 
illustrative example. Therefore, a number of new examples were drawn up to fill 
in data for properties and classes that have been introduced but not yet 
provided proper examples.

1 Miscellaneous Examples

Here a number of miscellaneous classes and properties have been bundled. Please 
read the class/property scope notes and check the example and vote if you 
accept/agree with the example.

https://docs.google.com/forms/d/e/1FAIpQLSeOKih5BaD4e3Y9lakqa51Cmdtq8yJ6S8GkVtAPHidoMhntqA/viewform?usp=sf_link

2 Space Time Volume and Temporal Properties Examples

Significant innovation has occurred in the model regarding the use of space 
time volumes and means for representing temporal relations. Please read the 
class/property scope notes and check the example and vote if you accept/agree 
with the example.

https://docs.google.com/forms/d/e/1FAIpQLSf07FGPi5lbER3AJlEAXidAMYvrRQTQi2Tl1pf_XpQU_9UfiQ/viewform?usp=sf_link

3 Presence Class and Related Properties Examples

The Presence class and its related properties, as a specialisation of STV, are 
another important addition to the standard for which examples have been 
generated. Please read the class/property scope notes and check the examples 
and vote if you accept/agree with the example.

https://docs.google.com/forms/d/e/1FAIpQLSf0_502Sxk0gpoRC58YnT18Vp8E2qbH6skBiG1yboCEDplpTQ/viewform?usp=sf_link

4 New property for Presence Class

In the elaboration of the above examples, it was proposed that it may be 
desirable/necessary to introduce a new property to the presence class which 
allows the documentation of the relation between an instance of E93 Presence 
and an instance of E53 Place. Therefore, this form allows you to vote on a) if 
the new property should be introduced, b) if you accept the proposed scope note 
and c) if you accept the various examples.

https://docs.google.com/forms/d/e/1FAIpQLSceFwCsX8HnsO551sSXh4Iol0wRLCyDyxFsbRD-mp-wuy21FA/viewform?usp=sf_link

These votes are called on April 16, 2020 and the voting period will last until 
April 30, 2020. Thank you 

Re: [Crm-sig] NEW ISSUE: Normal Custodian Of?

[Robert Sanderson]

Thanks Martin!

I would be happy with the temporary being explicit for the keeper, but then we 
have an inconsistency between location and custodian.  Would the same apply for 
location as well?

This would mean that we can be clear that there is an exceptional, temporary 
circumstance that should be expected to revert back to the normal circumstances 
in the future. I have a temporary work location of my home, but when this pesky 
virus has gone, it will go back to being my office at the Getty Center.

In terms of the types of transfers … yes, but there might be many types of 
transfers which are either permanent or temporary. It would be nightmarish to 
try and track which were which without some consistent method to flag them.  
Indeed Guernica’s travels around the world are a great example of the 
complexity here!

Rob


From: Crm-sig  on behalf of Martin Doerr 

Date: Saturday, March 7, 2020 at 7:48 AM
To: "crm-sig@ics.forth.gr" 
Subject: Re: [Crm-sig] NEW ISSUE: Normal Custodian Of?

Dear Robert, All,

I see the point, but propose another solution. I have even proposed to 
deprecate "current permanent location", because the "permanent" is hard to be 
objectified, and here extremely specific to a certain inventory practice.

I'd rather argue, that the current keeper of an object that is handed out for 
loan stays obliged for safe-guarding the object. So, a property "has temporary 
keeper" would be much more informative, and positively states what is 
happening. We should just accept a "current keeper" being simultaneaously in 
charge with a "temporary keeper", and the event of change of custody to the 
respective temporary keeper will specify anyhow the character of the transfer.

If transfers of custody are completely registered, as the examples suggest, 
there is no need for further differentiations of stateful properties, because 
the type of transfer can register that.

In any case, think of "Guernica" ! Reality can be very complex;-)

Best,

Martin

On 3/6/2020 12:10 AM, Robert Sanderson wrote:

Another use case which has come up:

A painting is given from the Paintings department, which is the normal 
custodian, to the Conservation department, in order to perform conservation 
work on it.

The Conservation department has custody of it, but the Paintings department is 
still the normal custodian.  The ownership of the object doesn’t change. And 
potentially the physical location of it doesn’t either, if the conservation 
work is being done in place in the gallery, such as the current work on the 
Nightwatch at the Rijksmuseum, or Blue Boy at the Huntingdon here in California.

Rob


From: George Bruseker 
<mailto:george.bruse...@gmail.com>
Date: Sunday, February 16, 2020 at 6:14 AM
To: Robert Sanderson <mailto:rsander...@getty.edu>
Cc: crm-sig <mailto:crm-sig@ics.forth.gr>
Subject: Re: [Crm-sig] NEW ISSUE: Normal Custodian Of?

It seems to make sense to raise as an issue. The case does seem to come up 
reasonably frequently. The parallel seems convincing. For the moment we could 
cover temporal elements by initiating the existing of the property via an E13 
attribute assignment (if we had such info).





On Feb 15, 2020, at 2:33 AM, Robert Sanderson 
mailto:rsander...@getty.edu>> wrote:


Apologies, I should have put NEW ISSUE in the subject for this originally.

As a quick proposal to discuss:

With P54 has current permanent location as a precedent, I would propose a Pxx 
has current permanent custodian as a new property to manage the knowledge 
described in the email below.

Happy to work on a scope note for it if that’s a useful thing to add to the 
ontology.

Rob

From: Robert Sanderson mailto:rsander...@getty.edu>>
Date: Tuesday, January 7, 2020 at 12:24 PM
To: "crm-sig@ics.forth.gr<mailto:crm-sig@ics.forth.gr>" 
mailto:crm-sig@ics.forth.gr>>
Subject: Normal Custodian Of?


Dear fellow SIG folks,

Happy new year 

A question came up here as to how to record the normal custodian of an object, 
as opposed to the current custodian.

For example, if we have custody of an object but it’s a permanent loan from a 
donor, and we lend it to another organization for an exhibition, then the owner 
doesn’t change (still the donor, probably wanting to remain anonymous) and 
there’s a transfer of custody from ourselves to the exhibiting organization.  
If that’s a travelling exhibit, it might pass through several custodians before 
it should eventually return to us.

Is there a way to track this not-quite-an-owner but 
not-just-the-current-custodian state?  The only way that I can see is to model 
the right of permanent custody separate from the right of temporary custody… 
but then we re-enter the rights and temporal validity arena.  Perhaps this 
would be another motivating use case for moving forward with that work?

Many thanks for your thoughts,

Rob

--
Rob Sanderson,  Seman

[Crm-sig] NEW ISSUE: [Sci] Labels of O19, O21

[Robert Sanderson]

Dear all,

At a recent Linked Art meeting we discussed how to model “find events”, and S19 
and O19 were agreed upon as the correct modeling constructs.  We also discussed 
why S19 is an “encounter” rather than a “find” or “discovery”, as is very well 
described in the scope notes for the class.

However, the properties of S19 would benefit from some attention towards 
consistency.  If S19 is encountering, then it seems counterproductive to have 
O19 as being “has found object” and O21 “has found at”, undoing all the good 
culturally sensitive work of explained in S19.

I would propose that O19 and 21 be relabeled to “encountered object (was object 
encountered by)” and “encountered at (witnessed encounter)”.

Many thanks for your consideration,

Rob

--
Dr. Robert Sanderson,  Semantic Architect  |  Getty Digital  |  
getty.edu<http://getty.edu/>
[signature_1632129958]
___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

Re: [Crm-sig] NEW ISSUE: Pxx represents entity of type

[Robert Sanderson]

Hi Nicola,

I disagree with the relationship to P137.  That would mean that the visual item 
exemplified the type, which it doesn’t, it merely depicts an entity of the type.
For example, if it were a sub-property of P137 and I was looking for exemplars 
of abstract impressionism, I might find images that are photographic that 
merely depict an instance of something which is abstract impressionism.
I could also see it being a sibling to P138 rather than a child, and thus a 
sub-property of P67.

I took the “not of interest” phrase from the parallel P125:

> This property defines the kind of objects used in an E7 Activity, when the 
> specific instance is either unknown or not of interest, such as use of "a 
> hammer".

But I’m also happy with your reformulation.

Thanks!

Rob

From: Nicola Carboni 
Date: Tuesday, February 25, 2020 at 2:48 AM
To: Robert Sanderson 
Cc: crm-sig 
Subject: Re: [Crm-sig] NEW ISSUE: Pxx represents entity of type


Dear Rob,

I do agree with the need and the formulation, and it can be extremely useful 
for iconographical attributes (which are intentionally classified using 
categories). I did personally used the same 
construct<https://ncarboni.github.io/vir/#K21_depict_things_of_type> in an 
extension of CRM for iconographical representation, so would love to see it in 
CRM base.

Sub Property Of P138 Represents

What about making it as subproperty of "P137 exemplifies (is exemplified by)". 
It does seems to me more appropriate.

This property establishes the relationship between an E36 Visual Item and an 
E55 Type that represents the class of entity which it visually represents. This 
property is used when the specific entity being represented is either unknown, 
or not of documentary interest. The manner or mode of the representation can be 
captured using Pxx.1 mode of representation.

I would not use a negative ("not of documentary interest") and say "This 
property is used when the specific entity being represented is either unknown, 
or for documenting the belonging of an item to a specific category" or another 
more positive formulation. In my experience, the choice of the classification 
of categorical vs instance depends on the discipline and not by a lack of 
documentary interest.

Another example could be:

  *   The attribute of the wall painting "Saint George" (E36) represents an 
entity of type dragon (E55) in the manner of Iconographical Attribute (E55)

Best,

Nicola

—
Nicola Carboni
Research Fellow // History of Art
University of Zurich Post Box 23
Ramistrasse 71 8006 Zurich
Switzerland

On 19 Feb 2020, at 1:54, Robert Sanderson wrote:



Dear all,



(Last new issue for now, I promise)



When describing a Visual Item, we can say that it represents some entity that 
you can point to (e.g. the sitter), that it is about some subject that you 
can’t point to (e.g love) and it can have general classifications with has type 
for style (abstract) or other such features of the overall visual content. 
However, it would be useful to be able to say that a class of entity is 
represented in the visual item rather than a specific entity.



We have tried several approaches to this. If we want to say that a still life 
painting depicts flowers, we would not want to create a Biological Object and 
classify it as a flower to be represented by the visual item of the painting … 
such a flower may never have actually existed, and it would be enormously 
expensive. Equally we don’t think that the Type “flowers” is represented in the 
painting … it’s a not a depiction of all flowers, it’s a depiction of some, 
likely fictional, collection of specific flowers.



So we would propose a new property that parallels P138 represents, but instead 
refers to a class of entity rather than a specific.



We can see this pattern already in the model:

P16 used specific objectvs   P125 used object of type

P20 had specific purpose vsP21 had general purpose

P33 used specific techniquevs   P32 used general technique

P108 has producedvsP186 produced thing of product type



Pxx represents entity of type

Domain: E36 Visual Item

Range: E55 Type

Sub Property Of P138 Represents



This property establishes the relationship between an E36 Visual Item and an 
E55 Type that represents the class of entity which it visually represents.  
This property is used when the specific entity being represented is either 
unknown, or not of documentary interest.  The manner or mode of the 
representation can be captured using Pxx.1 mode of representation.



Properties:  Pxx.1 mode of representation: E55 Type



Examples:
· The still life painting’s image content (E36) represents and entity 
of type flowers (E55)
· The sculpture’s visual content (E36) represents an entity of type 
woman (E55)
· The photograph’s visual content (E36) represents an entity of type 
beach (E55) in the manner of b

Re: [Crm-sig] NEW ISSUE: Normal Custodian Of?

[Robert Sanderson]

Another use case which has come up:

A painting is given from the Paintings department, which is the normal 
custodian, to the Conservation department, in order to perform conservation 
work on it.

The Conservation department has custody of it, but the Paintings department is 
still the normal custodian.  The ownership of the object doesn’t change. And 
potentially the physical location of it doesn’t either, if the conservation 
work is being done in place in the gallery, such as the current work on the 
Nightwatch at the Rijksmuseum, or Blue Boy at the Huntingdon here in California.

Rob


From: George Bruseker 
Date: Sunday, February 16, 2020 at 6:14 AM
To: Robert Sanderson 
Cc: crm-sig 
Subject: Re: [Crm-sig] NEW ISSUE: Normal Custodian Of?

It seems to make sense to raise as an issue. The case does seem to come up 
reasonably frequently. The parallel seems convincing. For the moment we could 
cover temporal elements by initiating the existing of the property via an E13 
attribute assignment (if we had such info).




On Feb 15, 2020, at 2:33 AM, Robert Sanderson 
mailto:rsander...@getty.edu>> wrote:


Apologies, I should have put NEW ISSUE in the subject for this originally.

As a quick proposal to discuss:

With P54 has current permanent location as a precedent, I would propose a Pxx 
has current permanent custodian as a new property to manage the knowledge 
described in the email below.

Happy to work on a scope note for it if that’s a useful thing to add to the 
ontology.

Rob

From: Robert Sanderson mailto:rsander...@getty.edu>>
Date: Tuesday, January 7, 2020 at 12:24 PM
To: "crm-sig@ics.forth.gr<mailto:crm-sig@ics.forth.gr>" 
mailto:crm-sig@ics.forth.gr>>
Subject: Normal Custodian Of?


Dear fellow SIG folks,

Happy new year 

A question came up here as to how to record the normal custodian of an object, 
as opposed to the current custodian.

For example, if we have custody of an object but it’s a permanent loan from a 
donor, and we lend it to another organization for an exhibition, then the owner 
doesn’t change (still the donor, probably wanting to remain anonymous) and 
there’s a transfer of custody from ourselves to the exhibiting organization.  
If that’s a travelling exhibit, it might pass through several custodians before 
it should eventually return to us.

Is there a way to track this not-quite-an-owner but 
not-just-the-current-custodian state?  The only way that I can see is to model 
the right of permanent custody separate from the right of temporary custody… 
but then we re-enter the rights and temporal validity arena.  Perhaps this 
would be another motivating use case for moving forward with that work?

Many thanks for your thoughts,

Rob

--
Rob Sanderson,  Semantic Architect  |  Getty Digital  |  
getty.edu<http://getty.edu/>

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


CAUTION: This email originated from outside of the Getty. Do not click links or 
open attachments unless you verify the sender and know the content is safe.


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

Re: [Crm-sig] My HW Issue 294: appears in etc.

[Robert Sanderson]

To play the devil’s avocado … if Stephen is correct that we don’t want to add 
categorical assertions, then these seem like clear instances of that type of 
assertion.

Personally, these seem extremely useful … along with many other categorical 
assertions!

Rob

From: Crm-sig  on behalf of Martin Doerr 

Date: Thursday, February 20, 2020 at 11:38 AM
To: crm-sig 
Subject: [Crm-sig] My HW Issue 294: appears in etc.

Dear all,



Here my reworking of the scope notes:

appears in
Domain:   E55 Type
Range:  E4 Period
Subproperty: appears in
Quantification: many-to-many
Old Scope Note:
This property connects a kind of object (documented as an instance of E55 Type) 
to an instance of E4 Period in order to indicate that this kind of object is 
found in archaeological contexts related to this period.
This property makes a weak statement with regards to the distribution of the 
class of object in the archaeological record. The statement would support 
reasoning, ceteris paribus, that the discovery of an instance of this type of 
object in an archaeological context would indicate that a number of instances 
of E4 Period, in which the type of object is known to appear, may have extended 
over the area of archaeological observation in question.
Stronger claims can be made using ‘typical for’ and ‘restricted to’  properties.
New Scope Note:
This property associates a kind of object (documented as an instance of E55) to 
an instance of E4 Period for indicating that objects of this kind have been 
generated within this period. The generation of such objects may be the result 
of human, biological, geological or other processes.
This property makes a weak statement with regards to the distribution of the 
class of object in the archaeological record, but also in geological or 
paleontological observations: If the genesis of an object of this type can 
plausibly be assumed to fall within the genesis of the context in which it was 
found, then the statement made with this property would support reasoning, 
ceteris paribus, that the genesis period of the find context forms part of or 
overlaps with one of the instance of E4 Period in which the respective object 
type has appeared.
Stronger claims can be made using ‘typical for’ and ‘restricted to’  properties.
restricted to
Domain:   E55 Type
Range:  E4 Period
Subproperty: appears in
Quantification: many-to-one

Old Scope Note:
This property connects a kind of object (documented as an instance of E55) to 
an instance of E4 Period to indicate that this kind of object is exclusively 
generated in contexts – archaeological, biological, geological –in this period.
This property makes a strong statement with regards to the distribution of the 
class of object in the archaeological record. The statement would support 
reasoning, ceteris paribus, that the discovery of an instance of this type of 
object in a context would be indicative of the extension of an instance of the 
related instance of E4 Period over the area of archaeological observation.
Weaker claims can be made using ‘typical for’ and ‘appears in’.

New Scope Note:
This property associates a kind of object (documented as an instance of E55) to 
an instance of E4 Period for indicating that objects of this kind have 
exclusively been generated in this period.
This property makes a strong statement concerning the distribution of the kind 
of object in the observation record: If the genesis of an object of this type 
can plausibly be assumed to fall within the genesis of the context in which it 
was found, then the statement made with this property would support reasoning, 
ceteris paribus, that the genesis period of the find context actually forms 
part of the related instance of E4 Period, or at least overlaps with it.
In contrast, objects from previous periods may appear in a context because they 
are still in use, and objects from later periods may have been pushed into an 
older context.
Weaker claims can be made using the properties ‘typical for’ and ‘appears in’.

typical for
Domain:E55 Type
Range:  E4 Period
Subproperty: appears in
Quantification: many-to-one
 Old Scope Note:
This property connects a kind of object (documented as an instance of E55 Type) 
to an instance of E4 Period in order to indicate that this kind of object is 
regularly found in archaeological contexts related to this period.
This property makes a moderate statement with regards to the distribution of 
the class of object in the archaeological record. The statement would support 
reasoning, ceteris paribus, that the discovery of instances of this type of 
object in an archaeological context would be a possible indicator of the 
extension of an instance of the related instance of E4 Period over the area of 
archaeological observation.
A stronger claim can be made using ‘restricted to’ while a weaker claim is made 
using ‘appears in.
New Scope 

[Crm-sig] NEW ISSUE: Pxx represents entity of type

[Robert Sanderson]

Dear all,

(Last new issue for now, I promise)

When describing a Visual Item, we can say that it represents some entity that 
you can point to (e.g. the sitter), that it is about some subject that you 
can’t point to (e.g love) and it can have general classifications with has type 
for style (abstract) or other such features of the overall visual content. 
However, it would be useful to be able to say that a class of entity is 
represented in the visual item rather than a specific entity.

We have tried several approaches to this. If we want to say that a still life 
painting depicts flowers, we would not want to create a Biological Object and 
classify it as a flower to be represented by the visual item of the painting … 
such a flower may never have actually existed, and it would be enormously 
expensive. Equally we don’t think that the Type “flowers” is represented in the 
painting … it’s a not a depiction of all flowers, it’s a depiction of some, 
likely fictional, collection of specific flowers.

So we would propose a new property that parallels P138 represents, but instead 
refers to a class of entity rather than a specific.

We can see this pattern already in the model:
P16 used specific objectvs   P125 used object of type
P20 had specific purpose vsP21 had general purpose
P33 used specific techniquevs   P32 used general technique
P108 has producedvsP186 produced thing of product type

Pxx represents entity of type
Domain: E36 Visual Item
Range: E55 Type
Sub Property Of P138 Represents

This property establishes the relationship between an E36 Visual Item and an 
E55 Type that represents the class of entity which it visually represents.  
This property is used when the specific entity being represented is either 
unknown, or not of documentary interest.  The manner or mode of the 
representation can be captured using Pxx.1 mode of representation.

Properties:  Pxx.1 mode of representation: E55 Type

Examples:

  *   The still life painting’s image content (E36) represents and entity of 
type flowers (E55)
  *   The sculpture’s visual content (E36) represents an entity of type woman 
(E55)
  *   The photograph’s visual content (E36) represents an entity of type beach 
(E55) in the manner of background (E55)


Thoughts?

Many thanks!

Rob


--
Dr. Robert Sanderson,  Semantic Architect  |  Getty Digital  |  
getty.edu<http://getty.edu/>
[signature_1245888113]
___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

[Crm-sig] NEW ISSUE: Transfer of Custody Scope Note

[Robert Sanderson]

Dear all,

At a recent Linked Art meeting we were discussing Exhibitions and the 
relationship to displays and art gallery presentations. In reading the fine 
print, so to speak, of the Transfer of Custody scope note, we noticed and would 
appreciate clarification about the following:


> This class comprises transfers of physical custody of objects between 
> instances of E39 Actor.

But then…


> The distinction between the legal responsibility for custody and the actual 
> physical possession of the object should be expressed using the property P2 
> has type (is type of).

So, the question is whether a transfer of legal custody can be modeled with 
E10, if either we do not know that physical custody was involved or if we know 
that it was not.

Some examples:


  *   Rob auctions his copy of LaRoche’s “Three Red Wolves” on Ebay. Does Ebay 
have custody of it in order to facilitate the sale?
  *   Rob sells his house. Clearly the house is not in the physical possession 
of anyone other than me, but while the sale is pending, I have ascribed some 
degree of legal custody to others?
  *   We do not know whether the original object is physically present at an 
auction house or not. If it’s a big statue, maybe the auction house only has a 
photograph of it. Even if it’s a painting, the original may not be there (it 
might have been viewable in a controlled environment previously for example). 
In these cases, there is enough legal custody to be able to negotiate the sale, 
but it is unknown whether there was explicitly physical custody.  Ditto for 
consignment of objects.

If E10 is only for physical custody, then how would we describe 
legal-but-not-physical custody? And if we can just use a P2 on the E10, then it 
would be great to change the first line of the scope note to address that.

Thanks!

Rob

--
Dr. Robert Sanderson,  Semantic Architect  |  Getty Digital  |  
getty.edu<http://getty.edu/>
[signature_134081]
___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

[Crm-sig] NEW ISSUE: Normal Custodian Of?

[Robert Sanderson]

Apologies, I should have put NEW ISSUE in the subject for this originally.

As a quick proposal to discuss:

With P54 has current permanent location as a precedent, I would propose a Pxx 
has current permanent custodian as a new property to manage the knowledge 
described in the email below.

Happy to work on a scope note for it if that’s a useful thing to add to the 
ontology.

Rob

From: Robert Sanderson 
Date: Tuesday, January 7, 2020 at 12:24 PM
To: "crm-sig@ics.forth.gr" 
Subject: Normal Custodian Of?


Dear fellow SIG folks,

Happy new year 

A question came up here as to how to record the normal custodian of an object, 
as opposed to the current custodian.

For example, if we have custody of an object but it’s a permanent loan from a 
donor, and we lend it to another organization for an exhibition, then the owner 
doesn’t change (still the donor, probably wanting to remain anonymous) and 
there’s a transfer of custody from ourselves to the exhibiting organization.  
If that’s a travelling exhibit, it might pass through several custodians before 
it should eventually return to us.

Is there a way to track this not-quite-an-owner but 
not-just-the-current-custodian state?  The only way that I can see is to model 
the right of permanent custody separate from the right of temporary custody… 
but then we re-enter the rights and temporal validity arena.  Perhaps this 
would be another motivating use case for moving forward with that work?

Many thanks for your thoughts,

Rob

--
Rob Sanderson,  Semantic Architect  |  Getty Digital  |  
getty.edu<http://getty.edu/>
[/Users/rsanderson/Library/Containers/com.microsoft.Outlook/Data/Library/Caches/Signatures/signature_1621652008]
___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

Re: [Crm-sig] workshop tutorials at CIDOC 2020: September 19-25, 2020?

[Robert Sanderson]

We’re hoping to have the panel during the week, and then a 2 hour or half day 
slot towards the end of the week for the workshop … thus attendees at the 
workshop part could have attended the CRM tutorial, and the panel, before 
coming to the more in depth Linked Art profile walk through.

Last year we had a very successful experience in London with inviting people to 
bring a print out of one of their collection system records, and we showed how 
to model and describe the object using CRM / Linked Art, and I anticipate that 
we would offer something similar as a small group exercise, after a tutorial 
style presentation.

Rob

From: Christian-Emil Smith Ore 
Date: Friday, February 14, 2020 at 1:11 AM
To: Robert Sanderson , crm-sig 
Cc: "Delmas-Glass, Emmanuelle" 
Subject: Re: [Crm-sig] workshop tutorials at CIDOC 2020: September 19-25, 2020?


​Hi Rob

It a very good idea to coordinate the workshops. Do you plan to have the 
workshop and the panel Saturday/Sunday before the conference?

Best,

Christian-Emil

____
From: Robert Sanderson 
Sent: 13 February 2020 18:18
To: Christian-Emil Smith Ore; crm-sig
Cc: Delmas-Glass, Emmanuelle
Subject: Re: [Crm-sig] workshop tutorials at CIDOC 2020: September 19-25, 2020?

Hi Christian-Emil, all,

While not a dedicated CRM workshop, the Linked Art WG plans to have an 
introductory panel session and subsequent workshop about our profiled use of 
CRM. If there is interest in aligning to avoid repeating very similar content, 
I’m happy to help coordinate.

Rob

From: Crm-sig  on behalf of Christian-Emil Smith 
Ore 
Date: Wednesday, February 12, 2020 at 11:19 PM
To: crm-sig 
Subject: [Crm-sig] workshop tutorials at CIDOC 2020: September 19-25, 2020?


Dear all,

The Board of CIDOC has its winter meeting  13-16 February. I participate as the 
CRM-SIG representative. One issue will bewg meetings and workshops tutorials. 
Does anybody plan or would like to  organize a CRM workshop/tutorial?

The dates and place:

CIDOC 2020: September 19-25, 2020 in Geneva, Switzerland



Best,

Christian-Emil

CAUTION: This email originated from outside of the Getty. Do not click links or 
open attachments unless you verify the sender and know the content is safe.


CAUTION: This email originated from outside of the Getty. Do not click links or 
open attachments unless you verify the sender and know the content is safe.


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

Re: [Crm-sig] workshop tutorials at CIDOC 2020: September 19-25, 2020?

[Robert Sanderson]

Hi Christian-Emil, all,

While not a dedicated CRM workshop, the Linked Art WG plans to have an 
introductory panel session and subsequent workshop about our profiled use of 
CRM. If there is interest in aligning to avoid repeating very similar content, 
I’m happy to help coordinate.

Rob

From: Crm-sig  on behalf of Christian-Emil Smith 
Ore 
Date: Wednesday, February 12, 2020 at 11:19 PM
To: crm-sig 
Subject: [Crm-sig] workshop tutorials at CIDOC 2020: September 19-25, 2020?


Dear all,

The Board of CIDOC has its winter meeting  13-16 February. I participate as the 
CRM-SIG representative. One issue will bewg meetings and workshops tutorials. 
Does anybody plan or would like to  organize a CRM workshop/tutorial?

The dates and place:

CIDOC 2020: September 19-25, 2020 in Geneva, Switzerland



Best,

Christian-Emil

CAUTION: This email originated from outside of the Getty. Do not click links or 
open attachments unless you verify the sender and know the content is safe.


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

Re: [Crm-sig] E-vote for the scope note of P2 has type (is type of)

[Robert Sanderson]

YES

From: Crm-sig  on behalf of Bekiari Xrysoula 

Date: Friday, January 31, 2020 at 4:55 AM
To: "crm-sig@ics.forth.gr" 
Subject: Re: [Crm-sig] E-vote for the scope note of P2 has type (is type of)


Dear All,

Following the decisions of the last sig, we invite you to vote if you accept 
the updated scope note of P2 has type .  The old and the new scope notes follow:

===

P2 has type (is type of)

(old)

Scope note:This property allows sub typing of CIDOC CRM entities - a form 
of specialisation – through the use of a terminological hierarchy, or thesaurus.

The CIDOC CRM is intended to focus on the high-level entities and relationships 
needed to describe data structures. Consequently, it does not specialise 
entities any further than is required for this immediate purpose. However, 
entities in the isA hierarchy of the CIDOC CRM may by specialised into any 
number of sub entities, which can be defined in the E55 Type hierarchy. E41 
Appellation, for example, may be specialised into “e-mail address”, “telephone 
number”, “post office box”, “URL” etc. none of which figures explicitly in the 
CIDOC CRM hierarchy. Subtyping obviously requires consistency between the 
meaning of the terms assigned and the more general intent of the CIDOC-CRM 
entity in question.

(New)

Scope note:This property allows sub typing of CIDOC CRM entities - a form 
of specialisation – through the use of a terminological hierarchy, or thesaurus.

The CIDOC CRM is intended to focus on the high-level entities and relationships 
needed to describe data structures. Consequently, it does not specialise 
entities any further than is required for this immediate purpose. However, 
entities in the isA hierarchy of the CIDOC CRM may by specialised into any 
number of sub entities, which can be defined in the E55 Type hierarchy. E41 
Appellation, for example, may be specialised into “e-mail address”, “telephone 
number”, “post office box”, “URL” etc. none of which figures explicitly in the 
CIDOC CRM hierarchy.
A comprehensive explanation about refining CIDOC CRM concepts by E55 Type is 
given in the section “About Types” in the section on “Specific Modelling 
Constructs” of this document.


PLEASE VOTE :

YES for accepting,

NO for not accepting,

by Feb. 6  2020.

all the best

Chryssoula



--

---

Chryssoula Bekiari

Research and Development Engineer



Center for Cultural Informatics / Information Systems Laboratory

Institute of Computer Science

Foundation for Research and Technology - Hellas (FORTH)



N. Plastira 100, Vassilika Vouton, GR-700 13 Heraklion, Crete, Greece

Phone: +30 2810 391631, Fax: +30 2810 391638, Skype: xrysmp

E-mail: beki...@ics.forth.gr

Web-site: http://www.ics.forth.gr/isl/index_main.php?l=e=231



CAUTION: This email originated from outside of the Getty. Do not click links or 
open attachments unless you verify the sender and know the content is safe.


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

Re: [Crm-sig] The archivists are (stil) a different sect ?

[Robert Sanderson]

I actually think that traditional archiving practices /are/ a different “sect” 
… or less controversially: the non-digital archival practices of the North 
American tradition do not map cleanly into a more precise ontology such as 
CIDOC-CRM that is designed for expressing knowledge about specifics, rather 
than the broad generalities of “collection description”.

In particular the distinction between the objects as managed physical things 
and the objects as the members of an intellectual hierarchy is very important 
in CRM (IMO) and very complicated to tease apart from current data in archival 
systems.

I believe that trying to force the very general archival patterns into a very 
specific CRM model would meet a lot of resistance from many institutions, and 
even if we think that would be an improvement to the archival practices, the 
archivists need to come to that realization for themselves.

Rob

From: Crm-sig  on behalf of Martin Doerr 

Date: Monday, January 27, 2020 at 1:53 AM
To: "crm-sig@ics.forth.gr" 
Subject: Re: [Crm-sig] The archivists are (stil) a different sect ?

On 1/27/2020 10:23 AM, Dan Matei wrote:

https://www.ica.org/standards/RiC/ontology.html



Great :-(



Dan





___

Crm-sig mailing list

Crm-sig@ics.forth.gr

http://lists.ics.forth.gr/mailman/listinfo/crm-sig

Well, they write:

"adding suggestions of mappings (in rico:closeTo) and OWL equivalences between 
some classes or properties and components in other models (among which - this 
is not an exhaustive list- CIDOC-CRM, IFLA-LRM, PREMIS, PROV-O, and Schema.org)"

.

--



 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

CAUTION: This email originated from outside of the Getty. Do not click links or 
open attachments unless you verify the sender and know the content is safe.


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

Re: [Crm-sig] ISSUE: Scope note of E37 Mark

[Robert Sanderson]

From a practical perspective, when modeling a short text that’s on a physical 
object … how can I know when that should be a Mark+Linguistic Object, or when 
it is an Inscription?

Rob

From: Crm-sig  on behalf of Martin Doerr 

Date: Saturday, January 18, 2020 at 12:32 PM
To: "crm-sig@ics.forth.gr" 
Subject: Re: [Crm-sig] ISSUE: Scope note of E37 Mark

I understand the following:

This means, that there cannot be Linguistic Objects among the marks that are 
not inscriptions.

This violates the Open World assumptions. We know that Inscriptions are also 
Linguistic Objects, but that does NOT imply that there may be other Linguistic 
Objects among the Marks.

It is most probably the case, but we neither know for sure, nor make such 
statements in the CRM.

I also do not see a particular utility in this statement.

All other rules A-D provided by Robert  appear to be correct.

Best,

Martin



On 1/18/2020 6:27 PM, Christian-Emil Smith Ore wrote:

E37 Mark E33 Linguistic Object

 |   /

E34 Inscription



​​E) No Marks which are not also Inscriptions are Linguistic Objects

The sentence is difficult to understand.  I try.
Pr defintion:
All (instances of E37) marks which are (instances of E34) Inscriptions are 
(instances of E33) Linguistic Objects.
The only difference between E34 Inscription and  E37 Mark is that E34 is a 
restriction of E37 Mark to those which also are  instances of  E33 Lingustic 
Object that is has a language.  Most sequences of letters and signs do not have 
a language.

C-E

From: Crm-sig 
<mailto:crm-sig-boun...@ics.forth.gr> on behalf 
of Martin Doerr <mailto:mar...@ics.forth.gr>
Sent: 18 January 2020 13:59
To: crm-sig@ics.forth.gr<mailto:crm-sig@ics.forth.gr>
Subject: Re: [Crm-sig] ISSUE: Scope note of E37 Mark

I also disagree with E, but letters and combinations should not be regarded 
Linguistic Objects. They do not have a particular language, translation etc. No 
need to make them linguistic objects.

Best,

Martin

On 1/18/2020 1:53 PM, Øyvind Eide wrote:
Dear all,

Given this answer to E is part of documentation practice, could it be solved by 
double instantiation?

All the best,

Øyvind

Am 17.01.2020 um 22:18 schrieb Ethan Gruber 
mailto:ewg4x...@gmail.com>>:

I agree with your assertion of D: that not all inscriptions are marks.

I disagree with E. A mark can most certainly be a letter or combination of 
letters. Have you ever noticed the letter "P" on an American coin? It's a mint 
mark representing Philadelphia. The "SC" characters on a Roman coin correspond 
to the authority of the Senate. These are obviously linguistic objects that 
carry a narrower semantic meaning as defined in the scope note for E37 Mark.

Ethan

On Fri, Jan 17, 2020 at 3:49 PM Robert Sanderson 
mailto:rsander...@getty.edu>> wrote:

I think that I agree  To be clearer about the inheritance that we’re 
discussing:


  *   A)  All Marks are Symbolic Objects
  *   B) All Linguistic Objects are Symbolic Objects
  *   C) All Inscriptions are Linguistic Objects
  *   D) All Inscriptions are Marks
  *   E) No Marks which are not also Inscriptions are Linguistic Objects

I believe the question is whether the last two assertions above are accurate.

For D, I would argue that the Balliol sign is not a Mark, as the symbolic 
content is not related to the intents given in the scope note, and thus either 
the scope note should be changed to remove the intents and be clearer about the 
nature of the class, or Inscription should not be a subclass of Mark.

For E, I would argue that if “short text” is included in the scope for the Mark 
class, then there must be some Marks that are Linguistic Objects as short text 
implies that the symbols encode some natural language. I think that the scope 
note should be changed to remove “short text” to avoid this issue. Marks should 
be explicitly NOT text and only symbols, and if there is a linguistic 
interpretation of the content, then they should instead be Inscriptions.

Hope that clarifies!

Rob

From: Martin Doerr mailto:mar...@ics.forth.gr>>
Date: Friday, January 17, 2020 at 10:35 AM
To: Robert Sanderson mailto:rsander...@getty.edu>>, 
crm-sig mailto:Crm-sig@ics.forth.gr>>
Subject: Re: [Crm-sig] ISSUE: Scope note of E37 Mark

Dear Robert,

Yes, that is a good question!
For a very long time, we had no feedback to this part f the CRM.

Be careful not to inherit things upstream. If a Mark is also a Linguistic 
Object, then it is in particular an Inscription.
But a Mark needs not be an Inscriptions.

However, we must take care that the "non-Inscription marks" are not separated 
out as complement, because following all the discussions we had in the past, 
there are enough marks cannot be clearly distinguished from inscriptions.

So, the scope not should admit the existence of marks in this wider sense, 
which are not the codified monogra