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

[Martin Doerr via Crm-sig]

Dear Francesco, dear Gordon,

Thank you very much!

It also appears to me that a large part of the semantics we are 
discussing is property of the relation between a particular and a name 
and not the name. The LRM Nomen has consequently modelled LRMoo,

as

 "F12 Nomen
Subclass of: E89 Propositional Object
Scope note: This class comprises associations between an instance of any 
class, and signs or arrangements of

signs that are used to refer to and identify that instance."

You both confirm this in different ways. I had been talking about a 
property of P1 is identified by, Francesco about the Name use, all 
variants of the same pattern. I think we should floow this thought.


By the way, I am working in methodology ontology engineering 30 years, 
and obviously would never propose to decide instances. Don't know, how I 
could be interpreted that way.


The ontologist must provide a definition of the "intension" of a class 
or property. This definition, be it appealing to common sense or in 
terms of logical rules or anything in between, must enable domain 
experts with a *reasonable precision* to decide on a justifiable base, 
if an instance belongs to the concept yes or no. This should approximate 
at least some professional practice. A "fuzzy zone" or area of 
undecidable instances *always* exists. In CRM-SIG, we always explore 
this by examples. If, e.g. for *an arbitrary name* there are no limits 
to any expert to which language it may belong, it demonstrates a 
weakness of the concept. In this case, we seek to understand all 
possible similar senses, to find out if the intuitive concept actually 
hides a quite substantial concept of different logic.


So, of course, as ontologists we must understand examples, or find a 
large enough group of experts that are able to understand them, but we 
define intensions. Should have been obvious


And yes, why shouldn't Zolotas speak a Greek-English mix? Obviously, it 
is neither German nor Chinese nor Arabic...that would not challege P72, 
since Quantification is not unique, and many European languages are not 
so alien to each other.


All the best,

Martin

On 11/13/2022 11:11 AM, George Bruseker via Crm-sig wrote:
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, 
 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 

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

[Francesco Beretta via Crm-sig]

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

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

[Gordon Dunsire via Crm-sig]

 
 
   
   
All

   
 

   
Back to the language characteristics of names and titles ...

   
 

   
First, to recap more detail about the LRMer and RDA treatment of 'names'.

   
 

   
The LRMer uses the class Nomen, defined as "An association between an entity and a designation that refers to it". All instances of the class are reifications of the statement "This instance of an entity has an appellation that is this designation". The designation is known as a 'nomen string', and it is the datatype object of the property LRM-R13 "has appellation". The property declares a range of Nomen, so an instance of nomen is an object type object of the property. The reification is used to distinguish instances of the same designator being assigned to multiple instances of one entity or multiple entities.

   
 

   
RDA implements Nomen and "has appellation" by distinguishing three categories of designation/appellation: name/title; access point, identifier. RDA does not treat an IRI as a nomen; that is, all appellations are strings, and a nomen IRI is a "thing". RDA adds sub-properties of LRM-R13 that are specific to these categories, but does not sub-class Nomen. The ontological distinction of the categories lies in the kind of agent/actor who assigns the designation/appellation, the syntax of the nomen string, and the context of its application in bibliographic metadata. A name/title is assigned by a creator of an information resource in the syntax of common discourse and the context of promoting the resource to its user; an access point is assigned by a creator of metadata for the resource and instances of associated entities in the syntax of a 'string encoding scheme', 'authority file', etc. and the context of collocating the instances in an ordered list; an identifier is assigned by a creator of metadata for instances of any entity in the syntax of an identifier assignment scheme that is typically mediated through an algorithm and the context of direct access to the resource when the identifier is known.

   
 

   
RDA does not expect an identifier to be based on language or translatable; the relationship between two identifiers for the same entity is a 'mapping', not a translation. [RDA does not forbid this; two identifiers that are based on a name or title that is translated might be considered to be translated themselves. This often occurs in official publications of multi-lingual governments.]

   
 

   
RDA does not expect an access point to be translated. The component strings of two access points for the same instance may be different language versions, but they are assembled into the structured strings of each access point by applying the same string encoding scheme; the result is two distinct access points, not a translation of one access point into another. This is illustrated by VIAF (Virtual International Authority File) which labels individual access points by assigning agency, not language. [Again, this is not forbidden in RDA.]

   
 

   
RDA expects titles of manifestations to be translated. Some manifestations bear statements of title, responsible agents, and other associated entities such as place of publication in multiple languages and scripts ("parallel statements") but is rare for names of persons to be 'translated'. Some manifestations are subsequent translations of an existing manifestation, and it less rare for names of persons and other entities to be 'translated' with local versions.

   
 

   
RDA does not generally expect names of persons to be translated. An exception is a name that includes an epithet, such as "Thomas the Rhymer" (although VIAF has no 'translated' version).

   
A quick Google search does not reveal a translation of "The Big Apple", so I guess that translation of names (of agents, places, etc.) that include epithets is unusual. There is an interesting article on translating geographic names, aptly entitled "Navigating through treacherous waters" (https://translationjournal.net/journal/28names.htm).

   
 

   
RDA expects all designation/appellations to be transliterated.

   
 

   
To answer Martin's questions:

   
 

   
A) In library practice, do you associate a name with a language, and what would be the rules.

   
 

   
GD: Yes. The LRM and RDA provide a property for language of a nomen. The LRM defines this in the context of the scheme to which the nomen belongs; that is, the language covered by the assigning agent. The RDA property does not provide semantics that add to its title "has language of nomen" or specific options for its use, because the 'waters are treacherous'.

   
 

   
Can transliteration to another script change and produce a language-specificity?

   
 

   
GD: I don't think so.

   
 
  

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  in Hebrew
>> written in Latin script? If this is the case, they are variants shaped and
>> used in different language groups. That would justify a
>> language-specificity.
>>
>> B) If the meaning of the language property we are seeking for is not the
>> language of the name, but the suitable use in a language group of the name
>> for the named instance, then, it is a subproperty of P1 and not P72. Such
>> as "is typically identified in English by...etc. That *is *an
>> ontological question.
>>
>> All the best,
>>
>> Martin
>>
>> On 11/10/2022 1:21 PM, Gordon Dunsire wrote:
>>
>> All
>>
>> A librarian expresses an initial opinion:
>>
>> What about gender of a name? E.g. "Gordon" is male; "Gordana" is female.
>> The Library of Congress has only recently stopped assigning gender to the
>> referant of a name, which has resulted in howlers like "Robert Galbraith"
>> (pseudonym of J.K. Rowling) is a male because the name is 'male'.
>>
>> RDA: resource description and access is an implementation of the IFLA
>> Library Reference Model (entity-relationship version). Names and titles are
>> given equal treatment; the only difference between a 'name' and a 'title'
>> is that 'title' is the traditional word for the 'name' of an information
>> resource. Since LRM/RDA has four 'resource entities', we have 'title of
>> work', 'title of expression', 'title of manifestation', and 'title of
>> item'; all other entities have 'name": 'name of place', 'name of
>> time-span', 'name of agent', etc.
>>
>> This discussion exposes a further difference, but it is not absolute. A
>> 'title' is usually composed of words, etc. taken from a natural language:
>> "Ceci n'est pas une pipe" uses French words; "The treachery of images" uses
>> English words; "La trahison des images" is back to French; "The wind and
>> the song" is back to English ... On the other hand, a 'name' is usually
>> composed of words, etc. that have no other use in natural language. But
>> there are many counter-examples, and the distinction may not exist in a
>> specific language group (e.g. Chinese?).
>>
>> Although RDA has a property for 'has language of nomen' ('nomen' being
>> the generic term for 'name/title', 'access point', and 'identifier'), the
>> expectation is that it only has utility for 'title', but not 'name'.
>>
>> The sibling property 'has script of nomen' has utility for names and
>> titles. It is important for transliterations.
>>
>> On 09/11/2022 20:02 GMT George Bruseker via Crm-sig
>>   wrote:
>>
>>
>> Dear Martin,
>>
>> I don't see an ontological problem here. One name can be 

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

