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 <azarot...@gmail.com>
wrote:
I agree with George that this should be added.
There are plenty of cases of classes without additional properties
that serve only to join two parent classes. For example
E22_Human-Made_Object, E25_Human-Made_Feature, and
E34_Inscription. There are also remaining leaf nodes with no
properties with only one parent class, such as E27_Site. Further,
there are classes that have a property, but which is semantically
indistinguishable from its super property. If the requirement is a
property, then I propose
Pxx_is_named_by (names)
Domain: E1
Range: Exx_Name (previously E33_E41)
Sub Property Of: P1_is_identified_by
Super Property Of: P102 has title
This property describes the naming of any entity by a name in a
human language.
And the
Exx_Name
Super Class: E33, E41
Super Class Of: E35 Title
The discussion last time devolved to "Well we use those so we
don't want to get rid of them so we're not going to even though
they don't have properties". But here's the thing ... *everything*
has a Name (by which I mean an E33_E41_Linguistic_Appellation).
And it's easy to demonstrate that E33_E41 is very well used.
So ... I don't find the argument that we can't do this
"because rules" very convincing when those rules are applied so
inconsistently.
Rob
On Tue, Nov 8, 2022 at 9:18 AM Pavlos Fafalios via Crm-sig
<crm-sig@ics.forth.gr> wrote:
Dear George,
To my understanding (without having been involved in the
relevant discussions about having the E33_E41 class in the
RDFS but not in CRM),
and according to the discussion in issue 363
<https://cidoc-crm.org/Issue/ID-363-form-and-persistence-of-rdf-identifiers>,
classes that use to co-occur on things simultaneously without
being associated with properties only applicable to the
combination of such classes, are not modelled individually as
subclasses of multiple parent classes (a principle used for
keeping the ontology compact).
The 'E35 Title' class exists because there is a property 'P102
has title' (of E71 Human-Made Thing) that needs to point to
something that is both a linguistic object and an appellation.
So, for having a CRM class "E? Linguistic Appellation", there
should be a property that needs to point to something that is
both a linguistic object and an appellation (and with the
intended meaning), e.g. a 'has 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 <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>
*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
*From:*Crm-sig <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>
*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
--
Pavlos Fafalios
Postdoctoral researcher (Marie Curie IF - Project ReKnow
<https://reknow.ics.forth.gr/>)
Centre for Cultural Informatics & Information Systems Laboratory
Institute of Computer Science - FORTH
Visiting Lecturer
Department of Management Science & Technology
Hellenic Mediterranean University
Web: http://users.ics.forth.gr/~fafalios/
Email: fafal...@ics.forth.gr
Address: N. Plastira 100, Vassilika Vouton, 70013 Heraklion,
Greece
Tel: +30-2810-391619
_______________________________________________
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
--
Rob Sanderson
Director for Cultural Heritage Metadata
Yale University
--
Pavlos Fafalios
Postdoctoral researcher (Marie Curie IF - Project ReKnow
<https://reknow.ics.forth.gr/>)
Centre for Cultural Informatics & Information Systems Laboratory
Institute of Computer Science - FORTH
Visiting Lecturer
Department of Management Science & Technology
Hellenic Mediterranean University
Web: http://users.ics.forth.gr/~fafalios/
Email: fafal...@ics.forth.gr
Address: N. Plastira 100, Vassilika Vouton, 70013 Heraklion, Greece
Tel: +30-2810-391619
_______________________________________________
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
--
------------------------------------
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
