Issue 358: CRMsoc and scope of CRM modules
posted by Martin on 10/1/2018
<proposal>
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.
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.
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.
posted by Oyvind on 12/1/2018
Dear Martin, and all,
> Am 10.01.2018 um 21:21 schrieb Martin Doerr <martin@ics.forth.gr>:
>
> 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?
posted by Francesco Berreta on 15/1/2018
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 <martin@ics.forth.gr>:
>>
>> 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.
In the 40th joined meeting of the CIDOC CRM SIG and ISO/TC46/SC4/WG9 and the 33nd FRBR - CIDOC CRM Harmonization meeting, the crm-sig discussed the proposal by Martin and decided the following actions:
About Plans model: The crm sig accepted MD’s proposal to withdraw the plans model (classes and properties) from CRMbase. The numbers of classes and properties will be deleted from CRMbase and will not be marked as deprecated since version 6.2.3 of CRMbase is still “In Progress” and it has not been published yet. The crm-sig decided that when classes and properties are deleted from published versions, they will be marked as “deprecated” in all subsequent versions regardless of the version status. In any other case they will be simply deleted.
posted by Velios on 9/5/2018
I am continuing with one of the sub-issues which says:
"About simplifying the template for the description of the family models: During the discussion about describing the new family model CRMsoc, the sig decided the description of each family model should be self-contained. The crm-sig assigned TV to propose simplified template for extensions."
Following the last SIG meeting I received the current template used for extensions from Chryssoula. The current template is actually simple and, in my view, suitable but it has not always been followed (for example in earlier drafts of CRMsci which initiated my original comments). As far as the document template is concerned I propose that it remains the same. Only that it is followed more strictly (for example, for the CRMsci version 1.2.5 I have proposed the removal of several sections which are not part of the template - see issue 332).
In the 41st joined meeting of the CIDOC CRM SIG and ISO/TC46/SC4/WG9 and the 34th FRBR - CIDOC CRM Harmonization meeting, the sig decided to open a new issue (384) about the template for the description of family models. Also the sig assigned to Francesco Berreta and Thanasis Velios to write the introduction of CRMsoc.
Lyon, May 2108
In the 42nd joined meeting of the CIDOC CRM SIG and ISO/TC46/SC4/WG9 and the 35th FRBR - CIDOC CRM Harmonization meeting, The discussion also included a demonstration of OntoME by FB, proposing that it be used as a means to extend the crm in a dynamic way for specific projects but in a common space. It was proposed (FB) that OntoME be further developed jointly by organizations participating in the crm-sig. It was agreed that no decision can be reached unless the goal and horizon of such a project are explicitly and formally stated, together with an estimation of the cost and resources that such an endeavor would require. And it would have to be communicated to the crm-sig, which is to determine whether they will engage in such a project.
HW: The crm-sig has assigned TV & FB to supply the full text document, outlining the intended and practical scope of CRMsoc, as well as propose naming conventions for the CRMsoc entities and properties by the next crm-sig meeting.
HW: MD will provide some classes from Social Institutions and NC will give us data up to the next meeting. The model is intended to cover social relations, economic activities, plans and rights.
HW: MD is to send a first attempt at defining the notions of Phase by email.
HW: MD, FB (who will be providing use cases) and RS (who will be providing examples and data) are assigned with working on the Business Model.
HW: RS to participate and coordinate the development of CRMsoc family model and take part in the discussion regarding the temporality of properties.
HW: RS will also participate in the discussion regarding the temporality of properties.
Berlin, November 2018
Posted by Robert Sanderson on 29/11/2018
Social constructs
· Ownership – initiated and terminated by an Acquisition, expresses the temporal validity of has_current_owner
o E.g. The Getty has owned Irises since 1990, and still does, and did not lose ownership between then and now
· Custody – as per Ownership, relative to Transfer of Custody
o The Getty had custody of Irises from 1990 until June 1999, at which point it transferred custody via a Move to the National Gallery of Canada, for the purpose of an Exhibition
· Identification – temporal validity of a P1_is_identified_by between something and an Identifier
o Knoedler and Co assigned an identifier to Rembrandt’s Lucretia - 23007
o The NGA assigned an identifier to the same painting – 1937.1.76
· Naming – similarly temporal validity of P1, for an Appellation rather than an Identifier
o The painting had the name “The Rape of Europa” until sometime in the 70s, but was then renamed to the more politically correct “The Abduction of Europa” (and the original name was translated from the published name, “El rapto de Europa”
o Knoedler calls the painting “Lucretia Stabbing Herself”, whereas the NGA call it just “Lucretia”
· Valuation – assignment of value for an object (monetary amount)
o In 1913, Lucretia was valued at $130,000 and then later in the year at 39,000 GBP
· Usage – that a thing was used in a particular way – either via p2_has_type or other
o A building can be used as a church, and then as a restaurant.
· Profession – p2_has_type of a Person
o Lewis Carroll was a photographer for a time, an author for a time, and a mathematician for a time
· Gender – p2_has_type of a Person
o Bruce Jenner was a male, and then a female (and took the name Caitlyn Jenner)
· Nationality – p2_has_type of a Person
o Angelina Jolie is American (by birth), but gained Cambodian nationality by decree of King Norodom Sihamoni, in 2005
Physical:
· The painting The Night Watch was originally larger than its current dimensions of 363cm x 437cm. It was cut down in 1715 when it was moved to the Amsterdam Town Hall to make it fit.
· Existence – the state between Production and Destruction ☺
Hope that helps!
Links:
Lucretia: https://www.nga.gov/collection/art-object-page.83.html
Irises: http://www.getty.edu/art/collection/objects/826/vincent-van-gogh-irises-dutch-1889/
Angelina: https://people.com/celebrity/angelina-jolie-gets-cambodian-citizenship/
Nightwatch original content: https://en.wikipedia.org/wiki/The_Night_Watch#/media/File:Nachtwacht-kopie-van-voor-1712.jpg
Posted by Martin on 22/3/2019
Dear Francesco, All,
Here some thoughts about modelling transaction business by obligations as fundamental building blocks.
Please let me know if you are aware of any similar or alternative ontology to that. To be discussed.
Posted by Robert Sanderson on 22/3/2019
Thanks Martin.
One initial note … for the Payment class, we separate out the paid_from and paid_to from the carried_out_by. The use case is when there is an agent that performs the Activity, which is neither the payer nor payee. For example, if I authorize an agent to go to an auction and bid on my behalf and disburse my funds, then the funds come from me, go to the seller, but the agent is carrying out the Payment activity, not me. In the worst case (for me!) I might have been run over by a bus immediately before the Payment, and thus incapable of carrying out the activity.
Rob