[Martin Doerr via Crm-sig]

Hi Robert,

No questions the existence of names with a language. I do not remember 
doing that.


I simply try, as often, to teach the group principles.

The scope note for E41 explicitly says:

"Different languages may use different appellations for the same thing, 
such as the names of major cities. Some appellations may be formulated 
*using a valid noun phrase of a particular language*. In these cases, 
the respective instances of E41 Appellation should also be declared as 
instances of E33 Linguistic Object. Then the language using the 
appellation can be declared with the property /P72 has language/: E56 
Language."


May be it is not clear, *what *I am discussing.

*As long *as on the application side, we declare E41_E33 , it is still 
up to the user to decide which sense of linguistic object we apply.


*If* the proposal is to *introduce a new Multiple IsA class* into 
CRMbase, all good practice requires *to write a scope note* and to 
clarify in which sense it is a linguistic object and the property P72 is 
applied. The class instance itself is then associated with the property, 
and not its incidental use.


This is a general ontological principle we apply, sine qua non. If we 
ignore that, we would further create a conflict with P139:


"This property should not be confused with additional variants of names 
used characteristically for a single, particular item, such as 
individual nicknames. It is a directed relationship, where the range 
expresses the derivative or variant and the domain the source of 
derivation or original form of variation, if such a direction can be 
established. "


That was my comment below.

What is your opinion, does anything prevent any name to be used in any 
language?


Therefore, I follow the usual discourse to help identifying ontological 
distinctions.
For instance, https://www.behindthename.com/name/joshua provides 
languages to name variants. This use should definitely be included if we 
decide a new class for CRMbase.


If we decide to include in P72  also a "made for" , or 
"characteristically used by" for E41-E33, we have to describe that. If 
we decide against, we have to decide that. If we are not able to decide, 
we leave the application in the RDFS as is, because it is not mature for 
ontological standardization at an international level, but resolved 
application-wise.


I asked for Farsi, because to my best knowledge, Iran uses the Arabic 
script. Therefore a transcription of Douglas Adams to Arabic script 
equally applies to Farsi and Arabic. As such, it would not be "Arabic".


I hope that makes my reasoning clearer.

All the best,

Martin

On 11/10/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 
 wrote:


Dear Gordon,

"The Library of Congress has only recently stopped assigning
gender to the referant of a name",

That is interesting!

I'd kindly ask for your expert opinion, about the "language" of a
name.

We had introduced the language property of a title because of the
frequent cases of words of a natural language and their translations.

