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