Re: [Crm-sig] Issue: Related examples

[George Bruseker via Crm-sig]

Dear Martin,

If we went in the direction of graphic example, perhaps there could be a
referenced draw.io graph which could be hosted on the site. The danger of
course is link staleness etc. However, ignoring that problem, probably more
like an illustration page like the current 'functional overview' graphs.
but for particular use case examples. So again IF we did such a thing then
maybe we would want to pick out a format of the things that should go into
such an example page ( a la functional overview diagrams).

All best,

George

On Thu, Jul 11, 2024 at 12:32 PM Martin Doerr via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear All,
>
> There has been invested a great lot of work in related examples, but they
> are not linked, such as:
>
>   the examination of MS Sinai Greek 418 by Nicholas Pickwoad in November
> 2003 (Honey & Pickwoad, 2010)
>
>   The examination of MS Sinai Greek 418 (E13) assigned attribute to MS
> Sinai Greek 418 (E22). (Honey and Pickwoad, 2010)
>
>   The examination of MS Sinai Greek 418 (E13) *assigned* unsupported
> (E55.) (Honey & Pickwoad, 2010)
>
>   The examination of MS Sinai Greek 418 (E13) *assigned property of type*
> binding structure type (E55). [‘binding structure type’ refers to a
> property, external to the CIDOC CRM, which connects a book (E22) to the
> type of its binding structure (E55)] (Honey & Pickwoad, 2010)
> I propose to discuss and decide quickly an effective method for connecting
> these examples. Graphics would also be nice, but a "see also" would already
> be of huge help.
>
> 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
>
>  Email: mar...@ics.forth.gr
>  Web-site: http://www.ics.forth.gr/isl
>
>
>
> 
>  Χωρίς
> ιούς.www.avast.com
> 
> <#m_-3873909119046156169_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> 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] PhD Position in Formal Ontology and Historical Research with University of Teramo and Takin.solutions

[George Bruseker via Crm-sig]

Dear colleagues,


Please find below an announcement for a PhD position with the University of
Teramo and Takin.solutions. If you know suitable candidates please feel
free to share the information. The application deadline is short.


Takin.solutions is proud to announce it is co-sponsoring a PhD candidate
with the University of Teramo on the topic, “The intersection of semantic
modelling and historical research”. The accepted candidate will work with
scholars from the School in Higher Educational Research (
https://unitedoc.it/) and semantic data experts at Takin.solutions (
https://www.takin.solutions/) in creating a research project that explores
the cutting edge in applying semantic data modelling techniques to pushing
forward historical research.

The suitable candidate will have a relevant background in historical
research (the topic of research for the PhD must fall in the space of early
modern history) and research data management, ideally with some
pre-existing knowledge of formal ontology and semantic data modelling
techniques. The description of the project scope can be found in the
attached document.

The specific description of the topic is:

“The intersection of semantic data modelling and historical research

The aim of this research project is to formulate a set of historical
questions and to develop a set of methodologies through the approach of
digital humanities. The PhD student will work with ontologies (in
particular CIDOC CRM) and adapt them to suitable platforms. An important
part of the work will be the study of historical case studies and the
development of a corresponding model. More specifically, the PhD will look
at building semantic data models adequate to support historical research
questions, working with real case studies from the early modern
Mediterranean. such as, for example, diasporas, forced and voluntary
migrations. Or trade dynamics. Building from real world historical data as
use cases. the researcher will explore the affordances that semantic data
model ling offers to support and facilitate an increasingly digital first
historical research practice. The research will thus look at the
applicability of well known ontological models such as CIDOC CRM lo
historical

research questions but also look at the suite of tools and methods around
semantic data management that need to be mastered to support historical
research. The researcher will explore how semantic data methods from
semantic data modelling to its application in real research scenarios. can
be ameliorated through the chaining together of appropriate tools and
techniques for creating and working with semantic historical data in a FAIR
context.”


The PhD specifically aims to create an intersection between formal academic
research and the development of professional skills such that the
successful candidate will complete both a research PhD and walk away with
applicable professional skills in the domain of semantic data management.

Details on how to apply and specific requirements are to be found here:

https://www.unite.it/UniTE/Ricerca/Dottorati_di_ricerca/Bando_di_concorso_per_l_ammissione_a_corsi_di_dottorato_di_ricerca_-_XL_ciclo_-_anno_accademico_2024_2025


Or here:

https://unitedoc.it/calls

The deadline for application is 19/6/2024.

The PhD will be written in the English language.

Please contact mailus@takin.solutions for further information
___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

Re: [Crm-sig] Fwd: CRM SIG in Plovdiv: Sign Up!

[George Bruseker via Crm-sig]

Dear all,

Another bump on this email. Many of you who have indicated that you intend
to come and want to stay at the event hotel have already written to them to
confirm your interest. Thank you!

It is a big help if everyone who is interested to stay there contacts the
hotel (details in the last email on this thread) as soon as you can to
indicate that you do indeed want to come, how many days, which days and
your chosen room type. They in any case will not charge you or require any
financial information at this time. They will simply make a note of it and
send you a payment link in the summer (August I believe).

Best,

George


On Tue, Apr 30, 2024 at 4:33 PM George Bruseker 
wrote:

> Dear all,
>
> We are pleased to announce that we have found the venue for the "59th
> CIDOC CRM & 52nd FRBR/LRMoo SIG Meeting" that will be hosted by
> Takin.solutions in Plovdiv, Bulgaria.
>
> The venue for the meeting will be Hotel Imperial Plovdiv.
> <https://hotelimperial.bg/>
>
> If you are interested in staying at the venue hotel, please read the
> following information carefully and act on it.
>
> Hotel Imperial Plovdiv is an attractive and comfortable venue with nice
> facilities which we hope will be a great environment for working together
> on advancing the CIDOC CRM and its extensions as an international standard
> for semantic data creation and management. The conference room has full
> audio visual and wifi facilities which should enable us to host a hybrid
> meeting, though we hope to welcome as many of you as possible to the
> beautiful city of Plovdiv, for productive ontology conversations and a
> great foody nightlife.
>
> As part of arranging this venue for the event, we were able to secure more
> advantageous prices for SIG members who are interested in staying at the
> venue. The following are the relevant rates and features of the hotel:
>
> Rooms:
>
>1.
>
>Standard Single room - 129 BGN per night
>2.
>
>Standard Double room - 164 BGN per night
>3.
>
>Premium Single room - 153 BGN per night
>4.
>
>Premium Double room - 188 BGN per night
>
> If you think of prices in Euro, take that number and divide it roughly in
> two.
>
> All room prices include:
>
>-
>
>Breakfast,
>-
>
>Parking,
>-
>
>Fitness,
>-
>
>Wifi,
>-
>
>Press reader (magazines and newspapers)
>-
>
>Wellness zone (unlimited usage of different saunas, jacuzzi,
>relaxation zone and more)
>
> Check in 15:00 pm
>
> Check out: 12:00 pm
>
> At present the hotel is holding up to 25 rooms for participants who want
> to stay at the hotel and take advantage also of the above rates. If you
> want to book at the hotel at these rates, please contact:
> events.imperialplov...@radissonindividuals.com ccing
> vesselina@takin.solutions  and george@takin.solutions between now and the
> end of May to reserve your room and make your payment / deposit. After that
> time they may stop holding these rooms at a better rate for us. In your
> email please include that the booking is for the SIG Meeting hosted by
> Takin.solutions, so they know for which event you are coming.
>
> Participants in the SIG are obviously free to choose to stay where they
> like in the city and there are probably many great airbnbs and other hotels
> which you could stay at if you prefer. There is no obligation to stay at
> this venue if you are coming but want to stay elsewhere.
>
>
> Looking forward to seeing you in Plovdiv.
>
>
> Best,
>
>
> George
>
>
>
> On Tue, Apr 23, 2024 at 10:35 AM George Bruseker via Crm-sig <
> crm-sig@ics.forth.gr> wrote:
>
>> Dear all,
>>
>> Thank you for your input on your attendance plans for the SIG planned for
>> this fall in Plovdiv. Currently we have +-15 certain attendees. Based on
>> this information, we are contacting the potential venues for the meeting
>> both to book our meeting room but also to seek out potential better room
>> rates if we book under a group rate at one hotel. Once we have solid
>> feedback from that, we will contact those who have indicated that they are
>> certainly coming with more information and to seek feedback on whether you
>> are interested in staying at the group rate hotel. We will of course not
>> proceed with any booking without seeking your input.
>>
>> Of course, we are still many months away from the meeting, so if you
>> haven't indicated that you are coming and are still interested in the group
>> rate or just to let us know that you are or aren't coming, please do add
>> yourself to the list above.
>>
>

Re: [Crm-sig] Fwd: CRM SIG in Plovdiv: Sign Up!

[George Bruseker via Crm-sig]

Dear all,

We are pleased to announce that we have found the venue for the "59th CIDOC
CRM & 52nd FRBR/LRMoo SIG Meeting" that will be hosted by Takin.solutions
in Plovdiv, Bulgaria.

The venue for the meeting will be Hotel Imperial Plovdiv.
<https://hotelimperial.bg/>

If you are interested in staying at the venue hotel, please read the
following information carefully and act on it.

Hotel Imperial Plovdiv is an attractive and comfortable venue with nice
facilities which we hope will be a great environment for working together
on advancing the CIDOC CRM and its extensions as an international standard
for semantic data creation and management. The conference room has full
audio visual and wifi facilities which should enable us to host a hybrid
meeting, though we hope to welcome as many of you as possible to the
beautiful city of Plovdiv, for productive ontology conversations and a
great foody nightlife.

As part of arranging this venue for the event, we were able to secure more
advantageous prices for SIG members who are interested in staying at the
venue. The following are the relevant rates and features of the hotel:

Rooms:

   1.

   Standard Single room - 129 BGN per night
   2.

   Standard Double room - 164 BGN per night
   3.

   Premium Single room - 153 BGN per night
   4.

   Premium Double room - 188 BGN per night

If you think of prices in Euro, take that number and divide it roughly in
two.

All room prices include:

   -

   Breakfast,
   -

   Parking,
   -

   Fitness,
   -

   Wifi,
   -

   Press reader (magazines and newspapers)
   -

   Wellness zone (unlimited usage of different saunas, jacuzzi, relaxation
   zone and more)

Check in 15:00 pm

Check out: 12:00 pm

At present the hotel is holding up to 25 rooms for participants who want to
stay at the hotel and take advantage also of the above rates. If you want
to book at the hotel at these rates, please contact:
events.imperialplov...@radissonindividuals.com ccing
vesselina@takin.solutions  and george@takin.solutions between now and the
end of May to reserve your room and make your payment / deposit. After that
time they may stop holding these rooms at a better rate for us. In your
email please include that the booking is for the SIG Meeting hosted by
Takin.solutions, so they know for which event you are coming.

Participants in the SIG are obviously free to choose to stay where they
like in the city and there are probably many great airbnbs and other hotels
which you could stay at if you prefer. There is no obligation to stay at
this venue if you are coming but want to stay elsewhere.


Looking forward to seeing you in Plovdiv.


Best,


George



On Tue, Apr 23, 2024 at 10:35 AM George Bruseker via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear all,
>
> Thank you for your input on your attendance plans for the SIG planned for
> this fall in Plovdiv. Currently we have +-15 certain attendees. Based on
> this information, we are contacting the potential venues for the meeting
> both to book our meeting room but also to seek out potential better room
> rates if we book under a group rate at one hotel. Once we have solid
> feedback from that, we will contact those who have indicated that they are
> certainly coming with more information and to seek feedback on whether you
> are interested in staying at the group rate hotel. We will of course not
> proceed with any booking without seeking your input.
>
> Of course, we are still many months away from the meeting, so if you
> haven't indicated that you are coming and are still interested in the group
> rate or just to let us know that you are or aren't coming, please do add
> yourself to the list above.
>
> Best,
>
> George
>
> On Fri, Apr 12, 2024 at 9:34 AM Eleni Tsouloucha via Crm-sig <
> crm-sig@ics.forth.gr> wrote:
>
>> Dear all,
>>
>> This is a reminder that the 59th SIG meeting will take place on the week
>> 23-27 September 2024 at Plovdiv.
>> For those of you that plan to attend in person, George Bruseker
>> (Takin.solutions) has prepared a document with useful information on
>> getting to Plovdiv plus interesting sites to visit and cool things to
>> do, while you're there.
>> Like  George   said in his email, in order to host so many people in
>> person,Takin.solutions will be renting a conference space to hold the
>> meetings. One option is to rent a space in a hotel where participants can
>> also stay, which should provide reduced rates for attendees too. To this
>> end, George has created a sign-up sheet, where he invites in-person
>> participants to confirm that they will show up for the meeting and also
>> indicate whether they are interested in staying at the same hotel where the
>> meeting will take place. Online participants are invited to indicate that
>> they will n

Re: [Crm-sig] Fwd: CRM SIG in Plovdiv: Sign Up!

[George Bruseker via Crm-sig]

Dear all,

Thank you for your input on your attendance plans for the SIG planned for
this fall in Plovdiv. Currently we have +-15 certain attendees. Based on
this information, we are contacting the potential venues for the meeting
both to book our meeting room but also to seek out potential better room
rates if we book under a group rate at one hotel. Once we have solid
feedback from that, we will contact those who have indicated that they are
certainly coming with more information and to seek feedback on whether you
are interested in staying at the group rate hotel. We will of course not
proceed with any booking without seeking your input.

Of course, we are still many months away from the meeting, so if you
haven't indicated that you are coming and are still interested in the group
rate or just to let us know that you are or aren't coming, please do add
yourself to the list above.

Best,

George

On Fri, Apr 12, 2024 at 9:34 AM Eleni Tsouloucha via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear all,
>
> This is a reminder that the 59th SIG meeting will take place on the week
> 23-27 September 2024 at Plovdiv.
> For those of you that plan to attend in person, George Bruseker
> (Takin.solutions) has prepared a document with useful information on
> getting to Plovdiv plus interesting sites to visit and cool things to
> do, while you're there.
> Like  George   said in his email, in order to host so many people in
> person,Takin.solutions will be renting a conference space to hold the
> meetings. One option is to rent a space in a hotel where participants can
> also stay, which should provide reduced rates for attendees too. To this
> end, George has created a sign-up sheet, where he invites in-person
> participants to confirm that they will show up for the meeting and also
> indicate whether they are interested in staying at the same hotel where the
> meeting will take place. Online participants are invited to indicate that
> they will not be joining in person.
>
> Please make sure to fill out the form *by Tuesday 16 April 2024*.
>
> Info on Plovdiv
> <https://docs.google.com/presentation/d/19Yy9Wrdk-egBER4baAdeUAY_-jihFQo-D8WxAsDLVWI/edit?usp=sharing>
>
> Attendance sheet
> <https://docs.google.com/spreadsheets/d/1TKHJjHaXZhHucdEaH-gWjGM5Fbm50H7LIjo07irKO9Q/edit?usp=sharing>
>
> Best,
> Eleni
>
>
> -- Forwarded message -
> From: George Bruseker via Crm-sig 
> Date: Fri, Mar 22, 2024 at 4:49 PM
> Subject: [Crm-sig] CRM SIG in Plovdiv: Sign Up!
> To: crm-sig 
>
>
> Dear all,
>
> As discussed yesterday in the CRM SIG session hosted by the BNF in Paris,
> the fall meeting of the CRM SIG will be held in Plovdiv, Bulgaria and be
> hosted by Takin.solutions.
>
> In order to let people know a little bit more about our home city, we
> have prepared the following powerpoint which indicates how to get to
> Plovdiv and some of the things you can enjoy while there.
>
>
> https://docs.google.com/presentation/d/19Yy9Wrdk-egBER4baAdeUAY_-jihFQo-D8WxAsDLVWI/edit?usp=sharing
>
> Moreover, in order to host so many people in person,Takin.solutions will
> be renting a conference space to hold the meetings. One option we are
> considering is to rent a space in a hotel where participants can also stay
> which should provide a better rate for attendees and for the conference
> room.
>
> Therefore, we have created this sign-up sheet to ask those who are
> definitely attending (or not attending) the next SIG in person to indicate
> this fact as well as if they are interested in staying in a shared
> accommodation. We have put two options we are looking at in the powerpoint.
>
>
> https://docs.google.com/spreadsheets/d/1TKHJjHaXZhHucdEaH-gWjGM5Fbm50H7LIjo07irKO9Q/edit#gid=0
>
> Please take the time to indicate your participation intentions as soon as
> possible and ideally before April 12, 2024. We will obviously contact
> participants who are interested in staying in the group hotel before making
> any formal arrangement in order to indicate the final rate offered and
> confirm your interest.
>
> Sincerely,
>
> George Bruseker
>
>
>
> ___
> Crm-sig mailing list
> Crm-sig@ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>
>
> --
> Eleni Tsouloucha
> Philologist - MA Linguistics & Language Technologies
> Center for Cultural Informatics
> Information Systems Laboratory - Institute of Computer Science
> Foundation for Research and Technology - Hellas (FORTH)
>
> Address: N. Plastira 100, GR-70013 Heraklion, Grece
> email: tsoulo...@isc.forth.gr, eleni.crm@gmail.com
> Tel: +30 2810391488
> ___
> Crm-sig mailing lis

[Crm-sig] CIDOC 2024 {Sustainable Connections: Building Knowledge Networks}

[George Bruseker via Crm-sig]

Dear all,

I am writing to share information on the call for contributions of the next
International Council of Documentation (CIDOC) conference.

The conference will take place in Amsterdam this year from 11-15 of
November and will be hosted by the Rijksmuseum.

The topic is:

Sustainable Connections: Building Knowledge Networks

Read about it in detail here:

https://www.rijksmuseum.nl/en/whats-on/lectures-symposiums/cidoc2024

As you will see in the conference description the idea of knowledge
networks is interpreted broadly; that said, an important subsection of work
is expected to be on semantic knowledge networks, how to build, sustain and
leverage them. There is even a hackathon event for linked open data the
weekend before which participants might consider participating in.

Given the expertise in this knowledge network on these topics, and of
course our affiliation under CIDOC, I thought I would highlight this year's
conference to the group in case you would be interested in participating.

Sincerely,

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

[Crm-sig] CRM SIG in Plovdiv: Sign Up!

[George Bruseker via Crm-sig]

Dear all,

As discussed yesterday in the CRM SIG session hosted by the BNF in Paris,
the fall meeting of the CRM SIG will be held in Plovdiv, Bulgaria and be
hosted by Takin.solutions.

In order to let people know a little bit more about our home city, we
have prepared the following powerpoint which indicates how to get to
Plovdiv and some of the things you can enjoy while there.

https://docs.google.com/presentation/d/19Yy9Wrdk-egBER4baAdeUAY_-jihFQo-D8WxAsDLVWI/edit?usp=sharing

Moreover, in order to host so many people in person,Takin.solutions will be
renting a conference space to hold the meetings. One option we are
considering is to rent a space in a hotel where participants can also stay
which should provide a better rate for attendees and for the conference
room.

Therefore, we have created this sign-up sheet to ask those who are
definitely attending (or not attending) the next SIG in person to indicate
this fact as well as if they are interested in staying in a shared
accommodation. We have put two options we are looking at in the powerpoint.

https://docs.google.com/spreadsheets/d/1TKHJjHaXZhHucdEaH-gWjGM5Fbm50H7LIjo07irKO9Q/edit#gid=0

Please take the time to indicate your participation intentions as soon as
possible and ideally before April 12, 2024. We will obviously contact
participants who are interested in staying in the group hotel before making
any formal arrangement in order to indicate the final rate offered and
confirm your interest.

Sincerely,

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

[Crm-sig] Linking Linked Data in Art History Interest Group (online, 25 Apr-1 Nov 24)

[George Bruseker via Crm-sig]

Dear all,

I just wanted to share this initiative with you in case it speaks to you
personally or scholars and researchers in your  networks and communities.

https://arthist.net/archive/41183

It is an effort conceived and led by historians to discuss from their
perspective  the potential use of linked data to their work.

All the best,

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

Re: [Crm-sig] Example for propositional objects

[George Bruseker via Crm-sig]

Other fun examples from philosophy could be the Dao De Jing for which there
are radically different translations that assume different propositional
content. Wittgenstein scholarship also has, I believe, extensive archival
numbering system and a developed commentary practice around the number
information objects ascribing different propositional contents to them.
Could go on a hunt for some of those.

On Sat, Jan 13, 2024 at 9:25 AM George Bruseker 
wrote:

> Dear Martin et al.,
>
> If what you mean by using the practice of referencing Bekker numbers as an
> example for propositional object is to create a complex example that spans
> multiple classes and properties and illustrates the interrelation between
> information object and propositional object and potentially symbolic
> object, that can be a nice illustration of that complex of classes and
> properties in CIDOC CRM which many people struggle to understand.
>
> That said, the example should then probably be drawn from a real world
> scenario. The Bekker numbers are identifiers for an information object not
> a propositional object. So one could talk about the imagined meaning of the
> passage according to one author but this would not be a super convincing
> example. As I mentioned people tend to be fundamentally contesting the
> meaning of the passage (it is not the case like in positive science that we
> are slowly over time converging to the one agreed meaning of Plato or
> Aristotle that everyone believes is the case), arguing that one or the
> other thing has a completely different propositional content.
>
> So if we wanted a good example on this, we should try to look for a
> passage with a well known debate around it where important scholar A
> contends that this one information object with Bekker number X has meaning
> Y and then scholar A contends that the same information object with Bekker
> number X has meaning Q. Y and Q can be our examples of propositional
> objects.
>
> I obviously don't have an example in my mind at the moment, but such
> arguments are pretty much the heart of interpreting ancient texts, so  it
> shouldn't be hard to find one.
>
> Would that find your agreement?
>
> George
>
>
>
>
> On Wed, Jan 10, 2024 at 3:58 PM Martin Doerr  wrote:
>
>> Dear George,
>>
>> Yes, I am very much aware of what you are describing and completely
>> agree. I am right now looking for the original text. The text itself in
>> Bekker's edition constitutes a Symbolic Object with propositional meaning,
>> an Expression in the sense of FRBR.
>> The search for precision is one aspect of what we do.
>>
>> The other aspect is accepting a certain fuzziness. The class E89
>> Propositional Object was introduced to capture the sense of FRBR Work,
>> which, *in one interpretation*, constitutes an abstraction of meaning
>> from the symbolic form, in particular from translations.
>>
>> As "knowledge engineer" I just neutrally observe, that sufficient people
>> support the idea of some sort of preservation of meaning across
>> translations, and others vehemently oppose. In the christian theological
>> background, authorized translations are regarded as "the Word of God",
>> i.e., transferring an even identical and in any case comprehensible
>> meaning, which, within this tradition, must not be questioned. Medieval
>> theological and philosophical tradition was widely using Aristotle in Latin
>> translation without questioning the essential transfer of meaning by the
>> Latin text.
>>
>> We need also not forget that early Latin (and Arabic) translators were
>> much closer to the common senses of the ancient Greek world. As such, our
>> ability today approximating the Greek original meaning from its linguistic
>> expression only may not necessarily be superior to consulting also relevant
>> translations.
>>
>> As such, my position about the preservation of meaning across
>> translations is an observational one.
>>
>> I assume you agree, that undeniably scholars around the world cite such
>> texts in translated form, and refer via Bekker identifiers in their
>> citations, often without referring to the translator at all (regarded as
>> "editor" and not "author" as I just read in a scholarly text !), expressing
>> that they mean the intended meaning of the corresponding original,
>> approximated by the translation provided.
>>
>> Since the CRM project is not about absolute precision, but about "minimal
>> ontological commitment" in the sense of Thomas Gruber, for the purpose of 
>> *information
>> integration*, rather than resolution, 

Re: [Crm-sig] Example for propositional objects

[George Bruseker via Crm-sig]

 a comment with translations in 3 languages and the original. I
> currently have a German and two English ones (below) at hand:
>
> “the same thing cannot at the same time belong and also not belong to the
> same thing and in the same respect”
> "It is impossible for the same attribute at once to belong and not to
> belong [20] to the same thing and in the same relation;
> (Met.Г 4.3,1005b19-20)
>
> Thus stated, users can make up their own mind about the common meaning in
> this example, isn't it?
>
> Would that find your agreement?
>
> Best,
>
> Martin
>
> On 1/10/2024 8:30 AM, George Bruseker wrote:
>
> Dear Martin,
>
> As a scholar of ancient philosophy, I do love Bekker numbers, but I am
> curious why they would be an example of propositional object. They are a
> reference to a particular chunk of text in the original Greek as setup in
> the Bekker edition. As such, I think as a scholar using ancient texts, I
> use it to locate the original Information Object upon which an
> interpretation (formulation of the proposition(s) that we think thinker X
> was making) is based. The exact propositional content of that information
> object is usually the subject of debate rather than the object of
> reference. Did Aristotle mean X or Y in passage 99a of the Posterior
> Analytics, is the usual topic of conversation. If we knew the exact
> propositional content, we'd be golden, but usually that is the very topic
> we want to endlessly swirl around and the Bekker number is the pointer for
> people who can read ancient Greek in order to be able to find the original
> passage, read it, translate it and cogitate on what was really meant there
> (the propositions encoded).
>
> But perhaps you have another use in mind?
>
>  Best,
>
> George
>
> On Sat, Jan 6, 2024 at 7:25 PM Martin Doerr via Crm-sig <
> crm-sig@ics.forth.gr> wrote:
>
>> Dear All,
>>
>> I suggest to create an example using Bekker numbers. They constitute
>> excellent examples of identifiers for propositional content.
>>
>> See https://guides.library.duq.edu/c.php?g=1030408=7468217
>>
>> --
>> 
>>  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
>>
>>  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
>>
>
>
> --
> 
>  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
>
>  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

Re: [Crm-sig] Example for propositional objects

[George Bruseker via Crm-sig]

Dear Achille,

Yeah, clearly the Bekker numbers themselves are not propositional objects
but identifiers. But I don't think that they are identifiers for
propositional objects. They are identifiers for chunks of text in an
edition, an information object which has a series of symbols and may encode
one or more propositions. The Bekker number literally points to a section
of a text as an edition, so the principle of identity is symbols not
propositions. There is no correlation between a Bekker number and a
proposition or set thereof. The Bekker number can point you to a passage in
the 'original' Bekker edition and it is used for cross correlation when you
want to see where your translation might match to the Bekker (so that you
can read the original Greek and see if you think that is what so and so is
saying).  So it is generally a modelling situation of E73s composed of
(p106) E73. If it were an identifier for a proposition then the principle
of identity would be to break down the propositions (noetic content) that
are encoded by the words and then give them identifiers (the propositions
not the encoded symbols) and then put them together by P148.

Or at least this is how I know Bekker numbers to be used in actual
practice. In a work on ancient philosophy if you are going to refer to
Aristotle or some other author and their passages, you don't quote Penguin
English, you quote the Bekker. And then, you say what it means (the
propositions).

Cheers,

George



On Wed, Jan 10, 2024 at 11:15 AM Achille Felicetti <
achille.felice...@pin.unifi.it> wrote:

> Dear George,
>
> What I read in Martin's email is that Bekker numbers are examples of
> identifiers for propositional content, not propositional objects themselves.
>
> Which, it seems to me, is not so far from your thoughts :-)
>
> Ciao,
> A.
>
> Il giorno 10 gen 2024, alle ore 07:30, George Bruseker via Crm-sig <
> crm-sig@ics.forth.gr> ha scritto:
>
> Dear Martin,
>
> As a scholar of ancient philosophy, I do love Bekker numbers, but I am
> curious why they would be an example of propositional object. They are a
> reference to a particular chunk of text in the original Greek as setup in
> the Bekker edition. As such, I think as a scholar using ancient texts, I
> use it to locate the original Information Object upon which an
> interpretation (formulation of the proposition(s) that we think thinker X
> was making) is based. The exact propositional content of that information
> object is usually the subject of debate rather than the object of
> reference. Did Aristotle mean X or Y in passage 99a of the Posterior
> Analytics, is the usual topic of conversation. If we knew the exact
> propositional content, we'd be golden, but usually that is the very topic
> we want to endlessly swirl around and the Bekker number is the pointer for
> people who can read ancient Greek in order to be able to find the original
> passage, read it, translate it and cogitate on what was really meant there
> (the propositions encoded).
>
> But perhaps you have another use in mind?
>
>  Best,
>
> George
>
> On Sat, Jan 6, 2024 at 7:25 PM Martin Doerr via Crm-sig <
> crm-sig@ics.forth.gr> wrote:
>
>> Dear All,
>>
>> I suggest to create an example using Bekker numbers. They constitute
>> excellent examples of identifiers for propositional content.
>>
>> See https://guides.library.duq.edu/c.php?g=1030408=7468217
>>
>> --
>> 
>>  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
>>
>>  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
>
>
>
___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