Here, my question is:

A) In library practice, do you associate a name with a language,
and what would be the rules.

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

I absolutely disagree with that. Can transliteration to another
script change and produce a language-specificity? That is
definitely an ontological question. Otherwise, we have no concept
at all for this property.

My example of Joshua had another purpose: The spelling and
pronunciation "Josua" is the one used in German, but not
exclusively. "Joshua" in English (and?), may be Yeshua
 in Hebrew written in Latin
script? If this is the case, they are variants shaped and used in
different language groups. That would justify a language-specificity.

B) If the meaning of the language property we are seeking for is
not the language of the name, but the suitable use in a language
group of the name for the named instance, then, it is a
subproperty of P1 and not P72. Such as "is typically identified in
English by...etc. That *is *an ontological question.

All the best,

Martin

On 11/10/2022 1:21 PM, Gordon 

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

[Robert Sanderson via Crm-sig]

Hi Martin,

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

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

Rob


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

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

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

[Martin Doerr via Crm-sig]

Dear Gordon,

"The Library of Congress has only recently stopped assigning gender to 
the referant of a name",


That is interesting!

I'd kindly ask for your expert opinion, about the "language" of a name.

We had introduced the language property of a title because of the 
frequent cases of words of a natural language and their translations.


Here, my question is:

A) In library practice, do you associate a name with a language, and 
what would be the rules.


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


I absolutely disagree with that. Can transliteration to another script 
change and produce a language-specificity? That is definitely an 
ontological question. Otherwise, we have no concept at all for this 
property.


My example of Joshua had another purpose: The spelling and pronunciation 
"Josua" is the one used in German, but not exclusively. "Joshua" in 
English (and?), may be Yeshua  in 
Hebrew written in Latin script? If this is the case, they are variants 
shaped and used in different language groups. That would justify a 
language-specificity.


B) If the meaning of the language property we are seeking for is not the 
language of the name, but the suitable use in a language group of the 
name for the named instance, then, it is a subproperty of P1 and not 
P72. Such as "is typically identified in English by...etc. That *is *an 
ontological question.


All the best,

Martin

On 11/10/2022 1:21 PM, Gordon Dunsire wrote:

All
A librarian expresses an initial opinion:
What about gender of a name? E.g. "Gordon" is male; "Gordana" is 
female. The Library of Congress has only recently stopped assigning 
gender to the referant of a name, which has resulted in howlers like 
"Robert Galbraith" (pseudonym of J.K. Rowling) is a male because the 
name is 'male'.
RDA: resource description and access is an implementation of the IFLA 
Library Reference Model (entity-relationship version). Names and 
titles are given equal treatment; the only difference between a 'name' 
and a 'title' is that 'title' is the traditional word for the 'name' 
of an information resource. Since LRM/RDA has four 'resource 
entities', we have 'title of work', 'title of expression', 'title of 
manifestation', and 'title of item'; all other entities have 'name": 
'name of place', 'name of time-span', 'name of agent', etc.
This discussion exposes a further difference, but it is not absolute. 
A 'title' is usually composed of words, etc. taken from a natural 
language: "Ceci n'est pas une pipe" uses French words; "The treachery 
of images" uses English words; "La trahison des images" is back to 
French; "The wind and the song" is back to English ... On the other 
hand, a 'name' is usually composed of words, etc. that have no other 
use in natural language. But there are many counter-examples, and the 
distinction may not exist in a specific language group (e.g. Chinese?).
Although RDA has a property for 'has language of nomen' ('nomen' being 
the generic term for 'name/title', 'access point', and 'identifier'), 
the expectation is that it only has utility for 'title', but not 'name'.
The sibling property 'has script of nomen' has utility for names and 
titles. It is important for transliterations.
On 09/11/2022 20:02 GMT George Bruseker via Crm-sig 
 wrote:

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



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

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




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

Who documents the object, documents their knowledge and, hopefully, 
thereby, the state of affairs in the world.
I don't understand the Farsi aspect of the above question. 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 

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

[Gordon Dunsire via Crm-sig]

 
 
  
   All
   
  
    
   
   
   
