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