Re: [Crm-sig] Example for propositional objects

[George Bruseker via Crm-sig]

Dear Martin,

As a scholar of ancient philosophy, I do love Bekker numbers, but I am
curious why they would be an example of propositional object. They are a
reference to a particular chunk of text in the original Greek as setup in
the Bekker edition. As such, I think as a scholar using ancient texts, I
use it to locate the original Information Object upon which an
interpretation (formulation of the proposition(s) that we think thinker X
was making) is based. The exact propositional content of that information
object is usually the subject of debate rather than the object of
reference. Did Aristotle mean X or Y in passage 99a of the Posterior
Analytics, is the usual topic of conversation. If we knew the exact
propositional content, we'd be golden, but usually that is the very topic
we want to endlessly swirl around and the Bekker number is the pointer for
people who can read ancient Greek in order to be able to find the original
passage, read it, translate it and cogitate on what was really meant there
(the propositions encoded).

But perhaps you have another use in mind?

 Best,

George

On Sat, Jan 6, 2024 at 7:25 PM Martin Doerr via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear All,
>
> I suggest to create an example using Bekker numbers. They constitute
> excellent examples of identifiers for propositional content.
>
> See https://guides.library.duq.edu/c.php?g=1030408=7468217
>
> --
> 
>  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
>
>  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 519, use of "preferred identifier" and "current permanent location"

[George Bruseker via Crm-sig]

Agreed. And it would make the standard more compact, an important principle!

Deprecate

On Thu, 12 Oct 2023 at 6:30 PM Robert Sanderson via Crm-sig <
crm-sig@ics.forth.gr> wrote:

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

Re: [Crm-sig] Issue: P168i defines place shortcut

[George Bruseker via Crm-sig]

Hi Martin,

On this one continue to disagree. Yes the intention of the statement is to
say that the instances of this class and their construction are meant to be
formulated in data standards outside of CRM. The user of CRM absolutely
should interpret this and understand it. And the basics of ontology are
that isA states that an instance of a subclass is also an instance of its
superclass. If the superclass is meant to not be interpreted in CRM but be
outside its world, then all of its subclasses should also not be
interpreted within CRM. Otherwise it would be like saying that some
subclasses of temporal entity can not be, ontologically, temporal, or some
subclasses of conceptual object can be, ontologically, other than
conceptual. That would be a logical contradiction.

Best,

George

On Wed, Oct 4, 2023 at 10:18 PM Martin Doerr via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> I think we have an interpretation problem here :
>
> "are not considered elements of the universe of discourse the CIDOC CRM
> aims to define and analyse".
>
> This is not a statement what users of the CRM should consider when they
> use the CRM. The CRM does not intend to analyse the Geospatial Standards,
> but interfaces to them, and recommends their use. It does not deal with the
> way computers store real numbers, integers etc, but interfaces to them and
> recommends their use. Exactly as RDF does *not analyze xsd values*, but
> interfaces to them and recommends their use. The linking construct in RDF
> is the *Literal*. Similarly, CRM defines some highlevel classes, to be
> filled with formats others analyze and define. Analyzing a superclass does
> not mean to analyze and define the subclasses.
>
> If this sense of the statement is not clear enough, please reformulate
> adequately.
>
> Best,
>
> Martin
>
>
> On 10/3/2023 9:59 AM, George Bruseker via Crm-sig wrote:
>
> The duality of primitives as being in and out of of the universe of a
> discourse is a problem
>
> On Tue, Oct 3, 2023 at 9:45 AM Schmidle, Wolfgang via Crm-sig <
> crm-sig@ics.forth.gr> wrote:
>
>> Okay, last one. I had overlooked P82 "at some time within", and of course
>> there is also P172 "contains" and P81 "ongoing throughout". The questions
>> about P171 also apply to P172 / P81 / P82.
>>
>> So many possible shortcuts. Was there a reason for not making E94 Space
>> Primitive a subclass of E53 Place? i.e. is it more on the side of "Period
>> is a Spacetime Volume" or "Physical Thing defines but is not a Spacetime
>> Volume"? The E59 scope note says "The instances of E59 Primitive Value and
>> its subclasses are not considered elements of the universe of discourse the
>> CIDOC CRM aims to define and analyse", but with E94 being a subclass of
>> Appellation this might no longer be entirely accurate anyway.
>>
>>
>> > Am 01.10.2023 um 14:09 schrieb Schmidle, Wolfgang via Crm-sig <
>> Crm-sig@ics.forth.gr>:
>> >
>> > Some additional questions:
>> >
>> > P189 and P171:
>> > E53 Place P171 at some place within E94 Space Primitive
>> > is a strong shortcut of
>> > E53 Place P89 falls within E53 Place P168 place is defined by E94 Space
>> Primitive
>> >
>> > Should P171 and the proposed "is approximated by" shortcut be either
>> both in CRMbase or both in CRMgeo?
>> >
>> > Would P171 be called "falls within" if it were introduced now?
>> >
>> > Should there be versions of P171 for time and spacetime volumes? i.e.
>> > E93 Spacetime Volume P10 falls within SP7 Declarative Spacetime Volume
>> P169i spacetime volume is defined by E95 Spacetime Primitive
>> > E52 Time-Span P86 falls within SP10 Declarative Time-Span P170i time is
>> defined by E61 Time Primitive
>> >
>> > P189 and Q11:
>> > Does P189 indeed represent the same concept as Q11 in CRMgeo (v1.2)?
>> For example, P189 is marked as reflexive (i.e. any place approximates
>> itself), which is not possible for Q11 since its domain and range are not
>> the same (Declarative Place approximates Place).
>> >
>> > P189 and P7:
>> > E4 Period P7 took place at E53 Place
>> > is an inverse shortcut of
>> > E4 Period P161 has spatial projection E53 Place P89 falls within E53
>> Place
>> > P7(x,y) ⇒ (∃z) [E53(z) ∧ P161(x,z) ∧ P89(z,y)]
>> > (leaving out the "same reference system" requirements)
>> >
>> > Could one say that it becomes a strong shortcut if we add the "will to
>> approximate" to the long version? i.e.
>>

Re: [Crm-sig] Issue: P168i defines place shortcut

[George Bruseker via Crm-sig]

The duality of primitives as being in and out of of the universe of a
discourse is a problem

On Tue, Oct 3, 2023 at 9:45 AM Schmidle, Wolfgang via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Okay, last one. I had overlooked P82 "at some time within", and of course
> there is also P172 "contains" and P81 "ongoing throughout". The questions
> about P171 also apply to P172 / P81 / P82.
>
> So many possible shortcuts. Was there a reason for not making E94 Space
> Primitive a subclass of E53 Place? i.e. is it more on the side of "Period
> is a Spacetime Volume" or "Physical Thing defines but is not a Spacetime
> Volume"? The E59 scope note says "The instances of E59 Primitive Value and
> its subclasses are not considered elements of the universe of discourse the
> CIDOC CRM aims to define and analyse", but with E94 being a subclass of
> Appellation this might no longer be entirely accurate anyway.
>
>
> > Am 01.10.2023 um 14:09 schrieb Schmidle, Wolfgang via Crm-sig <
> Crm-sig@ics.forth.gr>:
> >
> > Some additional questions:
> >
> > P189 and P171:
> > E53 Place P171 at some place within E94 Space Primitive
> > is a strong shortcut of
> > E53 Place P89 falls within E53 Place P168 place is defined by E94 Space
> Primitive
> >
> > Should P171 and the proposed "is approximated by" shortcut be either
> both in CRMbase or both in CRMgeo?
> >
> > Would P171 be called "falls within" if it were introduced now?
> >
> > Should there be versions of P171 for time and spacetime volumes? i.e.
> > E93 Spacetime Volume P10 falls within SP7 Declarative Spacetime Volume
> P169i spacetime volume is defined by E95 Spacetime Primitive
> > E52 Time-Span P86 falls within SP10 Declarative Time-Span P170i time is
> defined by E61 Time Primitive
> >
> > P189 and Q11:
> > Does P189 indeed represent the same concept as Q11 in CRMgeo (v1.2)? For
> example, P189 is marked as reflexive (i.e. any place approximates itself),
> which is not possible for Q11 since its domain and range are not the same
> (Declarative Place approximates Place).
> >
> > P189 and P7:
> > E4 Period P7 took place at E53 Place
> > is an inverse shortcut of
> > E4 Period P161 has spatial projection E53 Place P89 falls within E53
> Place
> > P7(x,y) ⇒ (∃z) [E53(z) ∧ P161(x,z) ∧ P89(z,y)]
> > (leaving out the "same reference system" requirements)
> >
> > Could one say that it becomes a strong shortcut if we add the "will to
> approximate" to the long version? i.e.
> > P7(x,y) ⇔ (∃z) [E53(z) ∧ P161(x,z) ∧ P89(z,y) ∧ P189i(z,y)]
> >
> > This is not far away from Rob's starting point in issue 439 (Approximate
> Dimensions). In this issue, Martin argues that P189 shouldn't be used when
> one can establish "falls within". But it seems to me that
> > P89 + P189i = "is approximated from the outside by"
> > would work very well together.
> >
> > Best,
> > Wolfgang
> >
> >
> >> Am 26.09.2023 um 11:25 schrieb Schmidle, Wolfgang via Crm-sig <
> Crm-sig@ics.forth.gr>:
> >>
> >> I assume that P189i is the same as Q11i in CRMgeo. Since the shortcut
> would be in CRMgeo anyway, would it make sense to define shortcuts for STVs
> and Time-Spans in CRMgeo as well? I.e. for
> >>
> >> E93 Spacetime Volume Q12i is approximated by SP7 Declarative Spacetime
> Volume P169i spacetime volume is defined by E95 Spacetime Primitive
> >>
> >> E52 Time-Span Q13i is approximated by SP10 Declarative Time-Span P170i
> time is defined by E61 Time Primitive
> >>
> >> Best,
> >> Wolfgang
> >>
> >>
> >>> Am 25.09.2023 um 11:20 schrieb Martin Doerr via Crm-sig <
> crm-sig@ics.forth.gr>:
> >>>
> >>> Dear All,
> >>>
> >>> I propose a shortcut in CRMgeo for E53 Place P189i is approximated by:
> E53 Place P168 place is defined by : E94 Space Primitive,
> >>> for obvious practical reasons. It can have the same label.
> >>>
> >>> 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,
>

Re: [Crm-sig] Evaluation of a learning tool based on gamified graph modeling

[George Bruseker via Crm-sig]

Dear Kai,

Thank you for the update on your work! This is an important segment of
CIDOC CRM work, to create means for appropriating the model and applying
it. I am sure this will be of interest to many in the group and will merit
further discussion.

Sincerely,

George


On Fri, Aug 25, 2023 at 5:56 PM Kai Niebes via Crm-sig 
wrote:

> Dear all,
>
> At the 50th CIDOC CRM SIG meeting, I presented a prototype web
> application (meeting topic "A pedagogical graph-based visualization
> tool for CRM") for users to learn to model using an interactive graph
> when given modeling tasks.
>
> The original prototype was never followed up, but as part of a thesis
> I'm writing, I revisited the idea and spent some time developing a
> successor, with an increased focus on a task system where tasks are
> divided into several exemplary levels of varying difficulty, and a
> system that allows users to search & explore relevant parts of the
> documentation without leaving the application.
>
> To evaluate this application, I am now looking for willing and helpful
> testers to see if this gamified approach works for understanding the
> basic concepts of the CRM, and if the ubiquitous, searchable
> documentation tool within the application encourages exploration of
> the available classes and properties of the CRM.
>
> If you have time and are interested, the hosted web application is
> currently available here:
> https://cidoc-crm-insight.pages.dev/
>
> As this is also my first post to the mailing list, I hope I have not
> disturbed its peace and that this message finds its readers.
>
> All the best and many thanks,
> Kai Niebes
> Institute for Digital Humanities
> University of Cologne
>
> PS: Due to the focus of my thesis, the application is strictly
> intended as an educational modeling tool, not as a general modeling
> tool, therefore no import or export functionality of any kind is
> included.
>
> ---
> Additional notes for the interested reader:
> * The code will be released under an open source license sometime in
> September when I finish my thesis.
> * The main frameworks used to develop the web application are Angular
> and Cytoscape.JS.
> * I would also like to test & evaluate the application with students
> unfamiliar with the CRM, but it is the semester break right now.
>
> ___
> 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] Co-Funded PhD Position Takin.solutions and University of Teramo: Historical Research and Semantic Data

[George Bruseker via Crm-sig]

Dear all,


Takin.solutions is excited to announce a co-funded PhD with the University
of Teramo in the areas of semantic data and historical research. The PhD
will focus on research on early modern slavery and traders in Africa and
across the Atlantic. The researcher will create and explore  semantic data
networks representing this information. In the process, they will help
generate new, sustainable methods of data based scholarship. The funded PhD
will work closely with Takin.solutions to learn / extend semantic data
modelling and other digital skills. The researcher will work with the
University of Teramo in original archival research on early modern slavery.
The successful candidate will have a passion for digital humanities, have a
knowledge of or interest in semantic data, and a passion for historical
research. This is a chance to bring new methods to bear on old questions
and to generate new, sustainable methods of data based scholarship. If you
are excited about digital humanities and historical research, come think
and work with us!

Official Position Call Page: https://bit.ly/3NpDRsH

Official Position Description: https://bit.ly/3XnEurm

Application Process: https://bit.ly/3CMY6eR (p.5, point 6)

Apply here: https://pica.cineca.it/unite/phd39

Application deadline July 21, 2023. To learn more, feel free to be in touch.

Please share this with potential interested persons or relevant networks!

Sincerely,

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

Re: [Crm-sig] NEW ISSUE: Statements about Statements.

[George Bruseker via Crm-sig]

 To