A librarian expresses an initial opinion:

   
 

   
What about gender of a name? E.g. "Gordon" is male; "Gordana" is female. The Library of Congress has only recently stopped assigning gender to the referant of a name, which has resulted in howlers like "Robert Galbraith" (pseudonym of J.K. Rowling) is a male because the name is 'male'.

   
 

   
RDA: resource description and access is an implementation of the IFLA Library Reference Model (entity-relationship version). Names and titles are given equal treatment; the only difference between a 'name' and a 'title' is that 'title' is the traditional word for the 'name' of an information resource. Since LRM/RDA has four 'resource entities', we have 'title of work', 'title of _expression_', 'title of manifestation', and 'title of item'; all other entities have 'name": 'name of place', 'name of time-span', 'name of agent', etc.

   
 

   
This discussion exposes a further difference, but it is not absolute. A 'title' is usually composed of words, etc. taken from a natural language: "Ceci n'est pas une pipe" uses French words; "The treachery of images" uses English words; "La trahison des images" is back to French; "The wind and the song" is back to English ... On the other hand, a 'name' is usually composed of words, etc. that have no other use in natural language. But there are many counter-examples, and the distinction may not exist in a specific language group (e.g. Chinese?).

   
 

   
Although RDA has a property for 'has language of nomen' ('nomen' being the generic term for 'name/title', 'access point', and 'identifier'), the expectation is that it only has utility for 'title', but not 'name'.

   
 

   
The sibling property 'has script of nomen' has utility for names and titles. It is important for transliterations.

   
   
   
On 09/11/2022 20:02 GMT George Bruseker via Crm-sig  wrote:

   
 

   
 



 Dear Martin, 
 
   
  
 
  I don't see an ontological problem here. One name can be used by / in many languages. If it is, that can be documented.
  
 
   
  
 
 
  
  
   The question was not if names can belong to language, or if langauges create names. It was how this is unambiguously defined.
   
  
 
   
  
 
  It isn't our job as ontologists to unambiguously define the instances of things in the world. This is for the domain specialists.
  
 
   
  
  
  
   
   The example below is what I feared. The fact that the arabic script is mainly used for Arabic, does itr make a transcript of an English name "Arabic?" why not Farsi?  I ask here for the Librarians to express their opinion.
   
  
 
   
  
 
  Who documents the object, documents their knowledge and, hopefully, thereby, the state of affairs in the world. 
  
 
   
  
 
  I don't understand the Farsi aspect of the above question. 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?
 

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

[Robert Sanderson via Crm-sig]

Unsurprisingly, I agree with George.

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

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

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

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

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

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

Rob


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

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

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

[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

[Martin Doerr via Crm-sig]

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



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



--

 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] 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 criteria because they
>>> > don't have properties ), such as Inscription, we should make an issue
>>> > not to delete, but to discuss the alternatives of removing this class
>>> > and maybe to remember the initial purpose of use of this class or to
>>> > find if there is an open issue regarding this - For E34, there is the
>>> > issue 533; So, my question is: what about the classes that we have
>>> > introduced in CRM base or in other compatible models, such as S7
>>> > Simulation or S5 in sci, which have no properties at all, but, as I
>>> > remember very well, the argument for introducing them (I am speaking
>>> > for sci) was that that they are domain specific but we haven't yet
>>> > developed them, but we intend to do so in future. - 

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 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 criteria because they
>> > don't have properties ), such as Inscription, we should make an issue
>> > not to delete, but to discuss the alternatives of removing this class
>> > and maybe to remember the initial purpose of use of this class or to
>> > find if there is an open issue regarding this - For E34, there is the
>> > issue 533; So, my question is: what about the classes that we have
>> > introduced in CRM base or in other compatible models, such as S7
>> > Simulation or S5 in sci, which have no properties at all, but, as I
>> > remember very well, the argument for introducing them (I am speaking
>> > for sci) was that that they are domain specific but we haven't yet
>> > developed them, but we intend to do so in future. - should we delete
>> > them? E34 has not been developed, in my understanding, and it is now
>> > replaced by CRM tex. So the issue , in my opinion, should be (for this
>> > class)  how we sychronize and not delete.
>> >
>> > BRs,
>> >
>> > Athina
>> >
>> > On 2022-11-08 23:25, Mark Fichtner via Crm-sig wrote:
>> >> Dear all,
>> >>
>> >> while I must agree with Rob that the three classes he proposed for
>> >> deletion are not a particular best pratice in ontology building from a
>> >> semantic point of view, I don't feel good with the direction the CRM
>> >> is going currently. At our museum we are following the CRM because it
>> >> is the only "really standardized" standard for our domain. It is
>> >> expressive 

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

[Robert Sanderson via Crm-sig]

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

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

For example,

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

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

Or:

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

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

Rob

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

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

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

[Martin Doerr via Crm-sig]

Dear All,

I would like to focus on the semantic questions wrt E33_E41. Would it be 
well defined? Please remember, that there were implementation arguments 
against multiple instantiation, not semantic ones. Therefore, we decided 
to solve the problem in the implementation side. Why the unlucky choice 
of two different labels now would warrent a deeper semantics is not 
clear to me. We can solve the issue by deciding a label.


If there are possibly deeper semantics, as I indicated in my last 
message, could we specify this?


Is the language of an E33_E41 a created within, made for, used by? Is it 
language or language speakers? What substance makes an Appellation 
"languageable"?


Can someone take a position? If this stays unclear, I vote for the 
current solution.


Cheers,

Martin

On 11/9/2022 10:46 AM, athinak via Crm-sig wrote:

Dear all,

