Add E33_E41_Linguistic_Appellation to the Official Specification

Post by George Bruseker (7 November 2022)

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

Post by Elias Tzortzakakis (7 November 2022)

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

Post by George Bruseker (7 November 2022)

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

Post by Stephen Stead (8 November 2022)

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.

Post by George Bruseker (8 November 2022)

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.

Post by Pavlos Fafalios (8 November 2022)

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

Post by George Bruseker (8 November 2022)

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

Cheers
G

Post by Rob Sanderson (8 November 2022)

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

Post by Thanasis Velios (8 November 2022)

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
 

Post by Pavlos Fafalios (8 November 2022)

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

Post by Martin Doerr (8 November 2022)

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
 

Post by Martin Doerr (8 November 2022)

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

Post by Martin Doerr (8 November 2022)

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

Post by Rob Sanderson (8 November 2022)

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

Post by Mark Fichtner (8 November 2022)

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

Post by George Bruseker (9 November 2022)

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

Post by Athina Kritsotaki (9 November 2022)

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 

Post by Carlo Meghini (9 November 2022)

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

Post by George Bruseker (9 November 2022)       

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

Post by Martin Doerr (9 November 2022)

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 

Post by Rob Sanderson (9 November 2022)

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 <uri-for-English> ]

  crm:P1_is_identified_by [

    a crm:E33_E41_Linguistic_Appellation ;

    P190_has_symbolic_content "دوغلاس آدمز" ;

    P72_has_language <uri-for-Arabic> ]    

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

Post by George Bruseker (9 November 2022)

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&logic=AND&note=&e…

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?

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.

Cheers,

George

Post by Martin Doerr (9 November 2022)

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?

Post by George Bruseker (9 November 2022)

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 don't know if the above wikipedia article is true or not, but I would like to be able to represent that data in the KB so that I could try to find out.

So, not sure why that's a blocker.

Best,

George

Post by Rob Sanderson (9 November 2022)

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

Post by Gordon Dunsire (10 November 2022)

 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.
 

Post by Martin Doerr (10 November 2022)

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

Post by Rob Sanderson (10 November 2022)

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

Post by George Bruseker (10 November 2022)

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.

Post by Martin Doerr (10 November 2022)

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

Post by Gordon Dunsire (11 November 2022)

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.
 
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.
 
GD: I would say that, in the library context, it is 'suitable use in a language group'.
 
 

Post by Francesco Beretta (12 November 2022)

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

Post by George Bruseker (13 November 2022)

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?

Post by Martin Doerr (13 November 2022)

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