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
<crm-sig@ics.forth.gr <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
<https://cidoc-crm.org/Issue/ID-363-form-and-persistence-of-rdf-identifiers>,
classes that use to co-occur on things simultaneously without being
associated with properties only applicable to the combination of
such classes, are not modelled individually as subclasses of
multiple parent classes (a principle used for keeping the ontology
compact).
The 'E35 Title' class exists because there is a property 'P102 has
title' (of E71 Human-Made Thing) that needs to point to something
that is both a linguistic object and an appellation.
So, for having a CRM class "E? Linguistic Appellation", there should
be a property that needs to point to something that is both a
linguistic object and an appellation (and with the intended
meaning), e.g. a 'has linguistic appellation' property for E39 Actor
or E77 Persistent Item. To my understanding, since there is no such
property, there is (currently) no need to introduce such a class in
CRM.
Best,
Pavlos
On Tue, Nov 8, 2022 at 12:50 PM George Bruseker via Crm-sig
<crm-sig@ics.forth.gr <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> <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 <crm-sig-boun...@ics.forth.gr
<mailto:crm-sig-boun...@ics.forth.gr>> *On Behalf Of *George
Bruseker via Crm-sig
*Sent:* 07 November 2022 15:58
*To:* Elias Tzortzakakis <tzort...@ics.forth.gr
<mailto:tzort...@ics.forth.gr>>
*Cc:* Crm-sig@ics.forth.gr <mailto: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 <mailto: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
<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 <crm-sig-boun...@ics.forth.gr
<mailto:crm-sig-boun...@ics.forth.gr>> *On Behalf Of
*George Bruseker via Crm-sig
*Sent:* Monday, November 7, 2022 5:02 PM
*To:* crm-sig <Crm-sig@ics.forth.gr
<mailto:Crm-sig@ics.forth.gr>>
*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
<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/
<https://www.takin.solutions/>____
____
__ __
-- ____
George Bruseker, PhD____
Chief Executive Officer____
Takin.solutions Ltd.____
https://www.takin.solutions/ <https://www.takin.solutions/>____
--
George Bruseker, PhD
Chief Executive Officer
Takin.solutions Ltd.
https://www.takin.solutions/ <https://www.takin.solutions/>
_______________________________________________
Crm-sig mailing list
Crm-sig@ics.forth.gr <mailto:Crm-sig@ics.forth.gr>
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
<http://lists.ics.forth.gr/mailman/listinfo/crm-sig>
--
Pavlos Fafalios
Postdoctoral researcher (Marie Curie IF - Project ReKnow
<https://reknow.ics.forth.gr/>)
Centre for Cultural Informatics & Information Systems Laboratory
Institute of Computer Science - FORTH
Visiting Lecturer
Department of Management Science & Technology
Hellenic Mediterranean University
Web: http://users.ics.forth.gr/~fafalios/
<http://users.ics.forth.gr/~fafalios/>
Email: fafal...@ics.forth.gr <mailto:fafal...@ics.forth.gr>
Address: N. Plastira 100, Vassilika Vouton, 70013 Heraklion, Greece
Tel: +30-2810-391619
_______________________________________________
Crm-sig mailing list
Crm-sig@ics.forth.gr <mailto:Crm-sig@ics.forth.gr>
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
<http://lists.ics.forth.gr/mailman/listinfo/crm-sig>
--
Rob Sanderson
Director for Cultural Heritage Metadata
Yale University
_______________________________________________
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
_______________________________________________
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