I fully agree that we must follow the principles of the ontology 
development and remove classes that do not fulfil the criteria of 
being classes in CRM Base. But, in my opinion, for specific classes of 
this kind (that they seem not to fulfill the criteria because they 
don't have properties ), such as Inscription, we should make an issue 
not to delete, but to discuss the alternatives of removing this class 
and maybe to remember the initial purpose of use of this class or to 
find if there is an open issue regarding this - For E34, there is the 
issue 533; So, my question is: what about the classes that we have 
introduced in CRM base or in other compatible models, such as S7 
Simulation or S5 in sci, which have no properties at all, but, as I 
remember very well, the argument for introducing them (I am speaking 
for sci) was that that they are domain specific but we haven't yet 
developed them, but we intend to do so in future. - should we delete 
them? E34 has not been developed, in my understanding, and it is now 
replaced by CRM tex. So the issue , in my opinion, should be (for this 
class)  how we sychronize and not delete.


BRs,

Athina

On 2022-11-08 23:25, Mark Fichtner via Crm-sig wrote:

Dear all,

while I must agree with Rob that the three classes he proposed for
deletion are not a particular best pratice in ontology building from a
semantic point of view, I don't feel good with the direction the CRM
is going currently. At our museum we are following the CRM because it
is the only "really standardized" standard for our domain. It is
expressive enough for a full top level ontology while also covering
the domain of cultural heritage. We are not interested in yet another
standard that maps metadata in a very common way - we have enough of
these and if we would want to use dublin core we would do so. The full
potential of the CRM is what binds us to using it.

Concepts like "Title" are really important for our domain - it is one
of the most important metadata fields for documentation in our museum.
With the abolishment of properties and classes in CRM Base that were
used a lot in the past the SIG and the CRM takes a turn away from the
museum side of documentation towards being a very general ontology.
While I know development may always hurt a little bit, this does not
feel right in any way anymore.

I am asking myself: Is this really what the CIDOC CRM should do? Is it
possible for the CIDOC CRM to survive in comparison to standards that
are more widely spread while abolishing it's own user base? Do we
really want a domain ontology - extending CRM Base called "CRM Museum
Documentation Ontology" because we throw out everything that is museum
related out of CRM Base? 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

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

To my thinking, while intellectually that would be the neatest of
solutions, pragmatically it would be a huge problem not only for system
developers who rely on the continuity of CRM but also socially and
politically in terms of the CRMs embeddedness in the museum community and
its operation within the aegis of ICOM.

CIDOC CRM walks a fine line between being a pure top level ontology and a
domain level ontology which is both a disadvantage because of the kinds of
discussions we have here and now and an advantage, especially in that it
keeps grounded to reality and not in the realm of pure theory where we know
no longer the relation of our modelling to any actual reality.

While of course any sensible proposition should be discussed, I think the
above would be a non-starter as CRM would really be in danger of losing its
identity and its social embeddedness with a community.

A project which abstracted the CRM to pure top level classes
would certainly be most interesting and exciting but also probably better
done in a pure academic environment from which blue sky research, the world
of information management of CH institutions could benefit in the long run.

In the meantime, it's my opinion we have to and have accepted that CRM is
an ontology that has roots in the museum cum CH community and should
continue to maintain its fruitful and stable relation therewith. So we have
to implement our principles such that we are able to grow organically with
that community and its research interests and needs, respectfully listening
and adapting to them, whilst keeping an eye to maintaining the generality
of the ontology as a useful medium for discussing events and their
participants in space time.

Cheers,

George

On Wed, Nov 9, 2022 at 11:51 AM Carlo Meghini via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear Mark, all,
>
> why not, then, have a domain-independent CRM core and an extension for
> museum documentation, perhaps generalized to CRMCH or something like that?
> Apologies if this proposal is already on the table and I missed it.
>
> Modularity at the core would sort out agendas, keeping discussions about
> general questions, like space-time volumes, diachronicity, etcetera, well
> separated from those about titles, information carriers, etcetera. More
> importantly it would allow independent (but harmonized) evolution.
>
> Carlo
> Il 08/11/22 22:25, Mark Fichtner via Crm-sig ha scritto:
>
> 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
>
>
>
> 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 

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

[Carlo Meghini via Crm-sig]

Dear Mark, all,

why not, then, have a domain-independent CRM core and an extension for 
museum documentation, perhaps generalized to CRMCH or something like 
that? Apologies if this proposal is already on the table and I missed it.


Modularity at the core would sort out agendas, keeping discussions about 
general questions, like space-time volumes, diachronicity, etcetera, 
well separated from those about titles, information carriers, etcetera. 
More importantly it would allow independent (but harmonized) evolution.


Carlo

Il 08/11/22 22:25, Mark Fichtner via Crm-sig ha scritto:

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


Am Di., 8. Nov. 2022 um 21:51 Uhr schrieb Robert Sanderson via Crm-sig 
:



Thank you for the clarification, Martin!

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

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

Thanks again,

Rob



On Tue, Nov 8, 2022 at 2:24 PM Martin Doerr via Crm-sig
 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

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

[athinak via Crm-sig]

Dear all,

I fully agree that we must follow the principles of the ontology 
development and remove classes that do not fulfil the criteria of being 
classes in CRM Base. But, in my opinion, for specific classes of this 
kind (that they seem not to fulfill the criteria because they don't have 
properties ), such as Inscription, we should make an issue not to 
delete, but to discuss the alternatives of removing this class and maybe 
to remember the initial purpose of use of this class or to find if there 
is an open issue regarding this - For E34, there is the issue 533; So, 
my question is: what about the classes that we have introduced in CRM 
base or in other compatible models, such as S7 Simulation or S5 in sci, 
which have no properties at all, but, as I remember very well, the 
argument for introducing them (I am speaking for sci) was that that they 
are domain specific but we haven't yet developed them, but we intend to 
do so in future. - should we delete them? E34 has not been developed, in 
my understanding, and it is now replaced by CRM tex. So the issue , in 
my opinion, should be (for this class)  how we sychronize and not 
delete.


BRs,

Athina

On 2022-11-08 23:25, Mark Fichtner via Crm-sig wrote:

Dear all,

while I must agree with Rob that the three classes he proposed for
deletion are not a particular best pratice in ontology building from a
semantic point of view, I don't feel good with the direction the CRM
is going currently. At our museum we are following the CRM because it
is the only "really standardized" standard for our domain. It is
expressive enough for a full top level ontology while also covering
the domain of cultural heritage. We are not interested in yet another
standard that maps metadata in a very common way - we have enough of
these and if we would want to use dublin core we would do so. The full
potential of the CRM is what binds us to using it.

Concepts like "Title" are really important for our domain - it is one
of the most important metadata fields for documentation in our museum.
With the abolishment of properties and classes in CRM Base that were
used a lot in the past the SIG and the CRM takes a turn away from the
museum side of documentation towards being a very general ontology.
While I know development may always hurt a little bit, this does not
feel right in any way anymore.

I am asking myself: Is this really what the CIDOC CRM should do? Is it
possible for the CIDOC CRM to survive in comparison to standards that
are more widely spread while abolishing it's own user base? Do we
really want a domain ontology - extending CRM Base called "CRM Museum
Documentation Ontology" because we throw out everything that is museum
related out of CRM Base? 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

Am Di., 8. Nov. 2022 um 21:51 Uhr schrieb Robert Sanderson via Crm-sig
:


Thank you for the clarification, Martin!

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

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

Thanks again,

Rob

On Tue, Nov 8, 2022 at 2:24 PM Martin Doerr via Crm-sig
 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, 

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

Thanks Paulos for pointing out the principle under discussion.

As this unexpectedly lively debate over a simple request for clearly
documenting in the standard a central and useful class has illustrated, the
principle in question appears ill formulated or incomplete since it sets a
letter of the law but requires much 'spirit' to fill in how it is actually
applied. One could call that 'likes'.

As Rob's reductio ad absurdum demonstrates, there are some rules for some
classes and other rules for other classes. Yes to Sites, because ... like?
No to Linguistic_Appellation because ... not like? I believe we would not
like to and not benefit from deleting the classes he proposes for deletion
although according to the letter of the law of the principle we ought to.

The class Linguistic Appellation comes out an empirical process of ontology
design and is a key concept for the community. It is not 'RDFS whatever'. I
believe this is another principle (how do we weigh the many countervailing
principles?) that says such classes should stay in or join the ontology. We
should represent (in an ontologically correct manner) key concepts of the
community. This is probably the justification for Site. But if it is the
justification for site, then it is a justification for
Linguistic_Appellation. Names with languages are a core concept of the
community (I don't imagine anyone cares to disagree?).

There are two more principles to call upon:

1) consistency of reasoning / application of rules
2) good practice as a standard