>>> be discussed!
>>>
>>>  We can extend E13 to Proposition Sets, which would be very important to
>>> describe consistently CRMinf and generalized observations. That would then
>>> be most effectively implementd via Named Graphs.
>>>
>>> Opinions?
>>>
>>> Best,
>>>
>>> Martin
>>>
>>> On 5/11/2023 3:41 PM, Robert Sanderson wrote:
>>>
>>>
>>> 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 lo

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[George Bruseker via Crm-sig]

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 <
>> http://ceur-ws.org/Vol-1457/SSWS2015_paper3.pdf>
>>
>>
>> Once again, I would like to suggest carefully distinguishing between the
>> CRM domain of discourse, in which the E13 class is conceptualized, and the
>> issue of stating the provenance of the information modelled in the
>> discourse domain, including instances of class E13 as part of the modelled
>> domain.
>>
>> For this last task (or domain of discourse), it would seems reasonable
>> and in line with best practices to use the PROV model and the corresponding
>> PROV-O ontology, a W3C recommendation. Or providing a specific extension of
>> the CRM, compatible and aligned with the PROV model. But using PROV-O seems
>> a good choice in order to facilitate interoperability.
>>
>> There remains the more fundamental question of whether the current debate
>> about RDF implementation is not in fact ind

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[George Bruseker via Crm-sig]

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 <
> http://ceur-ws.org/Vol-1457/SSWS2015_paper3.pdf>
>
>
> Once again, I would like to suggest carefully distinguishing between the
> CRM domain of discourse, in which the E13 class is conceptualized, and the
> issue of stating the provenance of the information modelled in the
> discourse domain, including instances of class E13 as part of the modelled
> domain.
>
> For this last task (or domain of discourse), it would seems reasonable and
> in line with best practices to use the PROV model and the corresponding
> PROV-O ontology, a W3C recommendation. Or providing a specific extension of
> the CRM, compatible and aligned with the PROV model. But using PROV-O seems
> a good choice in order to facilitate interoperability.
>
> There remains the more fundamental question of whether the current debate
> about RDF implementation is not in fact indicative of a more fundamental
> problem related to properties of properties and the implicit and richer
> information they contain, which cannot be adequately expressed in RDF
> without conceptualising them in terms of actual classes. Aren't these
> rather hybrid P(roperty)C(lasses), especially if they should be declared as
> subclasses of E1, to be considered as *de facto* classes and not just
> properties? Because if they are just statements, then adopting one or the
> other form of existing RDF reifications practices seems to be the good way
> to go.
>
> Best
>
> Francesco
>
>
> Le 10.05.23 à 18:48, Martin Doerr via Crm-sig a écrit :
>
> Dear All,
>
> I suggest to resolve the issue of referring to the provenance of .1
> properties more specifically:
>
> Solution a: Add properties to E13 to specify a .1 property. This may be
> more effective than the double indirection via PC class instance and 4
> links of the E13 construct.
>
> Solution b: Use RDF reification for this specific problem via the PC
> class.
>
> We need to examine in both cases the inferences we want to maintain about
> the base property and its domain and range, and what the relevant query
> construct is.
>
> Personally, I prefer solution c: Use the annotation model of CRM Dig,
> which goes via Named Graphs. This is much more performant and logically
> clearer, because Named Graphs are implemented as direct 

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[George Bruseker via Crm-sig]

Hi everyone,

To be clear I at no point suggested changing the ontology specification. I
proposed making the rdfs for pc classes consistent logically. It presently
isn't. If this is too big a leap for some it is not a problem I will just
implement it locally because I can't have unprovenanced statements.

Cheers

George

On Tue, 9 May 2023, 10:39 pm Francesco Beretta via Crm-sig, <
crm-sig@ics.forth.gr> wrote:

> Dear Christian-Emil, All,
>
> For the reasons I detailed in my other email, I totally agree with your
> point of view and would like to raise all possible caveats to this kind of
> mixing up quick and dirty implementation solutions and consistent
> conceptual modelling.
>
> If we need more classes, even on a provisional and experimental
> perspective, I would strongly suggest to produce them and document them as
> such, with stable URIs, and then refine progressively the ontology and
> integrate it into the CRM family. Of course, a nice place to do this is
> ontome.net 
>
> Best
>
> Francesco
>
> Le 08.05.23 à 17:36, Christian-Emil Smith Ore via Crm-sig a écrit :
>
> Also: RDF(S) is an implementation technology. We can assume that there
> exists a implmentation function from the CRM-FOL to RDF(S), but this may
> not be a 1-1 function. Strange constructs like the PC0(?) may not have
> counterparts in CRM-FOL.  Changing the ontology on the bases of
> special tricks used in the implementation may not always be a good idea,
> but may inspire us to make well thought out and consistent changes in the
> ontology.
>
>
> ___
> 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] PC0_Typed_CRM_Property in CRMpc

[George Bruseker via Crm-sig]

t
>> 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_michaelan

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[George Bruseker via Crm-sig]

Hi Rob and Martin,

But the point is not to make assertions about the property class itself but
the instance of the property class.

The instance of PC14 says Bob was the creator, Bob was a faker... it is a
regular abox assertion. And it has an identifier, necessarily.

The instances of PC classes are all already abox statements. They have just
been modelled in an odd way where we don't account for their ontological
substance. Being in a role is an ontological substance to define.

For me it is a big problem if there are statements in the CRM that can be
made (Bob was the builder) but can't be discussed. The abox statement Bob
was the builder is definitely in the domain of discourse and for that
reason should necessarily as a matter of principle be referenceable.

Otherwise, CRMbase cannot state the provenance for a piece of knowledge
like Da Vinci had the role of painter of Mona Lisa. It becomes impossible.
The abox information is in the PC14 instance.

Yes we can use the partitioning pattern which is fine, but it remains a
question of technically what to do about PC classes and it seems only half
baked if they aren't instances of E1. They fit the definition of instances
of E1, "This class comprises all things in the universe of discourse of the
CIDOC Conceptual Reference Model." Being in the role of the painter of Mona
Lisa is, for me, a thing in the universe of discourse of the CIDOC
Conceptual Reference Model.

The main thing is this is a technical extension to a technical extension to
make things work and isn't a real ontological question to my mind.

If we wanted to do the ontological discussions we would have to open up the
modelling box of worms, which is definitely another issue. I, for example,
would like to be able to talk about the timespan of the property of
something being part of something... but that's a broader issue :)

G

On Mon, May 8, 2023 at 5:21 PM Robert Sanderson via Crm-sig <
crm-sig@ics.forth.gr> wrote:

>
> 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 the

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[George Bruseker via Crm-sig]

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 wrote:
> > Dear all,
> >
> > When using the PC classes modelling structure we end up with a class
> > node for a property which we can then modify with things like 'kinds'
> > and 'modes' etc.
> >
> > Since such a statement has meaning and comes from somewhere [e.g.:
> > that someone did something in some capacity (PC14 carried out by ...
> > P02 has range E39 + P14.1 in the role of E55)] one sometimes needs to
> > provenance this statement with an E13 attribute assignment. Ie we want
> > to ground who made this claim.
> >
> > In theory this would be done with E13 pointing to the node in the
> > typical fashion (p141, P140). However, the class
> > PC0_Typed_CRM_Property is not declared as a subtype of E1 CRM Entity
> > in the PC extension file. As a result we cannot do this.
> >
> > https://cidoc-crm.org/rdfs/7.1.1/CIDOC_CRM_v7.1.1_PC.rdfs
> >
> > I would argue PC0_Typed_CRM_Property should be declared a subclass of
> > E1_CRM_Entity.  Then it would be consistent with the rest of the
> > modelling.
> >
> > Opinions?
> >
> > 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

[Crm-sig] Homework for Issue 628: redo learning diagrams

[George Bruseker via Crm-sig]

Dear all,

An open homework relates to updating the diagrams in the Use and Learn
section to accord with CRM 7.1.1.

On the road to that goal, we have had a first pass at re-representing the
extant diagrams in an updated style using draw.io .

You can find the link to this work here:

https://drive.google.com/file/d/1uZAVZ7x42ImKNZt60qZxmQ6nFQhRFkBW/view?usp=share_link

n.b.: to see the diagrams you must click the button 'open with diagrams.net'
then you must accept many terms, then please be aware that there are some
37 tabs full of diagrams, you can browse them at the bottom of the draw.io
interface.

We put forward this draft remake of the existing diagrams to get feedback
from the community on readability / functionality of this new
representation. The content should be the same as it was, if there is a
deviation it is likely by error.

We redid the old diagrams as it seemed like the appropriate first step
before embarking on altering them to reflect the new CIDOC CRM 7.1.1
realities. As we created these diagrams we noted where the diagram would
change in the new version.

The proposal here is to solicit feedback on the representation provided
here and then hopefully to plan the step forward to create the up to date
diagrams based on this discussion.

Best,

George on behalf of Takin.solutions
___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

Re: [Crm-sig] ISSUE Implementing .2 Properties in RDF

[George Bruseker via Crm-sig]

Hi Pavlos,

I definitely agree to keep following the PC modelling pattern at this
moment and your RDF description above looks correct to me.

My point was a theoretic one. The spirit should be to come to a conclusion
on this issue given current premises. My comments for posterity not the
present :) Or perhaps as Gerald implied the .2 as a method could be a
separate issue, while this particular implementation could just go ahead as
is.

Cheers,

George

On Tue, May 2, 2023 at 4:09 PM Pavlos Fafalios 
wrote:

> Dear George,
>
> About the PC constructs and, in general, if this is the best method to
> implement CRM's properties of properties in RDF (considering Francesco's
> email and arguments): I was not involved in the initial discussions, when
> the SIG first introduced the idea of property classes for implementing the
> .1 properties of CRM (I see they were first introduced in Jan 2015 for crm
> version 6.0). My suggestion is to first close issue 588
> <https://cidoc-crm.org/Issue/ID-588-common-policy-method-for-implementing-the-.1-properties-of-base-and-extensions-in-rdf>
>  *(since we have already voted for most of its sub-issues*) and then open
> a new issue for discussing this aspect.
>
> Thoughts?
>
> Best,
> Pavlos
>
>
> On Tue, May 2, 2023 at 3:08 PM George Bruseker 
> wrote:
>
>> Dear both,
>>
>> I am more and more swayed by Francesco's argument that every PC property
>> class hides an actual ontological entity which we are failing to properly
>> model.
>>
>> I think in principle what Pavlos proposes is syntactically correct and
>> insofar as we stay on PC here that is probably the way to go.
>>
>> That said, in this case we are actually building PCs on PCs essentially
>> because we want to avoid saying that there is a state that exists or
>> existed between two things and held for some time. Perhaps in a later
>> version of archaeo if we are able to accept that states do exist we could
>> significantly simplify this model by having real state classes for physical
>> relations etc. This I just forward for thought. The present modelling
>> completely depends on PC properties and there would be no good reason to
>> pause the present development path of CRMArchaeo which is reaching a stable
>> point, by presently changing course. We can maintain the state we presently
>> have.
>>
>> Best,
>>
>> George
>>
>> On Tue, May 2, 2023 at 1:55 PM Pavlos Fafalios via Crm-sig <
>> crm-sig@ics.forth.gr> wrote:
>>
>>> Dear Gerald, all,
>>>
>>> I think we can follow the same reification approach as we do for the .1
>>> properties.
>>> In this case, we just need to provide the property classes of the domain
>>> and range properties of AP13.2, i.e.:
>>> PC_AP13_has_stratigraphic_relation_to
>>> and
>>> PC_AP11_has_physical_relation_to
>>>
>>> Then, here is a (draft) example of RDF triples that make use of these
>>> constructs:
>>>
>>> ***
>>> 
>>>a   .
>>> 
>>>a   .
>>>
>>> 
>>>  .
>>> 
>>>a  ;
>>>  ;
>>>  .
>>>
>>> 
>>>  .
>>> 
>>>a  ;
>>>  ;
>>>  .
>>>
>>> 
>>>   
>>> ***
>>>
>>> But there are also other approaches for implementing this, such as using
>>> named graphs, or the standard RDF reification method (i.e. using
>>> rdf:subject, rdf:object, etc.), or RDF-start (I think).
>>>
>>> Please correct me if I have misunderstood something!
>>>
>>> Best regards,
>>> Pavlos
>>>
>>> On Mon, Apr 24, 2023 at 3:38 PM Hiebel, Gerald via Crm-sig <
>>> crm-sig@ics.forth.gr> wrote:
>>>
>>>> Dear all,
>>>>
>>>> we discussed CRMarchaeo and are going to make a proposel for a new
>>>> version in the next CRM-SIG.
>>>>
>>>>
>>>>
>>>> In the discussion we encountered the issue of not having yet a
>>>> policy/strategy for implementing .2 properties which means properties
>>>> related to properties.
>>>>
>>>> We have one of them in CRMarchaeo:
>>>>
>>>> *AP13.2 justified by (is justification of)*
>>>>
>>>>
>>>>
>>>> Domain:*AP13* has stratigraphic relation to

Re: [Crm-sig] ISSUE Implementing .2 Properties in RDF

[George Bruseker via Crm-sig]

RDF are not part
>> of CIDOC-CRM (especially since they make use of the same namespace).
>>
>> One way is to add a note in the beginning of the file. Another way would
>> be to provide them through a different namespace (not sure if this is a
>> good solution--needs some thinking).
>>
>>
>>
>> This is also a good reason for having them in a different RDF file:  all
>> classes and properties in this file, except the .1 properties, are not part
>> of CIDOC-CRM, while the .1 properties have a 'domain' class that is also
>> not part of CIDOC-CRM.
>>
>>
>>
>> Best,
>>
>> Pavlos
>>
>>
>>
>> On Mon, Sep 12, 2022 at 5:53 PM Mark Fichtner 
>> wrote:
>>
>> Dear all,
>>
>>
>>
>> nice work, thanks! I think for RDF this is a valid representation,
>> although I am not very happy to add properties that are not in the cidoc
>> crm directly and that are not part of the language itself (like in this
>> case crm:P03_reifies). As a user/reader of the rdf it is simply hard to
>> understand what is part of the cidoc crm itself and what comes due to
>> "workarounds". Even in as a new ontology/file/addon it mixes cidoc crm and
>> non-cidoc crm things.
>>
>>
>>
>> Also we have a reification concept (E13 Attribute Assignment), I am not
>> sure if we need even more of these.
>>
>>
>>
>> I'm looking forward to the discussion!
>>
>>
>>
>> Best,
>>
>>
>>
>> Mark Fichtner
>>
>>
>>
>> Germanisches Nationalmuseum
>>
>>
>>
>> Am Mo., 12. Sept. 2022 um 14:22 Uhr schrieb Pavlos Fafalios via Crm-sig <
>> crm-sig@ics.forth.gr>:
>>
>> Dear all,
>>
>>
>>
>> Please find my homework for issue 588
>> <https://cidoc-crm.org/Issue/ID-588-common-policy-method-for-implementing-the-.1-properties-of-base-and-extensions-in-rdf>
>> in the below link (as well as in the issues' folder):
>>
>>
>>
>>
>> https://docs.google.com/document/d/1oQRkmMUgyOeDsn3ZbPuQ__VtbigS9DVsHjmOtvx16uo/edit?usp=sharing
>>
>>
>>
>> Apologies for the delay! Feel free to add your comments or send your
>> feedback!
>>
>>
>> Best regards,
>>
>> Pavlos
>>
>>
>>
>>
>> --
>>
>> Pavlos Fafalios
>>
>> Postdoctoral researcher (Marie Curie IF - Project ReKnow
>> <https://reknow.ics.forth.gr/>)
>> Centre for Cultural Informatics & Information Systems Laboratory
>> Institute of Computer Science - FORTH
>>
>>
>> Visiting Lecturer
>> Department of Management Science & Technology
>> Hellenic Mediterranean University
>>
>>
>> Web: http://users.ics.forth.gr/~fafalios/
>> Email: fafal...@ics.forth.gr
>> Address: N. Plastira 100, Vassilika Vouton, 70013 Heraklion, Greece
>> Tel: +30-2810-391619
>>
>>
>>
>> ___
>> 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
>> <https://reknow.ics.forth.gr/>)
>> Centre for Cultural Informatics & Information Systems Laboratory
>> Institute of Computer Science - FORTH
>>
>>
>> Visiting Lecturer
>> Department of Management Science & Technology
>> Hellenic Mediterranean University
>>
>>
>> Web: http://users.ics.forth.gr/~fafalios/
>> Email: fafal...@ics.forth.gr
>> Address: N. Plastira 100, Vassilika Vouton, 70013 Heraklion, Greece
>> Tel: +30-2810-391619
>>
>>
>>
>>
>>
>>
>> --
>>
>> Pavlos Fafalios
>>
>> Postdoctoral researcher (Marie Curie IF - Project ReKnow
>> <https://reknow.ics.forth.gr/>)
>> Centre for Cultural Informatics & Information Systems Laboratory
>> Institute of Computer Science - FORTH
>>
>>
>> Visiting Lecturer
>> Department of Management Science & Technology
>> Hellenic Mediterranean University
>>
>>
>> Web: http://users.ics.forth.gr/~fafalios/
>> Email: fafal...@ics.forth.gr
>> Address: N. Plastira 100, Vassilika Vouton, 70013 Heraklion, Greece
>> Tel: +30-2810-391619
>>
>>
>> ___
>> Crm-sig mailing list
>> Crm-sig@ics.forth.gr
>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>>
>
>
> --
> Pavlos Fafalios
>
> Postdoctoral researcher
> Centre for Cultural Informatics & Information Systems Laboratory
> Institute of Computer Science - FORTH
>
> Visiting Lecturer
> Department of Management Science & Technology
> Hellenic Mediterranean University
>
> Web: http://users.ics.forth.gr/~fafalios/
> Email: fafal...@ics.forth.gr
> Address: N. Plastira 100, Vassilika Vouton, 70013 Heraklion, Greece
> Tel: +30-2810-391619
>
> ___
> Crm-sig mailing list
> Crm-sig@ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/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] Training Materials Conceptualization, Needs and Resources Discussion

[George Bruseker via Crm-sig]

Dear all,

You will have noticed on the agenda for the upcoming CRM SIG recently sent
by Eleni Tsoulouha that a day has been set aside for a discussion centering
around didactic and training material related to the understanding and use
of CIDOC CRM.

The dedication of a day to this topic was proposed given a number of
factors:

   1. the overall topic relates regardless to several on-going issues that
   are under discussion at the SIG
   2. the on-going ISO acceptance process for CRM base version 7.2x gives
   us a chance to focus on development of material aside from the CRMbase
   specification itself
   3. this year's CIDOC conference and next will have a strong CIDOC CRM
   component and there is a keen interest in training and knowledge of how to
   use the CRM
   4. The material most clearly available to a potential learner / user of
   CRM on the website, requires an update and enrichment with much material
   that has been generated in the meantime (
   https://www.cidoc-crm.org/use_and_learn)

Therefore, it seemed an opportune moment to open up a general discussion as
to the training material for learning and applying CRM (what should this
be, who should it be aimed at, what is its scope, what resources exist
already, what resources would it be good to develop) and then also to dive
into some detail about the potential categories of didactic / training
material and how we can populate them with extant material or plan to
generate new material.

With this in mind, the following draft document was drawn up by myself:

https://docs.google.com/document/d/12tk5Gi6nAAYDQBJmOcVQvBJGaP4LqFSlGkYX_3RfbXE/edit

as a starting point for this discussion. This document is in no way to be
considered complete or final but rather a sketch to prompt a fruitful
discussion.


The proposal for the day is to start with a general discussion of what we
mean by and need for training material, starting from the document above.
This is a draft in order to spur conversation which we would hope to be
wide ranging and open. The first session of the day will open this
discussion and investigate what are the proper categories and terms for the
different elements of CRM learning. SIG members with other  / better /
different ideas are very welcome even to propose a completely different
approach.

The other sessions of the day will pull as general organizing cue from the
proposal above in order to structure more specific conversations about
different topics.

We wanted to send this document out sufficiently in advance so that those
interested in this topic are able to consider it and gather their own ideas
and proposals in turn. Also since there are many topics with different
details to invite those who specifically want to speak on a topic, training
around a particular method or software for example, to be able to propose
this as a component of the conversation.

This will hopefully be the start of an on-going and fruitful effort to
update and enrich the offer of didactic and training materials on the CRM
site with an impact of making it easier and more coherent for potential
users of CRM to appropriate the necessary knowledge to use it to their
particular purposes.

Looking forward to the dialogue.

Sincerely,

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

[Crm-sig] PC0_Typed_CRM_Property in CRMpc

[George Bruseker via Crm-sig]

Dear all,

When using the PC classes modelling structure we end up with a class node
for a property which we can then modify with things like 'kinds' and
'modes' etc.

Since such a statement has meaning and comes from somewhere [e.g.: that
someone did something in some capacity (PC14 carried out by ... P02 has
range E39 + P14.1 in the role of E55)] one sometimes needs to provenance
this statement with an E13 attribute assignment. Ie we want to ground who
made this claim.

In theory this would be done with E13 pointing to the node in the typical
fashion (p141, P140). However, the class PC0_Typed_CRM_Property is not
declared as a subtype of E1 CRM Entity in the PC extension file. As a
result we cannot do this.

https://cidoc-crm.org/rdfs/7.1.1/CIDOC_CRM_v7.1.1_PC.rdfs

I would argue PC0_Typed_CRM_Property should be declared a subclass of
E1_CRM_Entity.  Then it would be consistent with the rest of the modelling.

Opinions?

Best,

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

Re: [Crm-sig] Relation between E28 Conceptual Object and E74 Group

[George Bruseker via Crm-sig]

I'm posting the following response text from Steve because the mailing list
software tosses his messages out:

Just a quick thought.
As you mention a set of individual performances (E7 Activities) you could
say that the individual performances (E7 Activity: performance of Tango on
particular day/time and at a particular place) P9i *forms part of* a master
E7 Activity (All Tango Performances).
E7 Activity (All Tango Performances) P16 *used specific object* E28
Conceptual Object(Intangible Heritage of the Tango).
E7 Activity (All Tango Performances) P14 *carried out by* E39 Actor(Tango
Community)
You could also say:
E28 Conceptual Object(Intangible Heritage of the Tango) P94i *was created
by* E65 Creation P14 *carried out by* E39 Actor(Tango Community)
This would make the community both the creator and performer of the
intangible heritage: which I believe is the current "best practice".
The timespan of the creation is of course open-ended as these are "living"
traditions.
HTH
SdS

On Thu, Mar 9, 2023 at 3:57 PM George Bruseker 
wrote:

> I'd use the term 'forms of life' instead of 'intangible heritage'. Then
> the likely closest CRM concept is E5 Event, at least if you want to be able
> to associate to actors in any direct way.
>
> E5 Event "Tango" p11 had participant E74 Group.
>
> Probably to be more expressive one would need an extension for social life!
>
> On Thu, Mar 9, 2023 at 3:18 PM Christian-Emil Smith Ore via Crm-sig <
> crm-sig@ics.forth.gr> wrote:
>
>> It is a good question. Also note that documentation of intangible
>> cultural heritage is in most cases ttangible. According to UNESCO
>> intangible cultural heritage is defined as
>>
>> Article 2 – Definitions
>> For the purposes of this Convention,
>> 1. The “intangible cultural heritage” means the practices,
>> representations, expressions, knowledge, skills – as well as the
>> instruments, objects, artefacts and cultural spaces associated therewith –
>> that communities, groups and, in some cases, individuals recognize as part
>> of their cultural heritage. This intangible cultural heritage, transmitted
>> from generation to generation, is constantly recreated by communities and
>> groups in response to their environment, their interaction with nature and
>> their history, and provides them with a sense of identity and continuity,
>> thus promoting respect for cultural diversity and human creativity. For the
>> purposes of this Convention, consideration will be given solely to such
>> intangible cultural heritage as is compatible with existing international
>> human rights instruments, as well as with the requirements of mutual
>> respect among communities, groups and individuals, and of sustainable
>> development.
>>
>> 2. The “intangible cultural heritage”, as defined in paragraph 1 above,
>> is manifested inter alia in the following domains:
>> (a) oral traditions and expressions, including language as a vehicle of
>> the intangible cultural heritage;
>> (b) performing arts;
>> (c) social practices, rituals and festive events;
>> (d) knowledge and practices concerning nature and the universe;
>> (e) traditional craftsmanship.
>>
>> Best,
>> Christian-Emil
>>
>>
>>
>> --
>> *From:* Crm-sig  on behalf of Franco
>> Niccolucci via Crm-sig 
>> *Sent:* 09 March 2023 14:54
>> *To:* crm-sig
>> *Subject:* [Crm-sig] Relation between E28 Conceptual Object and E74 Group
>>
>> In the UNESCO List of World Intangible Heritage many items (= E28
>> Conceptual Object) are referred to specific gatherings of people - commonly
>> named “communities” in everyday's language - such as:
>>
>> Tango -> Argentina & Uruguay
>> Rebetiko -> Greece
>> Opera dei pupi (puppet theatre) -> Italy (Sicily)
>>
>> These geographic names in reality mean the people, the inhabitants (maybe
>> not all of them): Argentinians, Uruguayos, Greeks, Sicilians i.e. the
>> social groups who are the custodians/performers of these traditions.
>>
>> So two classes are involved
>> 1) The group (Argentinians, Greeks, etc.) = E39 Actor
>> 2) The conceptual object representing the intangible heritage (Tango,
>> Rebetiko, etc.) = E28 Conceptual Object
>>
>> Note that intangibile heritage is NOT an activity, it is the abstraction
>> of a set of activities and the way in which they are traditionally
>> performed, which manifests through events/activities i.e. individual
>> performances.
>>
>> Which property - if any - can be used to relate such E39 Actors to the
>> corresponding E28?
>>
>

Re: [Crm-sig] Relation between E28 Conceptual Object and E74 Group

[George Bruseker via Crm-sig]

I'd use the term 'forms of life' instead of 'intangible heritage'. Then the
likely closest CRM concept is E5 Event, at least if you want to be able to
associate to actors in any direct way.

E5 Event "Tango" p11 had participant E74 Group.

Probably to be more expressive one would need an extension for social life!

On Thu, Mar 9, 2023 at 3:18 PM Christian-Emil Smith Ore via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> It is a good question. Also note that documentation of intangible
> cultural heritage is in most cases ttangible. According to UNESCO
> intangible cultural heritage is defined as
>
> Article 2 – Definitions
> For the purposes of this Convention,
> 1. The “intangible cultural heritage” means the practices,
> representations, expressions, knowledge, skills – as well as the
> instruments, objects, artefacts and cultural spaces associated therewith –
> that communities, groups and, in some cases, individuals recognize as part
> of their cultural heritage. This intangible cultural heritage, transmitted
> from generation to generation, is constantly recreated by communities and
> groups in response to their environment, their interaction with nature and
> their history, and provides them with a sense of identity and continuity,
> thus promoting respect for cultural diversity and human creativity. For the
> purposes of this Convention, consideration will be given solely to such
> intangible cultural heritage as is compatible with existing international
> human rights instruments, as well as with the requirements of mutual
> respect among communities, groups and individuals, and of sustainable
> development.
>
> 2. The “intangible cultural heritage”, as defined in paragraph 1 above, is
> manifested inter alia in the following domains:
> (a) oral traditions and expressions, including language as a vehicle of
> the intangible cultural heritage;
> (b) performing arts;
> (c) social practices, rituals and festive events;
> (d) knowledge and practices concerning nature and the universe;
> (e) traditional craftsmanship.
>
> Best,
> Christian-Emil
>
>
>
> --
> *From:* Crm-sig  on behalf of Franco
> Niccolucci via Crm-sig 
> *Sent:* 09 March 2023 14:54
> *To:* crm-sig
> *Subject:* [Crm-sig] Relation between E28 Conceptual Object and E74 Group
>
> In the UNESCO List of World Intangible Heritage many items (= E28
> Conceptual Object) are referred to specific gatherings of people - commonly
> named “communities” in everyday's language - such as:
>
> Tango -> Argentina & Uruguay
> Rebetiko -> Greece
> Opera dei pupi (puppet theatre) -> Italy (Sicily)
>
> These geographic names in reality mean the people, the inhabitants (maybe
> not all of them): Argentinians, Uruguayos, Greeks, Sicilians i.e. the
> social groups who are the custodians/performers of these traditions.
>
> So two classes are involved
> 1) The group (Argentinians, Greeks, etc.) = E39 Actor
> 2) The conceptual object representing the intangible heritage (Tango,
> Rebetiko, etc.) = E28 Conceptual Object
>
> Note that intangibile heritage is NOT an activity, it is the abstraction
> of a set of activities and the way in which they are traditionally
> performed, which manifests through events/activities i.e. individual
> performances.
>
> Which property - if any - can be used to relate such E39 Actors to the
> corresponding E28?
>
> Thank you for any help on the above.
>
> Franco
>
> Prof. Franco Niccolucci
> Director, VAST-LAB
> PIN - U. of Florence
> President, ARIADNE Research Infrastructure AISBL
> Chief Technology Officer 4CH
>
> Editor-in-Chief
> ACM Journal of Computing and Cultural Heritage (JOCCH)
>
> Piazza Ciardi 25
> 59100 Prato, Italy
>
>
>
>
>
> ___
> Crm-sig mailing list
> Crm-sig@ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
> ___
> Crm-sig mailing list
> Crm-sig@ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>
___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

