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
On Wed, Nov 9, 2022 at 9:05 AM Martin Doerr via Crm-sig <
crm-sig@ics.forth.gr> wrote:
> 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
>
> On 11/9/2022 10:46 AM, athinak via Crm-sig wrote:
> > 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
> >
> > On 2022-11-08 23:25, Mark Fichtner via Crm-sig wrote:
> >> 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
> >>
>
> --
> ------------------------------------
> 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