I think the first is self explanatory but let me elaborate more on the
second. CIDOC CRM is meant to be a communication standard and to be the
standard it is a ubiquitously self documenting enterprise, that should
show, from itself, exactly what it means. The spec is a sort of formal
ontology bible to users to adjudicate whether something is or is not, is
right or is not right. CRM achieves its job of enabling communication
between data and projects that otherwise are not connected, just when it is
so transparently clear and self documenting that it is applied
unambiguously. In attempting to apply Linguistic Appellation, which is a
key concept in the domain, and not finding it in the standard, I ran into
confusion because it has been kept out of the standard for what are shown
above to be inconsistent and insufficient reasons. It ought not to have
been because it is a key concept in the community and we should enable
clear communication.

So I propose not to go on a class deletion spree, nor on a class creation
spree, but rather to revisit the ambiguous principle and add in our
description of ceteris paribus conditions that we accept which includes
"important to the domain", and then revisit E33_E41 in that spirit to see
if we can give it full recognition, so that we can get on with core mission
which is enabling communication across data structures via a clear,
consistent and self documenting ontology.

Cheers,

George

On Tue, Nov 8, 2022 at 11:33 PM Mark Fichtner via Crm-sig <
crm-sig@ics.forth.gr> 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
>
>
>
> 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, 

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

[Mark Fichtner via Crm-sig]

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



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

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

[Robert Sanderson via Crm-sig]

Thank you for the clarification, Martin!

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

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

Thanks again,

Rob



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

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

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

[Martin Doerr via Crm-sig]

...apologies for writing piecewise!

Here some arguments for and against a Linguistic Appellation:

A) In order for an Appellation to become language specific, does it need 
some special traits?

   Can an Identifier become language specific? A place primitive?
   If not, there must be more to such an Appellation, that is in favor 
of a subclass.


B) is being language specific unique? Can names belong to 3 languages, 
but not to others?


C) How does an instance of Linguistic Appellation comes into being: If 
it is acquired later, it would be an accidental property, not essential. 
Then the Linguistic Appellation would have a potential to become part of 
a language.

The Human Made Feature comes into being in this combination exclusively.

D) Question: May be the language of an Appellation is a different 
property from that of an Linguistic Object, it may be like an adoption 
to genetic descendence. Is that difference relevant? Or do we 
distinguish a name being commonly known as in some language from being 
formed in that language (such as "Köln")?


Best

Martin



On 11/8/2022 9:37 PM, Martin Doerr via Crm-sig wrote:

Dear All,