[Crm-sig] Typo in Archaeo RDFS?

[George Bruseker via Crm-sig]

Dear all,

Whilst doing some Archaeo implementation in Arches, Takin.solutions noticed
a typo in the latest stable RDF for archaeo. 1.4.1

https://cidoc-crm.org/crmarchaeo/ModelVersion/version-1.4.1

The RDF reads:


Stratigraphic Unit
This class comprises S20 Physical Features that are either A2
Stratigraphic Volume Units or A3 Stratigraphic Interfaces
http://www.cidoc-crm.org/cidoc-crm/CRMsci/S20_Physical_Feature"/>


The reference to S20 is Physical Feature but should be Rigid Physical
Feature.

I think S20 was always called "Rigid Physical Feature". If so this seems to
be a typo and should perhaps be corrected?

Cheers,

George

-- 
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

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

[George Bruseker via Crm-sig]

Dear both,

I'm too covidy still to follow this in detail but I think the issue was
left, for the notes to show, for Martin to provide an example to show the
problem he sees that we cannot see.

Cheers,

George

On Thu, Dec 15, 2022 at 9:47 PM Martin Doerr via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear Robert,
>
> On 12/15/2022 4:57 PM, Robert Sanderson wrote:
>
>
> This doesn't meet the requirements, unfortunately.
>
> To my best understanding, and of others on this list, it has not made
> sufficiently clear so far by you which semantics the linguistic Appellation
> should comprise.  Following our methodology, requirements must be backed up
> by representative examples that allow for narrowing down the senses to be
> comprised. The do not come from authority.
>
> Most examples provided so far did not demonstrate the independence of the
> language specificity of the Appellation from the individual identified by
> it, but exactly the opposite. The difference is a matter of fundamental
> logic of semantic networks, and cannot be ignored.
>
> Examples must be sufficiently representative for a large set of data. TGN,
> for instance, is huge, and domainßinstance specific. VIAF refers to
> national libraries, not to languages. "The Big Apple" is a rather rare case
> of a complete English noun phrase used as a place name, which exactly fits
> the scope note of E41. It could be documented as Title. Transliteration,
> you mentioned, does not create a language specificity, but a script
> specificity.
>
> Please respect that it belongs to our method to discuss, if the sense of
> an original submission actually represents the best semantics fit for
> purpose, and to modify it if needed. I simply act here, as any CRM-SIG
> member should, as a knowledge engineer based on the examples you and others
> provided and try to propose the most adequate solution, and not to defend
> any position. I do not have any other project of my own. Please stay in
> your answers on the level of arguments based on representative examples and
> their interpretation.
>
>
> 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.
>
> Indeed I may not describe C11 as a State in the sense we discussed it. It
> is as timeless as all our properties of persistent items. States are better
> avoided if temporal inner bounds are to be given, because they require
> complete observation, a sort of Closed World. This is not the case here.
> But this distracts from the question to what the language here pertains.
>
> To repeat, if E33_41 is to enter unmodified CRMbase as you propose, it
> needs a scope note and examples that disambiguate scope and senses.  Then, *it
> must* be differentiated from domain-instance specific use, and the
> relevance
> of the remaining scope must be argued. All examples must be discussed and
> voted for.
>
> Rather than an anonymous "requirement set forth", I definitely would like
> to see your examples of use of E33_41 in your applications. Is that
> possible? Are you sure they fit the independence from the domain instance?
> Are you sure there will be no abuse in the sense I, Francesco and LRM
> propose?
>
> Best,
>
> Martin
>
>
> 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 

[Crm-sig] COVID case

[George Bruseker via Crm-sig]

Hi,

On return to Athens yesterday Dec 12 I tested positive for COVID. I did not
feel symptoms during Luxembourg meet  but I thought it wise to share this
with those who were in person. I do feel symptoms now. O13 triggered!

All the best

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

[Crm-sig] HW for Issue 488

[George Bruseker via Crm-sig]

Dear all,

Please find my HW for Issue 488

https://docs.google.com/presentation/d/1FrHiJj_4jR46ZeBjhsFblXQej2gwaZwCq3l-YU8--18/edit?usp=sharing

The issue is around for a while and is about documenting roles and
representation in activities. I present a potential solution based on
evidence from projects.

You can see the history of the discussion here:

https://cidoc-crm.org/Issue/ID-488-modelling-an-actor-carrying-out-an-action-at-the-behest-of-another

Best,

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

[Crm-sig] Homework for Issue 624

[George Bruseker via Crm-sig]

Dear all,

Issue 624 can be found here:
https://cidoc-crm.org/Issue/ID-624-add-e33e41linguisticappellation-to-the-official-specification

The discussion revolves around adding a class to the specification and not
just the rdfs which represents the phenomenon of names being in languages.

The homework for the issue can be found in this google doc:

https://docs.google.com/document/d/1-l6OrEy8I3doP5cCm5dTzLav6SwE2prxBtpPxpqBhaA/edit?usp=sharing

Best,

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

[Crm-sig] HW for Issue 547 CRMdig Update

[George Bruseker via Crm-sig]

Dear all,

Please find in the following links some additional homework for the ongoing
CRMdig update.

Discussion Doc

https://docs.google.com/document/d/1mjPo_UVJ7MlHzQuhEU8TCd4GnwbgOkR308oMPRxKzKY/edit?usp=sharing

Supporting Diagrams

https://drive.google.com/file/d/10i763cRrosrzcJjmtMG48abI-fj1c4zR/view?usp=sharing

What you will find in the links is a list of proposals to modify, move or
delete existing classes and properties in order to make CRMdig compatible
with CRMbase 7.1.1 and current best modelling practice.

There are three proposals contained in the homework pertaining to

D13 Digital Information Carrier

D9 Data Object

Annotation Classes [D29 Annotation Object, D30 Annotation Event, D35 Area]

The present state of the classes and properties, the reason they should be
modified/moved/deleted given and a proposal for how to do that is put
forward.

The work is an outcome of conversations with Rob Sanderson, Nicola Carboni
(some time ago) and Martin Doerr. The final proposal can be pinned on me,
however.

These are prepared for discussion at the upcoming SIG. If for whatever
reason you are not able to participate in person or online in this SIG but
are interested in the above matters, please do add your comments pro, con,
querying here for them to be considered during the meeting and potential
voting.

Best,

George
___
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

[George Bruseker via Crm-sig]

Dear all,

The deadline for voting on this issue has passed. There were 5 votes in
total. 5 votes were to approve the change. 0 votes were against. Therefore,
it would appear the change passes.

This will be reported to the CRM SIG in the session on the CRMdig which
will be held next week in Luxembourg.

Sincerely,

George

On Sun, Nov 6, 2022 at 4:53 PM Martin Doerr via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> YES
>
> On Tue, Nov 1, 2022, 10:56 George Bruseker via Crm-sig <
> crm-sig@ics.forth.gr> 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
>>
>
> __

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

[George Bruseker via Crm-sig]

Dear all,

The deadline for voting on this issue has passed. There were 7 votes in
total. 7 votes were to approve the change. 0 votes were against. Therefore,
it would appear the change passes.

This will be reported to the CRM SIG in the session on the CRMdig which
will be held next week in Luxembourg.

Sincerely,

George

On Mon, Nov 7, 2022 at 9:38 AM Weiss Christian SNM 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
> > <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/ <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
>
> ___
> Crm-sig mailing list
> Crm-sig@ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/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] NEW ISSUE: Add E33_E41_Linguistic_Appellation to the Official Specification

[George Bruseker via Crm-sig]

Dear all,

Given the opened discussion of the utility and need for this class and the
discussion which illustrates a clear precedent and use for this class, as
well as the need for the top principle for the need to clearly document
elements of the standard, I propose for the class to be added not just in
the RDFS (where it is already official) but to be given a scope note and
added to the basic documentation in order to support inter-dataset
communication with clarity and consistency.

Best,

George



-- 
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

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

[George Bruseker via Crm-sig]

Here is fun example of linguistic object which I guess challenges p72 but
is still actually diaskedastic and perithoric to our enterprise, brought to
you by the great zolotas

https://youtu.be/2XAcuxFqk9k

In what language is it? In what language is this email?

And is it in our capacity as ontologists that we would decide?





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
>
>
>
>
>
>
>
>
> Le 09.11.22 à 20:13, Martin Doerr via Crm-sig a écrit :
>
> Dear both,
>
> The question was not if names can belong to language, or if langauges
> create names. It was how this is unambiguously defined.
>
>
> 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.
>
> Why is Douglas Adams not "German"? I would use it in German exactly in
> this form.
>
> 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? Martino in Italian, Rumanian?
>
> From Wikipedia: "Joshua".
>
> *Josua* or *Jozua* is a male given name and a variation of the Hebrew
> name Yeshua .[1]
> [2]
>  Notable people with
> this name include:
>
>- Josua Bühler 
>(1895–1983), Swiss philatelist
>- Josua de Grave 
>(1643–1712), Dutch draughtsman and painter
>- Josua Harrsch 
>(1669–1719), German missionary
>- Josua 

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

[George Bruseker via Crm-sig]

I agree. This is p72:

This property associates an instance(s) of E33 Linguistic Object with an
instance of E56 Language in which it is, at least partially, expressed.

A mountain is surely made of a molehill here.

Can a name be expressed in a language? Yes. Can someone and recognize this
and document it? Yes. Does this happen all the time? Yes. Should the
standard express it yes. We already agreed this. That  is why it is in the
rdfs. But in practice this makes it hard for people to apply it. So the
proposa to please make it part of the standard so people can exchange
information.


On Thu, 10 Nov 2022, 8:45 pm Robert Sanderson,  wrote:

>
> 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 <https://en.wikipedia.org/wiki/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 

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

[George Bruseker via Crm-sig]

Dear Martin,

I don't see an ontological problem here. One name can be used by / in many
languages. If it is, that can be documented.


> The question was not if names can belong to language, or if langauges
> create names. It was how this is unambiguously defined.
>

It isn't our job as ontologists to unambiguously define the instances of
things in the world. This is for the domain specialists.


>
>
> The example below is what I feared. The fact that the arabic script is
> mainly used for Arabic, does itr make a *transcript *of an English name
> "Arabic?" why not Farsi?  I ask here for the Librarians to express their
> opinion.
>

Who documents the object, documents their knowledge and, hopefully,
thereby, the state of affairs in the world.

I don't understand the Farsi aspect of the above question. Why
would transliterating a name into English from Arabic make it Farsi?
Librarians?

Here's a person with a name: https://en.wikipedia.org/wiki/Averroes

His name is ابن رشد in Arabic and also أبو الوليد محمد ابن احمد ابن رشد.

With E33_E41 we can say that. Without it, we can't.

His name in English is usually Averroes and also he is known as Ibn Rushd.

With E33_E41 we can say that. Without it, we cant.

He has a transliterated name: Abū l-Walīd Muḥammad Ibn ʾAḥmad Ibn Rušd . Is
that his name in Arabic or English or no language? I don't know. Both?
Maybe. I'm not a scholar of philosopher's names and it's not my province to
judge. This is not the domain of the ontologist but the specialist in
onomastics or the appropriate discipline.



>
> Why is Douglas Adams not "German"? I would use it in German exactly in
> this form.
>

Then put in the KB for this name 'has language English' and 'has language
German' and the problem is solved.


>
>
> But "Adams" I  think is a last name exclusive to English, as Dörr to
> German.
>
> What is the language of "Martin", "Martino",  of
>
> Martin: Identical in English, Spanish, French, Dutch, German, Norwegian,
> Danish, Swedish?
>

If that is what the expert in onomastics thinks, yes. Not an ontological
issue. We provide the semantic framework, they do the researching.


> Martino in Italian, Rumanian?
>
> From Wikipedia: "Joshua".
>
> *Josua* or *Jozua* is a male given name and a variation of the Hebrew
> name Yeshua .[1]
> [2]
>  Notable people with
> this name include:
>
>- Josua Bühler 
>(1895–1983), Swiss philatelist
>- Josua de Grave 
>(1643–1712), Dutch draughtsman and painter
>- Josua Harrsch 
>(1669–1719), German missionary
>- Josua Hoffalt  (born
>1984), French ballet dancer
>- Josua Järvinen 
>(1871–1948), Finnish politician
>- Josua Koroibulu 
>(born 1982), Fijian rugby league footballer
>- Josua Heschel Kuttner
> (c. 1803–1878),
>Jewish Orthodox scholar and rabbi
>- Josua Lindahl 
>(1844–1912), Swedish-American geologist and paleontologist
>- Josua Maaler 
>(1529–1599), Swiss pastor and lexicographer
>- Josua Mateinaniu  (
>fl. 1835), Fijian missionary
>- Josua Mejías  (born
>1997), Venezuelan footballer
>- Johann Josua Mosengel
> (1663–1731),
>German pipe organ builder
>- Jozua Naudé (disambiguation)
>,
>several people
>- Josua Swanepoel 
>(born 1983), South African cricketer
>- Josua Tuisova  (born
>1994), Fijian rugby union player
>- Josua Vakurunabili 
>(born 1992), Fijian rugby union player
>- Josua Vici  (born 1994),
>Fijian rugby union player
>
> Following scripts, only  *יְהוֹשֻׁעַ
> *
> would be Hebrew, but Yeshua 
> English?
>

This is a question for the knowledge base. The English speaker writing this
article thinks that "Josua" applies to these people. It is up to them to
instantiate an instance of the class, call it Hebrew and then assign it as
a name of those individuals. If someone wants to dispute this, they can use
negative properties. I 

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

[George Bruseker via Crm-sig]

or to put it another way, if one only lived in a world of CRMese and knew
nothing else about the world in itself, understanding what E33_E41 is is
just a question of understanding what E35_Title is and then taking the
conceptual leap that it can be applied to E1. That's it! Names, in a
language, can be applied to anything, in human societies. And they often
are, and in documentation, and so the standard should represent it and
perspicuously document that representation.  Not everything is totally
inscrutable.

On Wed, Nov 9, 2022 at 5:13 PM George Bruseker 
wrote:

> Dear both,
>
> I have to agree with Robert, I basically can't even conceive how this is
> an argument. Obviously names come in languages MOST of the time. This is a
> basic feature of living in a human society, is it not? Is this not a base
> experience of being embodied as a human being that we all commonly have
> access to and is an undeniable reality? We live in language. We name things
> in language.
>
> But if we need to show that it was documented in a database, here are some:
>
> Getty AAT wrenches
>
> https://www.getty.edu/vow/AATFullDisplay?find=spanner=AND==N_page=1=300024714
>
> Wrench has a name in many languages.
>
> Here is geonames:
>
> https://www.geonames.org/6094817/ottawa.html
>
> Ottawa, has many names in different languages.
>
> Here is VIAF
>
> https://viaf.org/viaf/15873/#Picasso,_Pablo,_1881-1973
>
> Picasso has names in different languages.
>
> This could be done ad infinitum. How many databases should be listed
> before this is accepted as an empirical part of reality documented in CH
> and needing a class?
>
> Cheers,
>
> George
>
>
>
>
>
> On Wed, Nov 9, 2022 at 4:49 PM Robert Sanderson via Crm-sig <
> crm-sig@ics.forth.gr> wrote:
>
>>
>> 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 c

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

