Dear Martin, dear all,
Le 12.01.18 à 09:06, Øyvind Eide a écrit :
Dear Martin, and all,
Am 10.01.2018 um 21:21 schrieb Martin Doerr <[email protected]>:
Dear All,
I propose to withdraw the decision to put the plans model into CRM "base".
The Model becomes very unwieldy now.
I propose to create a CRMsoc (social), with
all plans, rights, norms, laws, business transactions, social relations and
their detailed temporal modelling.
Maybe this could be a place to include historical accounting as well?
On the one side, as we discussed in the last SIG Meeting, the whole CRM
is, or most parts of it are, about history: therefore there's no need to
have a specific extension about history. The dataforhistory.org project
is accordingly limited to managing profiles devoted to specific
subdomains of historical research (meant in its broadest sense), it is
not about creating an official CRM extension for historical research.
On the other side, most objects of historical research are related to
social life and consequently it seems very useful to have some more
classes and properties modelling this domain. In a specific extension.
I therefore fully support Martin's proposal.
I propose to withdraw the decision to put "Observation" into CRMbase.
A proper handling of Observation needs a model of an observed Situation, with
adequate
constraints for the things and relationships that can be observed.
I propose to keep Observation in CRMSci. To be clarified how the stratification
with CRMInf is achieved.
I propose to give up the condition that CRMbase keeps exclusively all
superproperties necessary to reach all elements in
a CRM compatible graph.
I propose to allow extensions, with "special mark-up and permission", to
explicitly declare additional superproperties, as few
as possible, and clearly justified by a distinct subject.
This seems to be a good concept, but we then need a flexible and
performant way of easily analyze and visualize the complex world of the
CRM and it's extensions. One should be able to filter in and out
extensions without loosing consistency, explore inheritance of
properties, etc.
Temporality of relationships appears to be a topic with a set of distinct
ontological patterns, which need to be considered separately.
Depending on the pattern, it should be decided into which module an explicit
description of a temporal validity of a relationship
will belong, regardless if the "time agnostic" version exists in CRMbase.
I agree with this proposal and then discuss, at a later time, if a
couple of new classes should be introduced to CRMbase, in addition to
the existing properties with limited temporal validity, to provide a
general view on this issue that could be used by the whole community.
Have a good start in the SIG meeting and see you tomorrow.
Best
Francesco Beretta
-----
Chargé de recherche au CNRS,
Responsable du Pôle histoire numérique,
Laboratoire de recherche historique Rhône-Alpes
CNRS UMR 5190 LARHRA,
I.S.H.,
14, Avenue Berthelot
69363 LYON CEDEX 07
+ 33 (0)6 51 84 48 84
Le Pôle histoire numérique
<http://larhra.ish-lyon.cnrs.fr/pole-histoire-numerique> du LARHRA
Le projet symogih.org <http://symogih.org/>
Le projet dataforhistory.org <http://dataforhistory.org/>
SPARQL endpoint <http://symogih.org/?q=rdf-publication>
Portail de ressources géo-historiques GEO-LARHRA
<http://geo-larhra.ish-lyon.cnrs.fr/>
Portail de ressources textuelles
<http://xml-portal.symogih.org/index.html> au format XML
Cours Outils numériques
<http://phn-wiki.ish-lyon.cnrs.fr/doku.php?id=td_histoire_numerique:accueil>pour
les historiens
<http://phn-wiki.ish-lyon.cnrs.fr/doku.php?id=td_histoire_numerique:accueil>
Publications
<https://halshs.archives-ouvertes.fr/search/index/?qa[auth_t][]=Francesco+Beretta&sort=producedDate_tdate+desc>