Apologies, I missed some messages in this thread.... Indeed 
"Human-Made Feature" is an interesting case. I prefer to review the 
arguments for Human-Made Feature, Human-Made Object. They are actually 
more complex, because feautures and objects differ wrt to Move, "bears 
feature" etc.


I prefer also a discussion to add more custom classes to the RDFS, 
such as "Active Destruction", rather that inceasing CRMbase.


Best,

Martin

On 11/8/2022 9:20 PM, Martin Doerr via Crm-sig 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



--

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

[Martin Doerr via Crm-sig]

Dear All,

Apologies, I missed some messages in this thread.... Indeed 
"Human-Made Feature" is an interesting case. I prefer to review the 
arguments for Human-Made Feature, Human-Made Object. They are actually 
more complex, because feautures and objects differ wrt to Move, "bears 
feature" etc.


I prefer also a discussion to add more custom classes to the RDFS, such 
as "Active Destruction", rather that inceasing CRMbase.


Best,

Martin

On 11/8/2022 9:20 PM, Martin Doerr via Crm-sig 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
 wrote:

Dear George,

To my understanding (without having been involved in the
relevant discussions about having the E33_E41 class in the
RDFS but not in CRM),
and according to the discussion in issue 363

,
classes that use to co-occur on things simultaneously without
being associated with properties only applicable to the
combination of such classes, are not modelled individually as
subclasses of multiple parent classes (a principle used for
keeping the ontology compact).

The 'E35 Title' class exists because there is a
property 'P102 has title' (of E71 Human-Made Thing) that
needs to point to something that is both a linguistic object
and an appellation.
So, for having a CRM class "E? Linguistic Appellation", there
should be a property that needs to point to something that is
both a linguistic object and an appellation (and with the
intended meaning), e.g. a 'has linguistic appellation'
property for E39 Actor or E77 Persistent Item. To my
understanding, since there is no such property, there is
(currently) no need to introduce such a class in CRM.

Best,
Pavlos



On Tue, Nov 8, 2022 at 12:50 PM George Bruseker via Crm-sig
 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 

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

[Martin Doerr via Crm-sig]

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

Dear George,

To my understanding (without having been involved in the
relevant discussions about having the E33_E41 class in the
RDFS but not in CRM),
and according to the discussion in issue 363

,
classes that use to co-occur on things simultaneously without
being associated with properties only applicable to the
combination of such classes, are not modelled individually as
subclasses of multiple parent classes (a principle used for
keeping the ontology compact).

The 'E35 Title' class exists because there is a property 'P102
has title' (of E71 Human-Made Thing) that needs to point to
something that is both a linguistic object and an appellation.
So, for having a CRM class "E? Linguistic Appellation", there
should be a property that needs to point to something that is
both a linguistic object and an appellation (and with the
intended meaning), e.g. a 'has linguistic appellation'
property for E39 Actor or E77 Persistent Item. To my
understanding, since there is no such property, there is
(currently) no need to introduce such a class in CRM.

Best,
Pavlos



On Tue, Nov 8, 2022 at 12:50 PM George Bruseker via Crm-sig
 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, 

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

[Pavlos Fafalios via Crm-sig]

Dear George and Robert,

Your comments are well taken and understood. I do not take a position
against or for the addition of this class (I'm not yet sure of either
decision), nor I support that "rules" must be always respected. I just
tried to find a good reason for not having already introduced such a class
(and thus facilitate the discussion).

Best,
Pavos

On Tue, Nov 8, 2022 at 5:00 PM Robert Sanderson  wrote:

>
> I agree with George that this should be added.
>
> There are plenty of cases of classes without additional properties that
> serve only to join two parent classes. For example E22_Human-Made_Object,
> E25_Human-Made_Feature, and E34_Inscription. There are also remaining leaf
> nodes with no properties with only one parent class, such as E27_Site.
> Further, there are classes that have a property, but which is semantically
> indistinguishable from its super property. If the requirement is a
> property, then I propose
>
> Pxx_is_named_by (names)
> Domain: E1
> Range: Exx_Name (previously E33_E41)
> Sub Property Of: P1_is_identified_by
> Super Property Of:  P102 has title
>
> This property describes the naming of any entity by a name in a human
> language.
>
> And the
> Exx_Name
> Super Class: E33, E41
> Super Class Of: E35 Title
>
>
> The discussion last time devolved to "Well we use those so we don't want
> to get rid of them so we're not going to even though they don't have
> properties". But here's the thing ... *everything* has a Name (by which I
> mean an E33_E41_Linguistic_Appellation). And it's easy to demonstrate that
> E33_E41 is very well used.
>
> So ... I don't find the argument that we can't do this "because rules"
> very convincing when those rules are applied so inconsistently.
>
> Rob
>
>
>
> On Tue, Nov 8, 2022 at 9:18 AM Pavlos Fafalios via Crm-sig <
> crm-sig@ics.forth.gr> wrote:
>
>> Dear George,
>>
>> To my understanding (without having been involved in the
>> relevant discussions about having the E33_E41 class in the RDFS but not in
>> CRM),
>> and according to the discussion in issue 363
>> 
>> ,
>> classes that use to co-occur on things simultaneously without being
>> associated with properties only applicable to the combination of such
>> classes, are not modelled individually as subclasses of multiple parent
>> classes (a principle used for keeping the ontology compact).
>>
>> The 'E35 Title' class exists because there is a property 'P102 has title'
>> (of E71 Human-Made Thing) that needs to point to something that is both a
>> linguistic object and an appellation.
>> So, for having a CRM class "E? Linguistic Appellation", there should be a
>> property that needs to point to something that is both a linguistic object
>> and an appellation (and with the intended meaning), e.g. a 'has linguistic
>> appellation' property for E39 Actor or E77 Persistent Item. To my
>> understanding, since there is no such property, there is (currently) no
>> need to introduce such a class in CRM.
>>
>> Best,
>> Pavlos
>>
>>
>>
>> On Tue, Nov 8, 2022 at 12:50 PM George Bruseker via Crm-sig <
>> crm-sig@ics.forth.gr> wrote:
>>
>>> It's not really though. In the majority of cases when you talk about a
>>> name you need to talk about a language too. Especially if CRM wants to be
>>> inclusive etc. We have a subclass 'title' of appellation that does allow
>>> but it only works for inanimate objects. So it is useless 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) 

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