[George Bruseker via Crm-sig]

onize 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? At least I might have my long loved E84
>> >> Information Carrier back there... :D
>> >>
>> >> No offense intended - just my two cents and the perspective of the GNM
>> >> Nürnberg on the current CRM development...
>> >>
>> >> Best,
>> >>
>> >> Mark
>> >>
>>
>> --
>> 
>>   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
>


-- 
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

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

[George Bruseker via Crm-sig]

mage 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

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

[George Bruseker via Crm-sig]

 Mark
>
>
>
> Am Di., 8. Nov. 2022 um 21:51 Uhr schrieb Robert Sanderson via Crm-sig <
> crm-sig@ics.forth.gr>:
>
>>
>> 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),
>>>>

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

[George Bruseker via Crm-sig]

Hi Pavlos,

I understand that principle, I am contesting it. There is another principle
which is handle obvious cases in the domain. I hold that that principle has
greater importance here.

Cheers
G

On Tue, Nov 8, 2022 at 3:59 PM Pavlos Fafalios 
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 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 XML comments of the
>>> rdfs file.
>>>
>>>
>>>
>>> There has been a discussion and decision about the correct order.
>>>
>>> Please see issue
>>> https://cidoc-crm.org/Issue/ID-555-rdfs-implementation-and-related-issues
>>> and search for post starting with In the 51st CIDOC CRM & 44th FRBRoo SIG
>>> m

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

[George Bruseker via Crm-sig]

It's like we inverse the 80 / 20 principle and we choose to solve only 20%
of the problem and let the other 80% be a workaround. But the 80% is where
the actual information / people are at.

On Tue, Nov 8, 2022 at 4:56 PM George Bruseker 
wrote:

> Hi Pavlos,
>
> I understand that principle, I am contesting it. There is another
> principle which is handle obvious cases in the domain. I hold that that
> principle has greater importance here.
>
> Cheers
> G
>
> On Tue, Nov 8, 2022 at 3:59 PM Pavlos Fafalios 
> 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 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 <
>>>> tzort...@ics.forth.gr> wrote:
>>>>
>>>> D

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

[George Bruseker via Crm-sig]

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 
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 XML comments of the
> rdfs file.
>
>
>
> There has been a discussion and decision about the correct order.
>
> Please see issue
> https://cidoc-crm.org/Issue/ID-555-rdfs-implementation-and-related-issues
> and search for post starting with In the 51st CIDOC CRM & 44th FRBRoo SIG
> meeting
>
> *Decision*: keeping numbers of the numeric identifier in order.
>
>
>
> Thus the rdfs is valid and consistent but the comment lines should also
> definitely be adapted to this decision.
>
> Thanks for spotting,
>
>
>
> I will correct this ASAP,
>
>
>
> Kind regards,
>
> Elias Tzortzakakis
>
>
>
>
>
> *From:* Crm-sig  *On Behalf Of *George
> Bruseker via Crm-sig
> *Sent:* Monday, November 7, 2022 5:02 PM
> *To:* crm-sig 
> *Subject:* [Crm-sig] error in RDFS for 7.1.1 for the class that is a
> subclass of E41 and E33
>
>
>
> Dear all,
>
>
>
> There are two references to the class that is a subclass of E41 and E33
> that allows you to talk about the language of a name (which is a super
> common requirement... actually almost always necessary). I can't give you
> it's official name because I dont know because it isn't in the spec doc and
> it doesn't have ONE name in the RDFS.
>
>
>
> In one reference it is called: E41_E33_Linguistic_Appellation and then
> later it is called E33_E41_Linguistic_Appellation. Try find f in the rdfs
> doc and you will what I mean.
>
>
>
> https://cidoc-crm.org/rdfs/7.1.1/CIDOC_CRM_v7.1.1.rdfs
>
>
>
>
>
> Actually I don't care what it is called, but it would be nice if it was
> really, really clear.
>
>
>
> I think this speaks against the practice of hiding classes we don't like
> and call implementation classes in the RDFS and should make them 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.
>
>
>
> And definitely it should not have two different name in the RDFS. Can we
> confirm that it is supposed to be E33_E41 and not E41_E33?
>
>
>
> Cheers,
>
>
>
> George
>
>
>
> --
>
> George Bruseker, PhD
>
> Chief Executive Officer
>
> Takin.solutions Ltd.
>
> https://www.takin.solutions/
>
>
>
>
> --
>
> George Bruseker, PhD
>
> Chief Executive Officer
>
> Takin.solutions Ltd.
>
> https://www.takin.solutions/
>


-- 
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

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

[George Bruseker via Crm-sig]

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 XML comments of the
> rdfs file.
>
>
>
> There has been a discussion and decision about the correct order.
>
> Please see issue
> https://cidoc-crm.org/Issue/ID-555-rdfs-implementation-and-related-issues
> and search for post starting with In the 51st CIDOC CRM & 44th FRBRoo SIG
> meeting
>
> *Decision*: keeping numbers of the numeric identifier in order.
>
>
>
> Thus the rdfs is valid and consistent but the comment lines should also
> definitely be adapted to this decision.
>
> Thanks for spotting,
>
>
>
> I will correct this ASAP,
>
>
>
> Kind regards,
>
> Elias Tzortzakakis
>
>
>
>
>
> *From:* Crm-sig  *On Behalf Of *George
> Bruseker via Crm-sig
> *Sent:* Monday, November 7, 2022 5:02 PM
> *To:* crm-sig 
> *Subject:* [Crm-sig] error in RDFS for 7.1.1 for the class that is a
> subclass of E41 and E33
>
>
>
> Dear all,
>
>
>
> There are two references to the class that is a subclass of E41 and E33
> that allows you to talk about the language of a name (which is a super
> common requirement... actually almost always necessary). I can't give you
> it's official name because I dont know because it isn't in the spec doc and
> it doesn't have ONE name in the RDFS.
>
>
>
> In one reference it is called: E41_E33_Linguistic_Appellation and then
> later it is called E33_E41_Linguistic_Appellation. Try find f in the rdfs
> doc and you will what I mean.
>
>
>
> https://cidoc-crm.org/rdfs/7.1.1/CIDOC_CRM_v7.1.1.rdfs
>
>
>
>
>
> Actually I don't care what it is called, but it would be nice if it was
> really, really clear.
>
>
>
> I think this speaks against the practice of hiding classes we don't like
> and call implementation classes in the RDFS and should make them 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.
>
>
>
> And definitely it should not have two different name in the RDFS. Can we
> confirm that it is supposed to be E33_E41 and not E41_E33?
>
>
>
> Cheers,
>
>
>
> George
>
>
>
> --
>
> George Bruseker, PhD
>
> Chief Executive Officer
>
> Takin.solutions Ltd.
>
> https://www.takin.solutions/
>


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

[George Bruseker via Crm-sig]

Dear all,

There are two references to the class that is a subclass of E41 and E33
that allows you to talk about the language of a name (which is a super
common requirement... actually almost always necessary). I can't give you
it's official name because I dont know because it isn't in the spec doc and
it doesn't have ONE name in the RDFS.

In one reference it is called: E41_E33_Linguistic_Appellation and then
later it is called E33_E41_Linguistic_Appellation. Try find f in the rdfs
doc and you will what I mean.

https://cidoc-crm.org/rdfs/7.1.1/CIDOC_CRM_v7.1.1.rdfs


Actually I don't care what it is called, but it would be nice if it was
really, really clear.

I think this speaks against the practice of hiding classes we don't like
and call implementation classes in the RDFS and should make them 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.

And definitely it should not have two different name in the RDFS. Can we
confirm that it is supposed to be E33_E41 and not E41_E33?

Cheers,

George

-- 
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] URIs of Classes that change Label (and how to relate them)

[George Bruseker via Crm-sig]

Dear all,

It is the CRM SIG's practice to encode the English label of a class into
the URI of the class itself. We thus find the official URIs of CRM encoded
in each official version of CRMbase on the official website:
https://cidoc-crm.org/versions-of-the-cidoc-crm

e.g.:

http://www.cidoc-crm.org/cidoc-crm/E1_CRM_Entity

And this is fine. But once in a while, as we evolve the standard, we change
the label of the class. This means we change the URI of the class as well.

A classic example:

In CRM 6.2.1

http://www.cidoc-crm.org/cidoc-crm/E78_Collection

In CRM 7.1.1

http://www.cidoc-crm.org/cidoc-crm/E78_Curated_Holding

Obviously, this is something we try not to do very often because it creates
a great many implementation headaches. But it occurs and that is okay.

When we make such changes, we imply that the name we use to identify the
class has changed but not its substance. The intension as defined by the
scope remains the same. All previous instances of this class remain
instances of this class. For some reason, we want to call it something
else.

As far as a semantic network is concerned though the new and the old class
are two different things, not one.

http://www.cidoc-crm.org/cidoc-crm/E78_Collection !=
http://www.cidoc-crm.org/cidoc-crm/E78_Curated_Holding

My question is, should we include something in the RDFS definition that
indicates the relation between the old URI and the new URI? To state an
equivalency? This way in a semantic network, they could be treated with the
same meaning?

Apologies if we have discussed this before and decided no, or that it can't
be done or shouldn't be done. I don't recall.

Best,

George

-- 
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] ISSUE: Delete Unnecessary / Incorrect Classes of CRMdig

[George Bruseker via Crm-sig]

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

[George Bruseker via Crm-sig]

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] CRMdig Issues Backgrounder

[George Bruseker via Crm-sig]

Dear all,

I am writing this as a preface to a number of emails that I hope I will be
sending through to the list over the next while regarding CRMdig. Following
the last SIG meeting in Rome, a decision was made to try to move forward
with doing a general review of CRMdig both to check its general consistency
with itself and the world and also to bring it into line with CRMbase 7.1.1.

https://cidoc-crm.org/Issue/ID-547-crmdig-update

In that regard, we will be first trying to give it a good trimming taking
into account the modelling principles that have been consolidated over the
last years and the best practices we have established. This will involve
the proposal of deletion of unnecessary classes and properties relative to
a domain ontology.

Thereafter for classes and properties that have been identified as
problematic but useful/functional, we will create separate issues for each
that at the very least identifies THAT they are problematic and hopefully
also proposes a useful way to fix them.

We will of course bear in mind the need to make the extension consistent
with CRMbase 7.1.1.

At first, the idea would be to bring CRMdig to a stable and consistent
state and then to systematically and based on input and feedback from the
community, add to its functionality modelling ground up from real world
cases / needs.

It is a very handy and necessary extension given the strong emphasis on
digital programmes in the CH community so it will be a real contribution we
can make to consolidate this work and bring it up to date. As usual for
those who are interested and have experience with implementing CRMdig or
other standards which they think it should be able to interact with / be
consistent with etc. please be in touch.

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

Re: [Crm-sig] E9 Move and its relationship with the origin/destination

[George Bruseker via Crm-sig]

Dear Martin and Wolfgang,

>
> >> Therefore, the described destination is an instance of E53 Place which
> P89 falls within (contains) the instance of E53 Place the move P7 took
> place at.
> > P26(x,y) ⇒ (∃z) [E53(z) ∧ P7(x,z) ∧ P89(y,z)]
> >
> > I assume that P26 behaves in the same way as P7, ie. there are some
> attestations and one can infer the best approximation.
>


> Why do you assume that?
>

I assume he assumes consistency in our reasoning and this is a predicate
that indicates where something is at a moment, like P7! So it seems like a
legit assumption.

Do I get your gist Wolfgang?

Cheers,

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

[Crm-sig] CRMdig Refocus HW

[George Bruseker via Crm-sig]

Dear all,

Given that CRMbase 7.1.1 is now a static entity and needs to be so for the
purposes of shepherding it through the ISO process (shout out to Philippe
and Erin!), now seems a good time to be doing some consolidation on the
many extensions and trying to tighten up official versions of these.

I have taken up the mission of consolidating notes and thoughts from the
past few years regarding CRMdig and how to bring it into line with the best
practices we have evolved at the CRM SIG.

I have, as a result, formulated the following three powerpoints / proposals:

CRMdig Cleanup:
https://docs.google.com/presentation/d/1xg9PvWh3BPmP_mcnEK5HmbPlj4NvH_MB_Z_7VT7J0uc/edit?usp=sharing

In which I propose a number of deletions and general consolidations to make
the extension accord with 7.1.1 and its practices. Here I should
acknowledge Rob Sanderson and Nicola Carboni for work which we did on this
a number of years ago which I have borrowed from (hold them not responsible
for any apostasies!).

CRMdig and CRMpe (Parthenos Entities)

https://docs.google.com/presentation/d/1yqqnfEtoM2TJYvliwSVgbYmJoDBXbzh8KUHL7Saa-0M/edit#slide=id.p

Some time ago (it was in Paris in 2018 I think) we agreed to look into how
to integrate the work of the Parthenos Project that was relevant to CRMdig
into a common framework. In this powerpoint, I illustrate the basic
proposals of CRMpe and make some proposals as to what elements might become
parts of CRMdig (and other models).

CRMdig and CRMsoc

https://docs.google.com/presentation/d/1Wh3Vb9LInY7w_zx33ixwBvPboI7IxrKPyP5VOyMabik/edit?usp=sharing

In looking over CRMdig, the annotation modelling particular stood out as an
outlier and not properly a question of digital workflow. I've done
extensive work on how to cover this using the structures of CRMsoc, so here
I put in an illustration of how that could be coherently harmonized.

The key point of this exercise, to my opinion, should be to focus on a
cleanup of CRMdig that brings it into coherence with our present practice
at CRM SIG but also takes into account the knowledge and experience of
people who have used it and who have knowledge of other standards and well
known practices in the community that should be taken into account.

Therefore, I present the above as a working framework for a discussion and
to announce that we will start to have the discussion of improving CRMdig.

For those of you who are interested in the topic and have opinions on what
is done right or wrong there, it would be great to hear your input, nothing
suggested above is set in stone, but is meant to start the conversation.

To that end, if people want to make structured remarks regarding the
proposals before the meeting, you can of course always use the emailing
back and forth feature of the list OR you could make your remarks in this
handy google doc I have constructed for that purpose:

https://docs.google.com/document/d/1Qn9I3wsZYJIJ0NoHkzyolCLPX1YvdHv8-48TtiOkk8o/edit?usp=sharing

This review is well overdue and is a nice, concentrated piece of action
which we could take up to facilitate the CRM community's modelling work, so
I do look forward to constructive and pragmatic discussions!

Best,

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

[Crm-sig] .1 properties on sub properties of properties with .1

[George Bruseker via Crm-sig]

Hi all,

This is for the .1 fans out there. I think it's an old discussion, but one
perhaps not unworth repeating. There are places where .1 is introduced like
'P14 carried out by' which allow you to qualify the relation's mode or
aspect. Participated as lawyer, as doctor etc.

Now P14 has subproperties. These specialize the top level property. So we
have a property like:

https://cidoc-crm.org/Property/P23-transferred-title-from/version-7.1.1

However, P23 doesn't have .1. And yet, people record information that
modifies such properties in precisely the same way as above.

So right now we can say:

E.g.:
Gifting of Statue of Liberty (E8) P23 transferred title from French State
(E74)
Gifting of Statue of Liberty (E8) P22 transferred title to American State
(E74)
Gifting of Statue of Liberty (E8) P24 transffered title of Statue of
Liberty (E22)

But people also record:

Gifting of Statue of Liberty (E8) P23 transferred title from French State
(E74) [Gifter]
Gifting of Statue of Liberty (E8) P22 transferred title to American State
(E74) [Giftee]
Gifting of Statue of Liberty (E8) P24 transferred title of Statue of
Liberty (E22)

This is not inconsequential information but rather important as you might
document different ways in which people interact in the exchange of
ownership of things.

This forces one to retreat to P14 but then one isn't using the standard
property for transfer of ownership etc.

Therefore, I propose that it be discussed that such properties receive the
downsteam .1 from their superproperties for logical consistency and for
accurate repesentation.

Thoughts?

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

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

[George Bruseker via Crm-sig]

Dear all,

My two cents.

I like the proposal regarding sustainability and its recognition
particularly of the financial realities and the potentials of technologies
/ new methodologies and how they relate to our working practice. (Not to
mention ecological questions)

Setting a standard number of meetings a year sounds good and three sounds
like an adequate number to me. I also think mixing hybrid and in person
makes sense with having one in person being realistic.

Regarding the colocation, I think I agree with Pat that it probably won't
work, especially if this is the only in person SIG meeting that will
happen. In that scenario, the SIG will take up its full number of days and
will necessitate being run very efficiently to keep it up to date. So I
would think the one in person meeting would remain a meeting to be held in
its own right. I think shortening the one in person meeting down to one day
is likely not realistic.

Obviously the above would be a significant update to the SIG's working
practice and so is definitely something that I think we should hear from
everyone about and fully understand the pros and cons of before making such
a significant structural change.

Sincerely,

George

On Tue, Jul 12, 2022 at 7:07 AM Pat Riva via Crm-sig 
wrote:

> I think the tension between in-person and online meetings will remain for
> some time. That does argue for an annual schedule that has some of each.
>
> I think we have found that there are kinds of issues/business that runs
> well in the Zoom format. I think of specific issues that don't require much
> explanation, editorial correction of scope notes, examples. Giving
> presentations and reports works too.
> But there are logistical drawbacks in addition to the timezones. Because
> of the timezones, we actually have fewer meeting hours over a 4-day online
> meeting than an in-person meeting. And it is much harder to stay available
> for all the sessions when one is at one's normal office. Plus distraction
> with other things the rest of the day. Speaking for my experience, of
> course.
>
> I do not find we have MORE people in attendance online at any one time
> than we had at in-person meetings pre-pandemic, but it is not all the same
> people. Bringing in the different participants is good.
>
> For the in-person meetings, I favour the stand-alone meeting, long enough
> to justify the travel time, rather than trying to extend some other event
> with a SIG. Attempting to extend another conference will make the entire
> trip very long. And too many different responsibilities conflicting for
> those active in the main conference, possibly not allowing the most active
> SIG members to concentrate on CRM because of their CIDOC duties, or CIDOC
> conference host duties, or presentations to give during CIDOC. For many
> years we have tried to extend IFLA to carry out standards work, and at best
> you can extend by one day, it can be hard to find a venue unsupported by
> the main conference, and everyone is already exhausted and often
> unprepared. Also, no matter what basic conference we attempt to extend,
> there will be a number of SIG members who do not find it relevant and would
> not be going.
>
> In summary, I agree with the mix of online and in-person, but not
> necessarily the formula for the in-person meeting. Like Rob I hesitate
> regarding the regional meetings, as adding too much logistical work and
> making the groups much too small to have the critical mass of expertise.
>
> Pat
>
> Pat Riva
> Acting University Librarian / Bibliothécaire en chef par intérim
> Concordia University / Université Concordia
> 1455 de Maisonneuve West, LB-331
> Montréal, Québec H3G 1M8
> Canada
> pat.r...@concordia.ca
>
> --
> *From:* Crm-sig  on behalf of Robert
> Sanderson via Crm-sig 
> *Sent:* July 7, 2022 1:11 PM
> *To:* Erin Canning 
> *Cc:* crm-sig 
> *Subject:* Re: [Crm-sig] New issues: Make SIG meetings more sustainable
>
>
> 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 

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

[George Bruseker via Crm-sig]

Dear all,

