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 >> listCrm-sig@ics.forth.grhttp://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