[Athanasios Velios via Crm-sig]

The section on Minimality outlines when new classes are declared and it 
includes:


"It serves as a merging point of two CIDOC CRM class branches via 
multiple IsA (e.g., E25 Human-Made Feature). When the branch 
superclasses are used for multiple instantiation of an item, this item 
is in the intersection of the scopes. The class resulting from multiple 
IsA should be narrower in scope than the intersection of the scopes of 
the branch superclasses."


If I interpret this correctly, we need to ask:

Is "E33 E41 Linguistic Appellation" narrower in scope that the result of 
multiple instantiation of "E33 Linguistic Object" and "E41 Appellation"?


And if I understand George's message correctly, it looks like it is not 
narrower, no?


All the best,

Thanasis




On 08/11/2022 15:00, Robert Sanderson via Crm-sig 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 
mailto:crm-sig@ics.forth.gr>> wrote:


Dear George,

To my understanding (without having been involved in the
relevant discussions about having the E33_E41 class in the RDFS but
not in CRM),
and according to the discussion in issue 363

,
classes that use to co-occur on things simultaneously without being
associated with properties only applicable to the combination of
such classes, are not modelled individually as subclasses of
multiple parent classes (a principle used for keeping the ontology
compact).

The 'E35 Title' class exists because there is a property 'P102 has
title' (of E71 Human-Made Thing) that needs to point to something
that is both a linguistic object and an appellation.
So, for having a CRM class "E? Linguistic Appellation", there should
be a property that needs to point to something that is both a
linguistic object and an appellation (and with the intended
meaning), e.g. a 'has linguistic appellation' property for E39 Actor
or E77 Persistent Item. To my understanding, since there is no such
property, there is (currently) no need to introduce such a class in
CRM.

Best,
Pavlos



On Tue, Nov 8, 2022 at 12:50 PM George Bruseker via Crm-sig
mailto: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
 mailto: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 mailto:crm-sig-boun...@ics.forth.gr>> *On Behalf Of *George
Bruseker via Crm-sig
*Sent:* 07 November 2022 15:58
*To:* Elias Tzortzakakis mailto:tzort...@ics.forth.gr>>
   

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

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

[Robert Sanderson via Crm-sig]

I agree with George that this should be added.

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

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

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

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


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

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

Rob



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

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

Re: [Crm-sig] 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
>> 
>> ,
>> 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:

 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





 

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

[Pavlos Fafalios via Crm-sig]

Dear George,

To my understanding (without having been involved in the
relevant discussions about having the E33_E41 class in the RDFS but not in
CRM),
and according to the discussion in issue 363

,
classes that use to co-occur on things simultaneously without being
associated with properties only applicable to the combination of such
classes, are not modelled individually as subclasses of multiple parent
classes (a principle used for keeping the ontology compact).

The 'E35 Title' class exists because there is a property 'P102 has title'
(of E71 Human-Made Thing) that needs to point to something that is both a
linguistic object and an appellation.
So, for having a CRM class "E? Linguistic Appellation", there should be a
property that needs to point to something that is both a linguistic object
and an appellation (and with the intended meaning), e.g. a 'has linguistic
appellation' property for E39 Actor or E77 Persistent Item. To my
understanding, since there is no such property, there is (currently) no
need to introduce such a class in CRM.

Best,
Pavlos



On Tue, Nov 8, 2022 at 12:50 PM George Bruseker via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> It's not really though. In the majority of cases when you talk about a
> name you need to talk about a language too. Especially if CRM wants to be
> inclusive etc. We have a subclass 'title' of appellation that does allow
> but it only works for inanimate objects. So it is useless as a general
> case. The use of E33_E41 should be a default in most modelling cases with
> E41 being the exception (mostly names are in a language). The general idea
> of a name in a language is not an arcane concept, but the majority concept.
> Needing to use an arcane construct either E33_E41 or multi instantiation
> for the majority case when the standard could just provide the appropriate
> class and document it and allow people to build around it, would be a
> superior way to go imho.
>
> On Tue, Nov 8, 2022 at 12:04 PM stead...@outlook.com 
> 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
>>
>>
>>

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

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

[Elias Tzortzakakis via Crm-sig]

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/

___
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