I also think that it would be useful to clarify who can or cannot vote and
what is the formal basis of voting and to have voting come from this base.
This does not mean that one has to vote if one formally is allowed to,
simply that the voting community is made clear. This would then also be a
reason to formally join the SIG (since one's institution could then vote).

Cheers,

George

On Tue, Jul 12, 2022 at 7:11 AM Pat Riva via Crm-sig 
wrote:

> I can say something about why I don't vote for all issues even when I was
> present for the discussion. I just don't have expertise in all the many
> areas covered by the CRM family. If the issue concerns, for example,
> whether a concept in archaeology has been well captured by a scope note, I
> will abstain. However, for a more logic-based or structural issue, or an
> editorial review of a text, I may well vote, even if it is in an extension
> for whose subject I don't have expertise.
>
> I'm not sure about this concept of formal voting members and non-voting
> members in SIG. I think we have sort of taken it on the honour system that
> people will only vote if they feel comfortable with the topic concerned.
>
> Pat
>
> Pat Riva
> Acting University Librarian / Bibliothécaire en chef par intérim
> Concordia University / Université Concordia
> 1455 de Maisonneuve West, LB-331
> Montréal, Québec H3G 1M8
> Canada
> pat.r...@concordia.ca
>
> --
> *From:* Crm-sig  on behalf of Erin Canning
> via Crm-sig 
> *Sent:* July 7, 2022 12:52 PM
> *To:* crm-sig 
> *Subject:* [Crm-sig] New issue: Improve voting process
>
> 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
>
___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

[Crm-sig] International Meeting Integrated Risk Management in Museums. Past Lessons, Future Ways

[George Bruseker via Crm-sig]

Dear all,

The organizer of this meeting invited me to share this link with you. They
were hoping to hear about CIDOC CRM but couldn't organize anything in time.

Regardless, it seems like a really good conference and of interest to some
in the community.

https://citcemnews.wixsite.com/irmm22

All the best and nice weekend,

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

[Crm-sig] New Issue: Common Policy / Method for Implementing the .1 Properties of Base and Extensions in RDF

[George Bruseker via Crm-sig]

Dear all,

Subsequent to another thread I started here I am proposing that there be a
conversation about having a standard policy and method for creating,
documenting and making available the .1 properties for base and its
extensions in the RDF serialization. At present to my knowledge the PC
classes are only available for CRMBase and relative to version 6.2.1. Other
extensions however also use .1 constructions and, moreover, CRMbase moves
forward and its PC classes should hypothetically move with it. Therefore, I
propose we discuss, create and implement a common policy for creating this
rdf derivative to support rdf implementations that adopt the .1
constructions.

Best,

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

[Crm-sig] More .1 Questions CRMArchaeo

[George Bruseker via Crm-sig]

Dear all,

I am also wondering about implementing .1 constructs in CRM Archaeo.
Although CRM Archaeo declares .1 properties that are actually essential to
its implementation, those properties are not (I believe) expressed in the
RDF that comes with CRM Archaeo. Is there a hidden PC file for CRM Archaeo
or does everyone generate their own? Should it have an official version?
This seems important in terms of the property classes being given the same
nomenclature etc or interoperability.

Maybe I missed them on the site.

Best,

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

[Crm-sig] Where to find all the .1s

[George Bruseker via Crm-sig]

Dear all,

I am wondering if we should have somewhere in the main document where
you can find all the .1 properties. Presently, to my knowledge, there is no
index of where these properties are. For those that use the .1 properties
it is difficult to find them all using the specification document. One
cannot search for '.1' as this returns too many results.

What do people think?

Best,

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

Re: [Crm-sig] E-vote for scope note part of issue 294 (CRMarchaeo)

[George Bruseker via Crm-sig]

Yes, to the reformulated text.

With this caveat, that the underlined in the formulation, " 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," sounds stylistically  awkward. Could just
switch out for 'in order to indicate that'?

Best,

George

On Mon, Mar 21, 2022 at 2:47 PM Hiebel, Gerald via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> YES
>
> Best,
>
> Gerald
>
>
>
> *From: *Crm-sig  on behalf of Martin Doerr
> via Crm-sig 
> *Reply to: *Martin Doerr 
> *Date: *Monday, 21. March 2022 at 12:44
> *To: *"crm-sig@ics.forth.gr" 
> *Subject: *Re: [Crm-sig] E-vote for scope note part of issue 294
> (CRMarchaeo)
>
>
>
> TES!
>
> Martin
>
> On 3/21/2022 1:24 PM, Christian-Emil Smith Ore via Crm-sig wrote:
>
> Dear all,
>
> As the issue number indicates issue 294 has been with for a while.
>
> In the 49th joint meeting of the CIDOC CRM SIG and SO/TC46/SC4/WG9; 42nd
> FRBR – CIDOC CRM Harmonization meeting, the sig accepted MD's proposal to
> change the quantification of  *appears in*, *restricted to*, *typical
> for *to *many-to-many, *as well as redraft their scope notes. The
> properties will be assigned the following AP numbers:
>
>- AP29 appears in
>- AP30 restricted to
>- AP31 typical for
>
> The new scope notes  are
> working definitions. The relations among types (issue 407
> )
> be taken into account, together with skos and other standards.
>
> HW: SdS to edit them.
>
> The edited version of the scope notes can be found here (and copied in a
> the end of this email:
>
> https://drive.google.com/drive/folders/1qS8aBP3UVLGn-WAXH6aH2vZp4wy1ME3t
>
>
>
> You are invited to vote on the scope note texts (not the name of the
> inverses which will be a separate e-vote)
>
>
>
> YES if you accept the edited texts
>
> NO if you don't accept the edited texts
>
> VETO if you think a e-vote is not ok at the current state
>
>
>
> The voting is open until 4th April.
>
>
>
> Best,
>
> Christian-Emil
>
>
>
>
>
> 294: E55 Type relations
>
> The SdS edits. The original text is highlighted in Yellow to make it
> easier to follow the differences.
>
>
>
> OLD
>
> AP29 appears in
>
> Domain: E55 Type
>
> Range: E4 Period
>
> Subproperty:
>
> Quantification: many-to-many (0,n:0,n)
>
> 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.
>
>
>
> NEW
>
> AP29 appears in
>
> Domain: E55 Type
>
> Range: E4 Period
>
> Subproperty:
>
> Quantification: many-to-many (0,n:0,n)
>
> Scope note: This property associates a kind of object (documented as an
> instance of E55 Type) with an
>
> instance of E4 Period indicating that objects of this kind have been
> brought into existence during
>
> this period. The genesis of such objects may be the result of human,
> biological, geological or other
>
> processes.
>
> This property makes a weak statement about the distribution of the
> associated object kind in the
>
> archaeological record: that is, if the genesis of an object of the type
> can plausibly be assumed to
>
> fall within the genesis of the context within which it was found, then
> this property supports
>
> reasoning, ceteris paribus, that the genesis period of the context forms
> part of, or overlaps with,
>
> one of the instances of E4 Period in which the respective object type has
> appeared. Such weak
>
> statements may also be useful in the context of geological or
> paleontological observations.
>
> Stronger claims can be made using the properties AP30 restricted to and
> AP31 typical for.
>
>
>
> OLD
>
> AP30 restricted to
>
> Domain: E55 Type
>
> Range: E4 Period
>
> Subproperty: appears in
>
> Quantification: many-to-many (0,n:0,n)
>
> 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 

Re: [Crm-sig] CALL FOR E-VOTE ISSUE 581

[George Bruseker via Crm-sig]

Dear Martin,


> May be you live in a different world, or make things artificially complex
> for the sake of providing absolute answers, which do not exist.
>

Interesting claim.


>
>
> The CRM method requires research questions.
>
> My implicit research question is simple: How do I prove that I am married?
> Please don't tell me by observation.
>
> Just tell me how that works. For this question, for this kind of bond, in
> Europe today. Please answer explicitly.
>

Different cultures and different groups at different times set up
different systems and methods for initiating, terminating and recognizing
different social facts. It depends on the language game that you
participate in (late Wittgenstein, check it out).

Is CRM meant to model European culture today or to model cultural
historical facts in general?


>
> Then we can discuss, if the distinction I made is practical, common sense
> and useful for this question or not.
>

You seem to suggest an event or state exists only if a document exists.
This seems far from common sense.

Best,

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

Re: [Crm-sig] CALL FOR E-VOTE ISSUE 581

[George Bruseker via Crm-sig]

Dear all,

Social symbolic events such as acquisitions (not done by force) are also
strictly not observable since you can only know that they occur if you
share the same social symbolic set and 'conclude' or 'infer' that something
has taken place. There is no atomic level at which we see these things and
can then say 'and now it is done'! Which atom, at what moment? Of course
there are various pieces of evidence you can go looking for and say these
are the things you must observe, but it's an obtuse way of looking at
things because if you are at the wedding and you are a literate member of
the cultural group then you know (barring an evil demon) that when the
bride has been kissed (and some books signed) that the event has occured.
You 'observed' it.

It is reasonable and natural for how to structure information and how to
ask questions to posit an observation acquisition event rather than saying
that what is observable is the book, the handshake etc.

This is the same with social institutions. No document need be consulted
for an alien anthropologist to land amongst CRM SIG discussion and
determine who the leader is. Having read a few background documents about
general human culture and observing a set of behaviours amongst a group of
people the anthropologist 'observes' M Doerr to be the leader. To say that
this is not observable is extremely hard to support (except again if we
argue only atomic configurations can be observed). What was observed is not
necessarily initiating and ending events (also symbolic, also only knowable
beyond physical material evidence), but a number of indicators within a
social symbolic system which indicated this to be the case.

It is thus equally natural to say that the social fact is observed although
in fact many minute individual observations were made etc. It would be
obtuse to ask for these to be listed instead of the fact in the same way it
would be for the event because this is not the form of evidence that is
typically required in the domain on inquiry.

Francesco points out for the nth time and I'm not sure why this cannot be
heard or acknowledge that historians usually do not have the kind of
evidence you ask for of physical events in space and time that start social
states. The historian is not at fault, the historical record is imperfect.
It is in this case not for the historian to change his practice but for the
ontologist to provide a structure which relates to the kind of reality that
the expert tries to describe.

As in observation in the sense of physics, the observer can be wrong.

Best,

George




On Tue, Mar 1, 2022 at 2:49 PM Martin Doerr via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear Francesco,
>
> May I object. I maintain that ownership is not observable. All examples
> you provided are about memories or documents of acquisition, or about those
> who claim to know those (who know/have known those) who know. The events of
> acquisition, in whatever form, are the only one that are observable. This
> does not require a higher conceptual consideration in the first place.
> Without counterexample, I cannot follow your criticism.
>
> All the best,
>
> Martin
>
> On 3/1/2022 11:47 AM, Francesco Beretta via Crm-sig wrote:
>
> Dear Athina,
>
> Thank you for taking of your time and for making explicit the reasons of
> your modelling choices and methodology.
>
> As University trained historians, we know that the model of the
> information produced by a project generally depends on the research agenda
> and the available sources. The model of a project is therefore not an
> ontology in the sense of a conceptualisation allowing for multi-project
> interoperability. Even the way of modelling a ship's voyage may change
> according to the lines of inquiry of different research projects. For this
> reason, a strict bottom-up modelling methodology in the field of historical
> research, and more broadly in the social sciences, without foundational
> analysis, doesn't seem to be the most appropriate way of producing an
> ontology for the whole portion of reality —a quite relevant portion in the
> cultural heritage perspective— these disciplines are concerned with.
>
> Regarding the ownership of a ship (
> https://en.wikipedia.org/wiki/Ship-owner), which in French is in some
> contexts referred to under the technical term 'armement' (
> https://fr.wikipedia.org/wiki/Armement_(marine) — cf. "registration
> activity" below), the social fact of ownership is as such and in general
> —in the sense of ontology— observable. One can ask sailors or informed
> contemporaries and they will know who the owner of the ship is. There are
> historical sources, for example correspondence, which attest to the role of
> shipowners (*armateurs*) of such and such a person or company, even if we
> have lost the shipping registers which state the events of taking ownership.
>
> In the Sealit project, a methodological choice or stance was adopted which
> is certainly legitimate in the 

[Crm-sig] Issue 528 HW: Where to put the translations

[George Bruseker via Crm-sig]

Dear all,

A sub aspect of the issue that Philippe will introduce around translations
is 'where to put the translations' on the website. I was tasked with doing
this some SIGs ago. The HW has been there for a while. Time permitting, we
can look at it!

https://docs.google.com/document/d/1BiGrX_pieVCCwlNf-JQweHkwTp57mfY58SIPxBvwkhw/edit?usp=sharing

Best,

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

Re: [Crm-sig] Issue 580: CRMsoc redefinition of scope

[George Bruseker via Crm-sig]

Hi All,

Here is a link to the folder in the SIG CIDOC CRM Drive for issue 580
containing all the pertinent homework which is:

Scope of CRMSoc
List of Classes and Properties to be redistributed / considered
New Spec doc with initial classes and properties proposed

https://drive.google.com/drive/folders/10XSepHjX_ua4_2n783VOW1syXGCKITo_?usp=sharing

the last can also be accessed directly here:

https://docs.google.com/document/d/1p6sLZ4GA073T4mIdsMj4s5VJEEdstZZF/edit?usp=sharing=115809866274616295104=true=true

All best,

George

On Mon, Feb 7, 2022 at 3:30 PM George Bruseker 
wrote:

> Hi All,
>
> Another part of this homework was to clear up the state of classes that
> were 'in' CRMSoc under the old definition, being considered to be in or
> just being bandied about as ideas. The idea is to house clean the whole
> business so that we can start off anew in the correct direction and also
> release classes and properties that would now be appropriate to a different
> extension to be developed there without any confusion.
>
> Attached then is the list of classes and properties that had been talked
> about in some way or other under the banner of CRMSoc and a suggestion of
> where they might go or what might become of them.
>
>
> https://docs.google.com/spreadsheets/d/1tzRcBqlAyTf9SQavbl8IEC9CHYMb_hip_kmGtYQGTR4/edit?usp=sharing
>
> Best,
>
> George
>
>
___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

Re: [Crm-sig] Issue 580: CRMsoc redefinition of scope

[George Bruseker via Crm-sig]

Hi All,

Another part of this homework was to clear up the state of classes that
were 'in' CRMSoc under the old definition, being considered to be in or
just being bandied about as ideas. The idea is to house clean the whole
business so that we can start off anew in the correct direction and also
release classes and properties that would now be appropriate to a different
extension to be developed there without any confusion.

Attached then is the list of classes and properties that had been talked
about in some way or other under the banner of CRMSoc and a suggestion of
where they might go or what might become of them.

https://docs.google.com/spreadsheets/d/1tzRcBqlAyTf9SQavbl8IEC9CHYMb_hip_kmGtYQGTR4/edit?usp=sharing

Best,

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

Re: [Crm-sig] Issue 580: CRMsoc redefinition of scope

[George Bruseker via Crm-sig]

Following on this helpful new iteration of the thought by Martin maybe a
phrasing like 'in distinction to facts established directly through / at
the level  of material physical processes and interactions' is more
expressive of the content/intent?







On Thu., Feb. 3, 2022, 11:52 p.m. Martin Doerr via Crm-sig, <
crm-sig@ics.forth.gr> wrote:

> On 2/2/2022 10:36 PM, Francesco Beretta via Crm-sig wrote:
>
> Dear Martin,
>
> Thank you for your message and comments.
>
> The sentence in question is not the happiest, and George and myself were
> not totally satisfied with the wording but it was necessary to send the
> homework to the SIG. We can of course reword it and a refomulation that is
> certainly also not the best one but expresses the same sense could be:
>
> " For facts which are established by convention as opposed to facts
> observed in an objective manner
>
> sure, should be something like the material process characterizing the
> events,
>
> Take an exemple. I organize a garden party and all my friends and guests
> are happy. But there’s a major difference if I do this privately in 2019 or
> if I’m a prime minister and there’s a COVID pandemic and I just imposed
> restrictive measures on the whole population of my country. The [objective
> / spatio-temporal] observed fact is the same, a crm:E5 garden party, but
> the social ‘facts’ arount it —my social function, the law establishing that
> garden parties are not allowed, etc. etc.— add a social overlay to the
> event which —for humans living in society— changes everything and has
> totally different consequences. CRMbase is concerned with objective
> spatio-temporal facts (from E4 Period downward this is the substance of
> facts : “This class comprises sets of coherent phenomena or cultural
> manifestations occurring *in time **and space*.”)
>
> On the other hand, social facts are situated in another space that could
> be called the intentional-temporal, that is to say, the space of phenomena
> specific to human societies observed through the filter of their
> conventions or collective representations. There is no opposition but a
> perfect articulation because the social is grafted onto the spatio-temporal
> (or the physical and biological) but adding an overlay that allows
> different groups of humans to interpret the same ‘objective’ fact as being
> two quite different situations: a totally normal and a big problem.
>
> But I propose to discuss all this, as you proposed earlier, in person at a
> live, even if digital, meeting.
>
> Best
>
> Francesco
>
>
> Le 02.02.22 à 20:11, Martin Doerr via Crm-sig a écrit :
>
> Dear Francesco,
>
> I find this text very well written and clear. My only question is, why:
>
> " For facts which are established by convention as opposed to pure
> spatio-temporal facts,"
>
> I do not see ground in the CRMbase, and the methodology applied, to regard
> that facts which are described in the CRM are "pure spatio-temporal", even
> if some of the classes and properties applied may describe only a
> spatiotemporal confinement. The CRM is very clear that the substance of
> Temporal Entities is not space-time.
>
> Further, respective facts you describe would be based on human activities,
> and E7 is defined explicitly as being intentional in substance.
>
> Finally, and most important, there seems to be a misunderstanding of CRM
> descriptions in general: no classification and properties of the CRM are
> exhaustive or "pure" in any sense. This is also the major idea behind
> multiple instantiation, and open world. Describing an item in terms of CRM
> does not make any statement what else it is not, except for a few
> definitely disjoint classes.
>
> Since this is a key concept of the CRM, part of the principles, it should
> be discussed. To my understanding, no extension can be characterized as
> "opposed to" another, it would violate its logical foundations.
>
> All the best,
>
> Martin
>
>
> On 2/1/2022 2:13 PM, Francesco Beretta via Crm-sig wrote:
>
> Dear all,
>
>
> Please find in attachment the homework of George Bruseker and myself
> concerning "Issue 580: CRMsoc redefinition of scope" for presentation at
> the next SIG.
>
> All the best,
>
> Francesco
>
> ___
> 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 Comput

Re: [Crm-sig] Issue 429 Homework 'has aptitude in'

[George Bruseker via Crm-sig]

Hi Matthew,

There is a long trail on this discussion nwhere there is quite some
disagreement whether we can assert knowledge or skill regarding someone so
I was going for some phrasing that was as light as possible and hence
landed on aptitude. I would be happy with has knowledge of or has skill in
or has know how of, but aptitude was an effort to be in line with epistemic
conservatives. Happy to strengthen it if everyone else would want.

Welcome back!

Best,

George

On Thu, Jan 27, 2022 at 9:31 PM Matthew Stiff 
wrote:

> Apologies - I've been hybernating for a long time so have come in on this
> issue without prior knowledge but one-time CRM editing experience (so "hi"
> to old friends).
>
> I think there is ambiguity in the names and scope notes here when it comes
> to aptitude and ability. Aptitude suggests the ability to acquire
> particular knowledge or skills (ability to have an ability). It doesn't
> mean that the individual actually has them. For example, I have the
> aptitude to read tomorrow's Guardian but I haven't done so yet (we could
> argue that I also have the ability, but until I see the words).
>
> I can see how ability can be measured but not aptitude, other than by
> evidence of ability in something similar (e.g. Aptitude for learning
> Portuguese through current ability in Spanish).
>
> I think these properties are describing skills or abilities that have
> already been acquired. They make sense if the word "aptitude" is replaced
> with "ability".
>
> Hope this is helpful. Please ignore if not.
>
> Best wishes,
>
> Matthew
> Dr Matthew Stiff MSc DPhil DPsych CPsychol
> Counselling Psychologist
> Matthew Stiff Counselling Psychology
>
> (m) 07939 151510
> --
> *From:* Crm-sig  on behalf of George
> Bruseker via Crm-sig 
> *Sent:* Thursday, January 27, 2022 6:07:08 PM
> *To:* crm-sig 
> *Subject:* [Crm-sig] Issue 429 Homework 'has aptitude in'
>
> Hi all,
>
> Following up on this issue, I have had a hack at proposing a property name
> and scope for a general skills type property. Here it is:
>
>
> https://docs.google.com/document/d/1kge1gqohcr4NQK89kxbhiLfGuqgzassJpWze81GgmBc/edit?usp=sharing
>
> Best,
>
> George
>
>
___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

[Crm-sig] Issue 429 Homework 'has aptitude in'

[George Bruseker via Crm-sig]

Hi all,

Following up on this issue, I have had a hack at proposing a property name
and scope for a general skills type property. Here it is:

https://docs.google.com/document/d/1kge1gqohcr4NQK89kxbhiLfGuqgzassJpWze81GgmBc/edit?usp=sharing

Best,

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

[Crm-sig] Issue 578 CRMSci O19 Property Labels Minor Correction? Homework

[George Bruseker via Crm-sig]

Hi all,

Here is the homework for 578 in the CRM SIG google drive:

https://docs.google.com/document/d/1EXSW6CRV3T1G05UpO8mH7hZwMDTu1_VvjzmzcaeudlI/edit?usp=sharing

Best,

George
___
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?

[George Bruseker via Crm-sig]

>
>
> Forgive me George for bringing up my original comment - it is entirely
> possible that I have not understood the problem.
>

V happy to discuss it.


>
> It seems to me that what is really missing is the connection between the
> event and the outcome. It seems that you are saying that it is a causal
> connection. Shortcutting that to the type of the outcome is exactly the
> process of Typed Properties (TPs) and negating that is the process of
> Negative Typed Properties (NTPs), both of which are still being baked.
> Adding TPs to CRM base is a bad idea in my view, as it is a specific
> solution for RDFS and it is not needed in other implementations.
>
> So maybe break down the problem to:
>
> 1) See if we need a new class for outcome
>

I argue that the outcome is an event (this being a possible sense of
outcome).


> 2) Define a causal property (which we have avoided so far)
>

o13 triggers basically does the trick


> 3) Finish the TPs and NTPs, which I hope will be done soon
>

that would mean applying them to CRMSci I guess


>
> Maybe discussing live at the SIG is easier.
>

Probably!

Cheers,

G


>
> All the best,
>
> Thanasis
>
> On 07/01/2022 10:08, George Bruseker via Crm-sig wrote:
> > Hi Rob / Francesco / Martin,
> >
> > These are all nice examples that maybe we could dig into further, maybe
> > they display the 'senses of outcome' problem Martin is pointing to?
> >
> > An ontological problem that seems to come up in my mind as I try to
> > conceptualize this is do we mean
> >
> > 1) outcome of type in the sense of a shortcut for a real particular
> > event of a type (the particular event we do not know much about expect
> > that it was caused by the first event and has some type)
> >
> > 2) outcome of a type in the sense of a shortcut for a real particular
> > event that had particular properties (the particular event we do not
> > know much about expect that it produced something, showed something,
> > modified something and was caused by the first event)
> >
> > 3) outcome as an evaluation of achievement of an event (succeeds, fails)
> > - we only talk about one event and evaluate whether it achieves its goal
> >
> > These can all cause trouble.
> >
> > So for example the JFK Assassination:
> >
> > (E7) Shooting at JFK, (E69) JFK dies
> >
> > So if we choose to model these as two separate events (legitimate), then
> > Shooting of JFK had general purpose 'death' and we know in fact that the
> > shooting triggers the death of JFK (no bullets in JFK, no dead JFK that
> > day, the shooting caused the death).
> >
> > So the shortcut 'had outcome of type' could be 'death' just in case we
> > didn't know anything about the particular death event of JFK and didn't
> > want to instantiate it as a node.
> >
> > Shooting of JFK (E7) triggers Death of JFK (E69) has type "Death" (E55)
> >
> > So here it is that there is an event of type X that is shortcut.
> >
> > That would be sense 1.
> >
> > Sense 2 would be something like
> >
> > Shooting at JFK (E7) triggers Death of JFK (E69) kills JFK (E21)
> >
> > So here it would be the particular property of E69 to 'kill' an E21 that
> > would be shortcuted
> >
> > We could also have sense 3, 'had outcome of type' 'success'. As in, the
> > assassin had general purpose 'death' and the outcome was 'success'.
> >
> > How would this work in the other examples:
> >
> > An archeological expedition -- resulted in outcome of type "came
> > home empty handed" / "found something"
> >
> >
> > So we have an initial event
> >
> > Archeological Expedition (E7) has general purpose "Find Something" (E55)
> > Archeological Expedition (E7) had outcome of type "Found Something" (E55)
> >
> > And then would the shortcut mean:
> >
> > a) Archeological Expedition (E7) triggered Dig Activity (A1) has type
> > Found Something (E55)
> >
> > or
> >
> > b) Archeological Expedition (E7) triggered Dig Activity (A1)
> > encountered Object (E22)
> >
> > (so here because E22 is 'something', the shortcut is true... that would
> > seem more like a rule than a property)
> > or
> >
> > c) Archeological Expedition (E7) had purpose Find Something (E55)
> > Archeological Expedition (E7) had outcome of type Found Something (E55)
> >
> > So here it wouldn't imply a pass through to another event but would
> > evaluate this event in itself.
> >
>

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

[George Bruseker via Crm-sig]

Hi Rob / Francesco / Martin,

These are all nice examples that maybe we could dig into further, maybe
they display the 'senses of outcome' problem Martin is pointing to?

An ontological problem that seems to come up in my mind as I try to
conceptualize this is do we mean

1) outcome of type in the sense of a shortcut for a real particular event
of a type (the particular event we do not know much about expect that it
was caused by the first event and has some type)

2) outcome of a type in the sense of a shortcut for a real particular event
that had particular properties (the particular event we do not know
much about expect that it produced something, showed something, modified
something and was caused by the first event)

3) outcome as an evaluation of achievement of an event (succeeds, fails) -
we only talk about one event and evaluate whether it achieves its goal

These can all cause trouble.

So for example the JFK Assassination:

(E7) Shooting at JFK, (E69) JFK dies

So if we choose to model these as two separate events (legitimate), then
Shooting of JFK had general purpose 'death' and we know in fact that the
shooting triggers the death of JFK (no bullets in JFK, no dead JFK that
day, the shooting caused the death).

So the shortcut 'had outcome of type' could be 'death' just in case we
didn't know anything about the particular death event of JFK and didn't
want to instantiate it as a node.

Shooting of JFK (E7) triggers Death of JFK (E69) has type "Death" (E55)

So here it is that there is an event of type X that is shortcut.

That would be sense 1.

Sense 2 would be something like

Shooting at JFK (E7) triggers Death of JFK (E69) kills JFK (E21)

So here it would be the particular property of E69 to 'kill' an E21 that
would be shortcuted

We could also have sense 3, 'had outcome of type' 'success'. As in, the
assassin had general purpose 'death' and the outcome was 'success'.

How would this work in the other examples:
>


> An archeological expedition -- resulted in outcome of type "came home
> empty handed" / "found something"
>

So we have an initial event

Archeological Expedition (E7) has general purpose "Find Something" (E55)
Archeological Expedition (E7) had outcome of type "Found Something" (E55)

And then would the shortcut mean:

a) Archeological Expedition (E7) triggered Dig Activity (A1) has type Found
Something (E55)

or

b) Archeological Expedition (E7) triggered Dig Activity (A1)
encountered Object (E22)

(so here because E22 is 'something', the shortcut is true... that would
seem more like a rule than a property)

or

c) Archeological Expedition (E7) had purpose Find Something (E55)
Archeological Expedition (E7) had outcome of type Found Something (E55)

So here it wouldn't imply a pass through to another event but would
evaluate this event in itself.


Commission of an artwork -- resulted in outcome of type "artist ran off
> with the money" / "artist produced something else" / "artist produced what
> was wanted" / ...
>

Commission of Artwork (E7) had general purpose 'production of artwork'
Commission of Artwork (E7) had outcome of type "artist ran off with the
money" / "artist produced something else" / "artist produced what was
wanted"

And then would these shortcuts mean:

a) Commission of Artwork (E7) triggered Production (E12) has type "artist
produced something else" / "artist produced what was wanted" (E55)

or

Commission of Artwork (E7) triggered Activity (E7) has type "artist ran off
with the money" (E55)

So in the above cases it either shortcuts an E12 or an E7 which we don't
have any details about but for which we would have classificatory terms
like 'desired production', 'undesired production' OR 'theft/loss' or
something like this. As per Martin's mail on types it falls to the
vocabulary to tell us which CRM event type is implied...

or

b) Commission of Artwork (E7) triggered Production (E12) produced Some
Object (E22)

(so here because E22 is 'something', the shortcut is true... that would
seem more like a rule than a property)

But if we do this then we would have to put the 'desired production' or
'undesired production' categories on the E22 and the non production / non
created thing would not be expressible.

or

c) Commission of Artwork (E7) had purpose "Build Something" (E55)
Archaological Expedition (E7) had outcome of type "Built that Something"
(E55)

This above case however seems like it would be better covered by the Plans
modelling since what makes something meet or not meet a criterion is
complicated...?


> Exhibition planning -- resulted in outcome of type "exhibition" / "no
> exhibition" / "revised exhibition" / ...
>


Exhibition Planning (E7) has general purpose "Run Exhibition" (E55)
Exhibition Planning (E7) had outcome of type "exhibition" / "no exhibition"
/ "revised exhibition" (E55)

And then would the shortcut mean:

a) Exhibition Planning (E7) triggered Exhibition (E7) has type "Exhibition"
/ "Revised Exhibition" (E55)

it seems here we 

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

[George Bruseker via Crm-sig]

Hi Martin,

Quoting self, "in the idiom of CRM, I am proposing that this be restricted
to the concept of one event resulting in another event of a type.

E7 pxxx had outcome of type E55 (of an E5/7).

So I am looking for a CRM property that would be able to denote a similar
concept to the one that the English language term 'outcome' denotes when it
is uttered.""

Best,

George


On Thu, Jan 6, 2022 at 8:42 PM Martin Doerr  wrote:

> Sorry,
>
> I mean (Oxford Dictionary):
>
> "outcome
> noun [ C usually singular ]
> <https://dictionary.cambridge.org/de/help/codes.html>
> uk
> /ˈaʊt.kʌm/ us
> /ˈaʊt.kʌm/
> C1
> a result <https://dictionary.cambridge.org/de/worterbuch/englisch/result>
> or effect <https://dictionary.cambridge.org/de/worterbuch/englisch/effect>
> of an action
> <https://dictionary.cambridge.org/de/worterbuch/englisch/action>,
> situation
> <https://dictionary.cambridge.org/de/worterbuch/englisch/situation>,
> etc.:
> It's too early to predict
> <https://dictionary.cambridge.org/de/worterbuch/englisch/predict> the
> outcome of the meeting
> <https://dictionary.cambridge.org/de/worterbuch/englisch/meeting>.
> Thesaurus: synonyms, antonyms, and examples
> the result of something
> <https://dictionary.cambridge.org/de/thesaurus/articles/the-result-of-something>
>
>- result <https://dictionary.cambridge.org/de/thesaurus/result>His
>firing was a direct result of his refusal to follow the employment 
> policies.
>- effect <https://dictionary.cambridge.org/de/thesaurus/effect>The
>radiation leak has had a disastrous effect on the environment.
>- consequence
><https://dictionary.cambridge.org/de/thesaurus/consequence>Failure to
>do proper safety checks may have serious consequences.
>- outcome <https://dictionary.cambridge.org/de/thesaurus/outcome>It's
>too early to predict the outcome of the meeting.
>- upshot <https://dictionary.cambridge.org/de/thesaurus/upshot>The
>upshot of the discussions is that there will be no further redundancies.
>- end result <https://dictionary.cambridge.org/de/thesaurus/end-result>The
>end result of these changes should be a more efficient system for dealing
>with complaints.
>
> What do you mean of all that? The fact that equivalent words exist in some
> other languages has nothing to do with definition.
>
> I hope this is comprehensible.
>
> Best,
>
> Martin
>
> On 1/6/2022 8:21 PM, Robert Sanderson wrote:
>
>
> 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
>>>

Re: [Crm-sig] About ... entity of Type?

[George Bruseker via Crm-sig]

Hi Martin,


> We use the “type" because it implies necessarily if it is a perdurant or
> endurant, person etc. If it does not, it is ill-defined, and has no place
> in a Thesaurus (see the AAT).
>

Unfortunately, I find many thesuri don't follow good ontological
principles, so we are forced for workarounds, but okay.


> If the categories of a thesaurus fit the CRM is a mapping problem.
>
> No problem for retrieval at all. Just a programmers job.
>

That job can be very expensive!


>
> Place types are relatively rare, such as "river" "lake", "city". The UMLS
> system e.g., listed some decade ago I think 10 or 20 million types, but
> less than 100 properties, corresponding to at most 200 classes. Therefore,
> P2 is not "cheap", but it does never replace meaningful properties.
>


"Cheap" in "Cheap and Cheerful" is not a denigration...
https://www.macmillandictionary.com/dictionary/british/cheap-and-cheerful

Cheers,

George

>
___
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?

[George Bruseker via Crm-sig]

Hi Rob / Martin,

Yes, Rob provides a nice instance example.

Again, I just want to explore whether such a property has applications
beyond this scope. Perhaps it isn't needed but if we look at more examples
maybe a generalization will arise.

Best,

George

On Thu, Jan 6, 2022 at 7:53 PM Robert Sanderson  wrote:

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

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

[George Bruseker via Crm-sig]

Dear Martin,

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 have a general E7 Activity which I use to capture instances which I use
as a container for many different provenance related activities. Every time
an activity (E7) that involves something like a transfer of custody
ownership offer of an object takes place, I create an instance of this
activity (the indivdual transfer etc is a part of the overall activity). So
the activity usually has a general purpose 'sale' for example... it's a
general human activity (E7) which involves some people and it involves a
purpose 'sale'. It is NOT THE SALE, but is an activity aiming towards such
a thing. We may or may not know of the next activity. Did the sale happen,
didn't it? Maybe we know, maybe we don't know. Maybe we know on the
particular level ... yes this sale  on feb 9, 2021 happened. Or, only
'yes some sort of sale happened', but not which particular sale.

As said before so much of this can be covered already, but this knowledge
of 'some kind of event' was caused by this event is not presently
expressible.

I don't really need help with the provenance modelling, I have that
covered. I am just looking for a way to more accurately represent an
outcome known at the categorial level (not some particular event but some
kind of event).



>
> 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.
>

This sounds good, but I'm not using that model and have the above situation
so in my case the need does arise.


>
> 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.
>

This is very advanced for me. 'Outcome' is an English language word (which
I assumed we use as our lingua franca in CRM discussions). Looking it up I
find, "the result or effect of an action, situation, or event."
https://dictionary.cambridge.org/dictionary/english/outcome I assume in
referencing it to call up this general concept for other speakers/users of
English. I too think it is a word of language. It seems to me that the word
denotes, "the result or effect of an action, situation, or event." So, and
I don't know how to put this not in language (and furthermore English), it
denotes the concept, "The result or effect of an action, situation or
event."

Now in the idiom of CRM, I am proposing that this be restricted to the
concept of one event resulting in another event of a type.

E7 pxxx had outcome of type E55 (of an E5/7).

So I am looking for a CRM property that would be able to denote a similar
concept to the one that the English language term 'outcome' denotes when it
is uttered. I suppose the ontological nature of an outcome as thus denoted
is an event caused by an other event (actually an event of a type). I
believe that this concept is not restricted to English speakers but is
probably widely shared.


>
> 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?
>

I don't understand about the cheap is cheerful comment, it is a pretty
standard phrase. (FUN!)

The second part 'what would the type pertain to', is exactly my problem
though, why I don't want to use this solution. The type does not pertain to
my E7 Activity but rather to an E7 Activity that it cause

Re: [Crm-sig] About ... entity of Type?

[George Bruseker via Crm-sig]

Dear Martin,

I'm glad to hear you have encountered such cases as well and find it a
potentially good path to explore. I find myself in a conundrum thinking
about (my own) proposal because of the vagueness of the word 'entity'.

What I find typical in many modelling exercises regarding bibliography is
that aboutness can be about the following real world, particular things:

subject - E55
geographic location / place - E53
person / corporation - E39

So already there is typically some breakdown of aboutness into different
main kinds of real, particular things that a work can be about.

When I reflect on the property 'represents entity of type', the examples
are all of endurants. This may be an accident but it makes me wonder about
whether a new specialization of aboutness to refer to 'things of type'
would best follow this general pattern (the entity could be a perdurant,
endurant, place etc.) or if the property would better be more specialized.
(is about temporal event of type, is about persistent item of type, is
about place of type).

It just occurs to me that in the context of retrieval if the property were
not more specific to perdurants / endurants etc. then it could be quite
difficult to sort out if you want to find works about events of type vs
works about things of type vs works about places of type etc. This is not a
problem when the aboutness property is about a particular because we can
use the class to differentiate. 'Given me E73 about E39'  automatically
culls the data down to the aboutness regarding actors. If the new property
pointed to E55, then we would not have this facility.

So... hopefully still a good idea but seems to have some complications to
be thought through.

Best,

George

On Sat, Jan 1, 2022 at 6:43 PM Martin Doerr via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear George,
>
> I think this is a very good idea. There are thousands of archaeological
> publications listing items etc. of certain types, often with reference to
> museums keeping them, but library practice will only register overall
> aboutness. Museum records cite such publications explicitly, but the
> inverse has never been exploited systematically.
>
> Cheers,
>
> martin
>
> On 12/14/2021 6:55 PM, George Bruseker via Crm-sig wrote:
>
> better phrasing, 'about a particular thing that is known categorically'
>
> Eg Sales Record about 'Sale Event'
>
>
>
> On Tue, Dec 14, 2021 at 6:53 PM George Bruseker 
> wrote:
>
>> Dear all,
>>
>> Recently work is on-going on a new property 'represents thing of type'
>> which is distinct from 'represents' (again that particular vs categorical
>> distinction).
>>
>> https://cidoc-crm.org/Issue/ID-476-pxx-represents-entity-of-type
>>
>> I am confronted with cases of an information object being about not a
>> particular thing but a category of thing... in my case event types but I
>> guess it could be object types. Of course the existing 'about' property is
>> sufficient but it doesn't allow to differentiate that it is not just a type
>> but about an as yet unknown X which was of type Y... It seems to me similar
>> to the other new property we are working on already.
>>
>> Does anybody else have cases like this? Any interest in a new parallel
>> property like that OR a solution that requires no new properties but also
>> doesn't require semantic back flips to understand?
>>
>> Best,
>>
>> George
>>
>
> ___
> 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
>
___
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?

[George Bruseker via Crm-sig]

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.

The cheap and cheerful solution would just be to put this as a p2 has
type... the typical solution.

It would nice to be more accurate though since the categorization isn't of
the event itself but of its typical outcome. 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).

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.

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 as
> production, modification etc.
>
> The interesting case are processes which are known to be abandoned, but
> what that means needs further investigation: How much of action has been
> done and left historical traces?
>
> Processes which have not been finished during recording time are another
> case. This is notoriously difficult, and resembles the "current"
> discussions. We may need an "still ongoing", which should be harmonized
> with the time-spans.
>
> Unknown parameters of an event, such as purchase from unknown to unknown,
> do not need a n "outcome" property, but are just a specific event an object
> has experienced.
>
> Isn't it?
>
> Other kinds of "outcomes" can be modifications, obligations, receiving
> knowledge of, transfer of properties between "input-output" etc. May be it
> is time to study if we can create a relatively comprehensive list. Some
> events may only leave memory as only persistent thing, e.g. performances.
>
> To be discussed!
>
> Best,
>
> Martin
>
> On 12/31/2021 8:29 PM, Martin Doerr via Crm-sig wrote:
>
> Dear All,
>
> The missing property of outcome is so far deliberate in the CRM, because
> we could not identify a general case. In contrast, there are models with
> input-output semantics, but this is a very small subset.
>
> As in all such cases, we first need a collection of examples, and study if
> there exist common semantics, or if it splits in a set of more specific
> cases. I'd expect about 5 kinds of outcomes. If you give me the time, I can
> present in the next meeting some.
>
> All the best,
>
> Martin
>
>
> On 12/20/2021 6:45 PM, George Bruseker via Crm-sig wrote:
>
> Hi Thanasi,
>
> The proposal creates a consistent way of doing the 'type of' version of a
> property that relates one particular to another particular.
>
> So  each individual property:
> https://cidoc-crm.org/Property/P20-had-specific-purpose/version-7.1.1
> has its typed version like:
> https://cidoc-crm.org/Property/P21-had-general-purpose/version-7.1.1
>
> Right?
>
> But I contend there IS NO particular property in regular CRM that
> expresses the semantics I indicate above (therefore the proposal cannot
> generate its typed version). P21 DOES NOT express the semantics I need
> (hence also not P23).
>
> O13 triggers more or less does. in particular. But I need the
> generalization. Triggered an outcome of type.
>
> Anyhow, not sure if anyone else needs this, but very common in my data.
>
> Cheers,
> G
>
> On Mon, Dec 20, 2021 at 4:35 PM Athanasios Velios 
> wrote:
>
>> Following Athina's response and in relation to the question about the
>> extant properties, I guess the "type of type" can be replicated with
>> thesaurus related properties (e.g. P127 has broader term). I would
>> consider the instances of E55 Type sli

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

[George Bruseker via Crm-sig]

Hi Thanasi,

The proposal creates a consistent way of doing the 'type of' version of a
property that relates one particular to another particular.

So  each individual property:
https://cidoc-crm.org/Property/P20-had-specific-purpose/version-7.1.1
has its typed version like:
https://cidoc-crm.org/Property/P21-had-general-purpose/version-7.1.1

Right?

But I contend there IS NO particular property in regular CRM that expresses
the semantics I indicate above (therefore the proposal cannot generate its
typed version). P21 DOES NOT express the semantics I need (hence also not
P23).

O13 triggers more or less does. in particular. But I need the
generalization. Triggered an outcome of type.

Anyhow, not sure if anyone else needs this, but very common in my data.

Cheers,
G

On Mon, Dec 20, 2021 at 4:35 PM Athanasios Velios 
wrote:

> Following Athina's response and in relation to the question about the
> extant properties, I guess the "type of type" can be replicated with
> thesaurus related properties (e.g. P127 has broader term). I would
> consider the instances of E55 Type slightly differently to normal
> instances and not extent the idea to them.
>
> T.
>
> On 14/12/2021 19:42, George Bruseker wrote:
> > Hi Thanasi,
> >
> > Yes that's true. Good reminder. That might be a solution but then we
> > would need the particular property for expressing that two events are
> > causally connected. I avoided to put it in the last email so as not to
> > stir up to many semantic teapots. But obviously to have the general
> > property we should have the particular property. So we have for example
> > we have the particular properties:
> >
> > https://cidoc-crm.org/Property/P20-had-specific-purpose/version-7.1.1
> > <https://cidoc-crm.org/Property/P20-had-specific-purpose/version-7.1.1>
> > and
> > https://cidoc-crm.org/Property/P21-had-general-purpose/version-7.1.1
> > <https://cidoc-crm.org/Property/P21-had-general-purpose/version-7.1.1>
> >
> > so the analogy to this in my situation is probably
> >
> > O13 triggers (is triggered by)
> > https://cidoc-crm.org/crmsci/sites/default/files/CRMsci%20v.1.4.pdf
> > <https://cidoc-crm.org/crmsci/sites/default/files/CRMsci%20v.1.4.pdf>
> > and we need the analogy of p21 to make the model complete
> >
> > On another note out of curiosity, in the extension where every property
> > has a 'type of' property what happens with the extant 'type of'
> > properties? I assume there isn't any has general purpose of type
> > property... or is there?
> >
> > Cheers
> >
> > G
> >
> > On Tue, Dec 14, 2021 at 9:20 PM Athanasios Velios via Crm-sig
> > mailto:crm-sig@ics.forth.gr>> wrote:
> >
> > Hi George, all,
> >
> > As part of Linked Conservation Data (and with the help of Carlo,
> Martin
> > and Steve) we proposed the idea of Typed Properties which derive from
> > current CRM properties and always have E55 Type as range.
> >
> > E.g. "bears feature" → "bears feature of type" so that one can
> describe
> > the type of something without specifying the individual. It is very
> > economical in conservation where we want to avoid describing
> > hundreds of
> > individuals of similar types.
> >
> > We are still baking the exact impact of such a reduction from
> > individuals to Types. One issue in RDFS is the multitude of new
> > properties. There seems to be a simple implementation in OWL with
> > property paths. Not an immediate solution but a flag for more to
> come.
> >
> > All the best,
> >
> > Thanasis
> >
> > On 14/12/2021 15:49, George Bruseker via Crm-sig wrote:
> >  > Hi all,
> >  >
> >  > I have situations in which I have events where the data curators
> >  > describe events for which they have generic knowledge of the
> > outcome:
> >  > sold, completed, incomplete, this sort of thing. So there is
> > knowledge
> >  > but it is not knowledge of the particular next event but of a
> > general
> >  > kind of outcome.
> >  >
> >  > We have properties like: P21 had general purpose (was purpose of)
> > which
> >  > is very useful for when the data curator only has generic
> knowledge
> >  > knowledge and not particular knowledge regarding purpose. This
> > seems a
> >  > parallel to this case.
> >  >
> >  > Anybody else have this case and have an interest in a proper

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

[George Bruseker via Crm-sig]

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 <http://prefix.cc> :
>
> 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

[Crm-sig] CIDOC CRM Digital Game Interview

[George Bruseker via Crm-sig]

Dear all,

Here is an interview with Olivier Marlet by Humanum on the interest and use
of a digital game for teaching and learning CIDOC CRM.

https://www.youtube.com/watch?v=0ZF34982h-M

Best,

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

[Crm-sig] Official NameSpaces of CRM Extensions?

[George Bruseker via Crm-sig]

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

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

[George Bruseker via Crm-sig]

Hi Thanasi,

Yes that's true. Good reminder. That might be a solution but then we would
need the particular property for expressing that two events are causally
connected. I avoided to put it in the last email so as not to stir up to
many semantic teapots. But obviously to have the general property we should
have the particular property. So we have for example we have the particular
properties:

https://cidoc-crm.org/Property/P20-had-specific-purpose/version-7.1.1
and
https://cidoc-crm.org/Property/P21-had-general-purpose/version-7.1.1

so the analogy to this in my situation is probably

O13 triggers (is triggered by)
https://cidoc-crm.org/crmsci/sites/default/files/CRMsci%20v.1.4.pdf
and we need the analogy of p21 to make the model complete

On another note out of curiosity, in the extension where every property has
a 'type of' property what happens with the extant 'type of' properties? I
assume there isn't any has general purpose of type property... or is there?

Cheers

G

On Tue, Dec 14, 2021 at 9:20 PM Athanasios Velios via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Hi George, all,
>
> As part of Linked Conservation Data (and with the help of Carlo, Martin
> and Steve) we proposed the idea of Typed Properties which derive from
> current CRM properties and always have E55 Type as range.
>
> E.g. "bears feature" → "bears feature of type" so that one can describe
> the type of something without specifying the individual. It is very
> economical in conservation where we want to avoid describing hundreds of
> individuals of similar types.
>
> We are still baking the exact impact of such a reduction from
> individuals to Types. One issue in RDFS is the multitude of new
> properties. There seems to be a simple implementation in OWL with
> property paths. Not an immediate solution but a flag for more to come.
>
> All the best,
>
> Thanasis
>
> On 14/12/2021 15:49, George Bruseker via Crm-sig wrote:
> > Hi all,
> >
> > I have situations in which I have events where the data curators
> > describe events for which they have generic knowledge of the outcome:
> > sold, completed, incomplete, this sort of thing. So there is knowledge
> > but it is not knowledge of the particular next event but of a general
> > kind of outcome.
> >
> > We have properties like: P21 had general purpose (was purpose of) which
> > is very useful for when the data curator only has generic knowledge
> > knowledge and not particular knowledge regarding purpose. This seems a
> > parallel to this case.
> >
> > Anybody else have this case and have an interest in a property like 'had
> > general outcome' or 'had outcome of type' that goes from Event to a
> > Type? Or, better yet if possible, a solution that doesn't involve a new
> > property but that does meet this semantic need without too many
> contortions?
> >
> > 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
>
___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

Re: [Crm-sig] About ... entity of Type?

[George Bruseker via Crm-sig]

better phrasing, 'about a particular thing that is known categorically'

Eg Sales Record about 'Sale Event'



On Tue, Dec 14, 2021 at 6:53 PM George Bruseker 
wrote:

> Dear all,
>
> Recently work is on-going on a new property 'represents thing of type'
> which is distinct from 'represents' (again that particular vs categorical
> distinction).
>
> https://cidoc-crm.org/Issue/ID-476-pxx-represents-entity-of-type
>
> I am confronted with cases of an information object being about not a
> particular thing but a category of thing... in my case event types but I
> guess it could be object types. Of course the existing 'about' property is
> sufficient but it doesn't allow to differentiate that it is not just a type
> but about an as yet unknown X which was of type Y... It seems to me similar
> to the other new property we are working on already.
>
> Does anybody else have cases like this? Any interest in a new parallel
> property like that OR a solution that requires no new properties but also
> doesn't require semantic back flips to understand?
>
> Best,
>
> George
>
___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

[Crm-sig] About ... entity of Type?

[George Bruseker via Crm-sig]

Dear all,

Recently work is on-going on a new property 'represents thing of type'
which is distinct from 'represents' (again that particular vs categorical
distinction).

https://cidoc-crm.org/Issue/ID-476-pxx-represents-entity-of-type

I am confronted with cases of an information object being about not a
particular thing but a category of thing... in my case event types but I
guess it could be object types. Of course the existing 'about' property is
sufficient but it doesn't allow to differentiate that it is not just a type
but about an as yet unknown X which was of type Y... It seems to me similar
to the other new property we are working on already.

Does anybody else have cases like this? Any interest in a new parallel
property like that OR a solution that requires no new properties but also
doesn't require semantic back flips to understand?

Best,

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

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

[George Bruseker via Crm-sig]

Hi all,

I have situations in which I have events where the data curators describe
events for which they have generic knowledge of the outcome: sold,
completed, incomplete, this sort of thing. So there is knowledge but it is
not knowledge of the particular next event but of a general kind of outcome.

We have properties like: P21 had general purpose (was purpose of) which is
very useful for when the data curator only has generic knowledge knowledge
and not particular knowledge regarding purpose. This seems a parallel to
this case.

Anybody else have this case and have an interest in a property like 'had
general outcome' or 'had outcome of type' that goes from Event to a Type?
Or, better yet if possible, a solution that doesn't involve a new property
but that does meet this semantic need without too many contortions?

Best,

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

Re: [Crm-sig] PLEASE VOTE: New Member.

[George Bruseker via Crm-sig]

yes

On Mon, Nov 29, 2021 at 12:37 PM Donatella Fiorani via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Yes
>
> Il giorno sab 27 nov 2021 alle ore 21:29 Martin Doerr via Crm-sig <
> crm-sig@ics.forth.gr> ha scritto:
>
>> Dear All,
>>
>> It is a great pleasure and honor for us to announce that the Palace
>> Museum in Beijing applies for CRM-SIG membership.
>>
>> I have received the following request from the Museum:
>>
>> "The Palace Museum would like to apply for the CRM-SIG membership. Ye
>> Yipei, who is now already attending the CRM-SIG meetings informally,
>> would be the Museum's representative. She is now also formally a CIDOC
>> member. We would be honored to have the opportunity to learn from and
>> work with the experts and colleagues from the CRM-SIG".
>>
>> PLEASE VOTE  "YES" if you support the new member,
>>
>> no, if not,
>>
>> by Dec. 10, 2021.
>>
>> 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
>>
>
>
> --
> prof. arch. Donatella Fiorani
> Ordinario di Restauro Architettonico
> 'Sapienza' Università di Roma
> Dipartimento di Storia, Disegno e Restauro dell'Architettura
>
> ___
> 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] Moving Next SIG (8-11/2/2022) Back to Zoom / Online

[George Bruseker via Crm-sig]

Dear all,

On behalf of the CRM SIG, I am sorry to announce that our intention to hold
the next meeting (Feb 8-11, 2022) in person in Heraklion, Crete, hosted by
the Centre for Cultural Informatics at ICS-FORTH, will not go ahead as
planned.

Given the present covid circumstances in Greece, Europe and the world in
general, it seems our desire to meet in person is once again thwarted by
the reality that the pandemic continues unabated. This reality must be
respected.

Thankfully, we continue to have the support of the University of Oslo,
Faculty of Arts, Unit for Digital Documention, who will once again provide
us with a Zoom platform from which to move our collective work forward.
This also has the advantage of making the meeting more accessible across
the globe.

Thanks for your understanding. Look forward to see you all on Zoom, in
February, 2022.

Sincerely,

George Bruseker
Co-Chair CIDOC CRM SIG
___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

[Crm-sig] CIDOC CRM Game - Digital Edition

[George Bruseker via Crm-sig]

Dear all,

It is a pleasure to announce the release of the CIDOC CRM Game - Digital
Edition to the public. The aim of this game is to support the teaching and
learning of formal ontologies in general and the CIDOC CRM in particular.

The CIDOC CRM Game - Digital Edition is a single player card game divided
into different learning challenges. It aims to allow the player to explore
the world of formal ontologies and CIDOC CRM while testing their knowledge
and skills in semantic data as they go along.

This edition of the CIDOC CRM Game was made possible through the funding of
Mémoires des archéologues et des sites archéologiques (MASA), a consortium
from the french research infrastructure Huma-Num. It is the joint outcome
of the efforts of the following individuals and institutions (learn more in
the credits of the game):

George Bruseker (Takin.solutions)
Anais Guillem (UC Merced)
Olivier Marlet (MASA)
François-Xavier Talgorn (Indytion)

This edition of the game uses the case study of the excavations at
Marmoutiers abbey in Tours. The game platform, designed in Unity, has been
created as a means to generate further digital editions of the game over
time with different case studies and different content. Having been
developed as a game to support particularly the understanding of the CIDOC
CRM, creating new versions of this game for that ontology is a particularly
simple process.

The game is available for download at:

http://www.cidoc-crm-game.org/node/39

It is our sincere hope that this game will prove a useful starting point
for teaching and learning ontologies. We are very open to collaborations to
carry this concept forward in different environments in the future.

Sincerely,

George Bruseker on Behalf of the CIDOC CRM Game - Digital Edition team
___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

[Crm-sig] CRMSci O19 Property Labels Minor Correction?

[George Bruseker via 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

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

[George Bruseker via Crm-sig]

Hi Athina!

What causes the bird to go from a to b, I guess is the simplest way to put
it. Does it just happen? Is the bird just present in the event of its
migration?

G

On Tue, Oct 12, 2021 at 11:22 AM athinak  wrote:

> Hello,
>
> I am probably missing something here, but regarding these databases, in
> which cases these animals are documented as actors? It seems that there
> are documentations about births and traps and capturing events, but the
> discussion is about activities carried out by them, right? From my
> experience with gbif and darwincore, which a standard that is widely
> used for biodiversity databases, haven't seen definitions of this kind
> of relationships, but  maybe I am missing things
> or I misunderstood something
>
> BRs
> Athina
>
>   Στις 2021-10-12 10:02, George Bruseker via Crm-sig έγραψε:
> > Hi all,
> >
> > Here are some examples of databases that deal with individual or
> > collectivites of animals NOT as THINGS but as AGENTS:
> >
> > EMU: Pest Tracking in Museums
> >
> >
> http://help.emu.axiell.com/v6.4/en/Topics/EMu/Traps%20and%20Pest%20Events%20modules.htm
> >
> > Here's a database that tracks the migratory paths of individual birds:
> >
> > https://nationalzoo.si.edu/migratory-birds/migratory-birds-tracking-map
> >
> > Here's a database that tracks orcas:
> >
> > https://theorcaproject.wordpress.com/killer-whale-orca-database/
> >
> > Here's a database that tracks gorillas:
> >
> > https://www.gorillasland.com/la-plaine-zoo.php
> >
> > I would say that often something doesn't get documented because it is
> > silenced by the information systems available (see the terrible
> > gorilla database), arguably what CIDOC CRM is supposed to aid in
> > getting out of (viz. Dominic's textual works issue and documenting
> > context). The fact that people are forced to shoehorn identifiable
> > individuals that they want to document and have discourse about into
> > classes that do not suit them is for me the obvious argument for
> > making classes and properties!
> >
> > Whether there are explicit fields for such data, the natural world is
> > something which unsurprisingly Cultural Heritage is interested in and
> > refers to. Orcas are, for example, highly important animals within
> > different cultural systems in Canada, they are documented and they are
> > documented not as things but as agents. So what is the pressing
> > counter point to allowing this expressivity? That there are too many
> > classes and properties. Many would make that argument about CRMinf or
> > about any of our extensions. I suppose it depends on where you
> > interest lies. By not opening these categories we effectively
> > mute/suppress this voice. Because the limits of the world are my
> > language when we choose to oppress a class we choose to oppress the
> > ability to express that object. Or we indeed force the documentation
> > of things that are considered agents as objects. This seems the
> > greater harm to my mind.
> >
> > On the expertise question, 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 

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

[George Bruseker via Crm-sig]

Hi Martin,

I'm also pressed for time but above wrote out an argument.

Best,
George

On Tue, Oct 12, 2021 at 10:17 AM Martin Doerr  wrote:

> Hi George,
>
> I'd prefer to let the biologists talk about that. To my best knowledge
> of real cases, this is a much debated question. For the time being, I am
> sorry I have no time to provide details.
>
> All the best,
>
> Martin
>
>
> On 10/12/2021 10:02 AM, George Bruseker wrote:
> > On the expertise question, I am not sure if we required a biologist to
> > be able to model the notion of Birth or Death.
>
>
> --
> 
>   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

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

[George Bruseker via Crm-sig]

 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
>
> pat.r...@concordia.ca
>
> --
> *From:* Robert Sanderson 
> *Sent:* October 11, 2021 5:16 PM
> *To:* Pat Riva 
> *Cc:* Martin Doerr ; George Bruseker <
> george.bruse...@gmail.com>; crm-sig@ics.forth.gr 
> *Subject:* Re: [Crm-sig] New Issue: Non-human Actors
>
>
> Attention This email originates from outside the concordia.ca domain. //
> Ce courriel provient de l'exterieur du domaine de concordia.ca
>
>
>
>
> Hi Pat,
>
> While that is certainly true from a model-theoretic perspective, in
> practice authorities simply create Persons for them which is, in my
> opinion, even worse because there is a demonstrated need which the modeling
> is intentionally preventing.
>
> For example in the Library of Congress:
> Real animal/people:
>   Lassie: https://id.loc.gov/authorities/names/nb2015016669.html
> <https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fid.loc.gov%2Fauthorities%2Fnames%2Fnb2015016669.html=04%7C01%7Cpat.riva%40concordia.ca%7Cc79309f39b794e1f071208d98cfc5da8%7C5569f185d22f4e139850ce5b1abcd2e8%7C0%7C0%7C637695838963964170%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=hdNSl4RqY9oAtWoVxSp3xl9fCc21yLNCKsHF8lEspgs%3D=0>
>
>   Misha the Dolphin: https://id.loc.gov/rwo/agents/nb2017006372.html
> <https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fid.loc.gov%2Frwo%2Fagents%2Fnb2017006372.html=04%7C01%7Cpat.riva%40concordia.ca%7Cc79309f39b794e1f071208d98cfc5da8%7C5569f185d22f4e139850ce5b1abcd2e8%7C0%7C0%7C637695838963964170%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=0rU8nimUcSQsX0qHQI7H94Hs4w3ssLoOLPIB6fQdwBE%3D=0>
>
> And fictitious:
>   Odie (from Garfield):
> https://id.loc.gov/authorities/names/no2017122131.html
> <https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fid.loc.gov%2Fauthorities%2Fnames%2Fno2017122131.html=04%7C01%7Cpat.riva%40concordia.ca%7Cc79309f39b794e1f071208d98cfc5da8%7C5569f185d22f4e139850ce5b1abcd2e8%7C0%7C0%7C637695838963974165%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=QEy5XUWLQMwdpq9prYdI14FzZlkBkHvWmHIUrph%2FeQo%3D=0>
>   Grumpy Cat: https://id.loc.gov/rwo/agents/n2013036964.html
> <https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fid.loc.gov%2Frwo%2Fagents%2Fn2013036964.html=04%7C01%7Cpat.riva%40concordia.ca%7Cc79309f39b794e1f071208d98cfc5da8%7C5569f185d22f4e139850ce5b1abcd2e8%7C0%7C0%7C637695838963974165%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=LKk%2BIU6%2B1hjIcYA9lP%2F2cGVSF%2BhegeziH4ifUrOmcz8%3D=0>
>
>
> In ULAN, here's a racehorse/person:
>
> https://www.getty.edu/vow/ULANFullDisplay?find500353456
> <https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.getty.edu%2Fvow%2FULANFullDisplay%3Ffind%3D%26role%3D%26nation%3D%26subjectid%3D500353456=04%7C01%7Cpat.riva%40concordia.ca%7Cc79309f39b794e1f071208d98cfc5da8%7C5569f185d22f4e139850ce5b1abcd2e8%7C0%7C0%7C637695838963984159%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=uq7x%2FB9sMhI%2Ba5WIBaE%2FYIZ1JqKCDROMhsE%2FqTHIl34%3D=0>
>
>
> ISNI has a dog/person called Maggie Mayhem:
> https://isni.org/isni/
> <https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fisni.org%2Fisni%2F=04%7C01%7Cpat.riva%40concordia.ca%7Cc79309f39b794e1f071208d98cfc5da8%7C5569f185d22f4e139850ce5b1abcd2e8%7C0%7C0%7C637695838963984159%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=kA1elOx%2BnZrSK8z8AkvhabyJQfHsRUAY%2FpP53dqgvfI%3D=0>
> 000497302960
>
> And so on.
>
> Rob
>
>
> On Mon, Oct 11, 2021 at 4:50 PM Pat Riva via Crm-sig 
> wrote:
>
> Just to remark that the library world discussed non-human actors for many
> years (in the literal sense of actor as in the dogs that portrayed Lassie
> in the TV series, or that portrayed Sykes and Paddy from Midsomer Murders,
> somehow it is always cute dogs that are brought up in the discussion).
>
> The desire 

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

[George Bruseker via Crm-sig]

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 general class that subsumes the agency of purely
>> human actors and biological agents. This would be our top class. Here we
>> come up with a more general notion of agency. Whereas E39 Actor was
>> declared in order to account for a 'legal persons notion' of agency common
>> to Western legal systems etc. (and is perfectly adequate for the scope of
>> CRM Base), this would be a broader notion of agency.
>>
>> In order to avoid impossible philosophical arguments around self
>> consciousness, we can give a more externalist scope note / intension to
>> this class. Agency has to do with those entities which display self
>> organization and action towards an end from an external perspective. This
>> way we avoid having to know if the other really has a self. If it looks
>> like it is acting intentionally and people document it as such, then so it
>> is.
>>
>> This now gives us a super class (and eventually super properties) for all
>> agents.
>>
>> But wait... we need more.
>>
>> CRMBase distinguishes between persons and groups. Whereas persons must
>> have both agency and be individuated corporeal beings, groups do not.
>> Persons are atomic and irreducible (can't be made up of more persons, can't
>> be spread over multiple bodies / time zones). Groups are composed of
>> persons and groups. Groups are inherently collective.
>>
>> If we wish then to have this same distinction reflected into the
>> biological domain we would need a class for individual biological agents
>> parallel / sibling to person and a class for collective bi

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

[George Bruseker via Crm-sig]

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 general class that subsumes the agency of purely human
actors and biological agents. This would be our top class. Here we come up
with a more general notion of agency. Whereas E39 Actor was declared in
order to account for a 'legal persons notion' of agency common to Western
legal systems etc. (and is perfectly adequate for the scope of CRM Base),
this would be a broader notion of agency.

In order to avoid impossible philosophical arguments around self
consciousness, we can give a more externalist scope note / intension to
this class. Agency has to do with those entities which display self
organization and action towards an end from an external perspective. This
way we avoid having to know if the other really has a self. If it looks
like it is acting intentionally and people document it as such, then so it
is.

This now gives us a super class (and eventually super properties) for all
agents.

But wait... we need more.

CRMBase distinguishes between persons and groups. Whereas persons must have
both agency and be individuated corporeal beings, groups do not. Persons
are atomic and irreducible (can't be made up of more persons, can't be
spread over multiple bodies / time zones). Groups are composed of persons
and groups. Groups are inherently collective.

If we wish then to have this same distinction reflected into the biological
domain we would need a class for individual biological agents parallel /
sibling to person and a class for collective biological agents, parallel /
sibling to group.

Doing this one would then need the superclasses to subsume these divisions.
Hence:

Individual Agent: subclass of Agent, superclass of individual biological
agent

Collective Agent: subclass of Agent, superclass of collective biological
agent and human group

This finally allows us to have:

Individual Biological Agent: subclass of Biological Agent and Individual
Agent: used for individual birds, trees, and other biological actors

Collective Biological Agent: subclass of Biological Agent and Collective
Agent: used for flocks, forests and other group biological actors (unlike
human groups, such groups are inherently corporeal)

And at that point we might consider renaming our existing classes to
'human' xxx

So

E39 Human Agent: subclass of agent, no real change in intension, the kind
of entity that can take action for which legal responsibility can be
attributed within human cultures societies

E21 Human Person: no real change in intension but its superclass becomes
individual biological agent and human agent (ie an animal that can be held
legallly responsible for its actions)

E74 Group no real change in intension, but it gains a super class
Collective Agent so it can be queried together with other agent groups.

This analysis does not get into the properties which are, of course,
fundamental but sketches a possible path for creating the structure
necessary to create this extension of scope in such a way that it would
respect the principle of monotonicity in revising the model while allowing
the growth of the model to handle the many use cases of