Posted by Thanasis on 10/6/2019
Dear all,
Following discussions with Martin I am sending some homework about the
specification of events with which the activity plans are concerned, and
also a revision of the Activity Plan scope note. Also attached.
-------------------------------------------------------------
socExx Event Specification
subclass of : E89 Propositional Object
Scope note:
This class comprises specifications of events by providing necessary or
desirable constraints to their properties, be it on the level of
particular items involved or on the level of kinds of processes, items
or qualities and quantities involved. Such specifications may be used to
recognize that a past or future particular event fits the specification
or for planning future events. Characteristically, instances of this
class may be created to be associated with instances of socExx Activity
Plan, as specification of the kind of event that should trigger the
execution of an Activity Plan. For example, we expect a disaster plan
for a library to be executed when a disaster happens or as part of a
disaster readiness exercise.
Examples:
* The description of the rainy weather conditions at the location and
date of my wedding (socExx Event Specification) done in advance by my
wedding planner, which was specified to trigger the plan (socExx
Activity Plan) of using a gazeebo.
* The description of the sunny weather conditions at the location and
date of my wedding (socExx Event Specification) done in advance by my
wedding planner, which was specified to trigger the plan (socExx
Activity Plan) of taking photographs at the park.
* The description of the humidity level reached in the museum store room
(socExx Event Specification) done in advance by a preventive
conservator, which was specified to trigger the plan (socExx Activity
Plan) of turning on the dehumidifier.
Properties:
* socPxx requires event type (is required event type of): E55 Type
(e.g.1 rainy weather and wedding, e.g.2 change of humidity)
* socPxx requires actor role (is required actor role of): E55 Type
(e.g.1 mayor)
* socPxx requires type of thing (is required type of thing of): E55 Type
(e.g., a car)
* socPxx requires place (is required place of): E53 Place (e.g.1 Cardiff
city hall, e.g.2 National Museum Wales store room)
* socPxx requires time-span (is required time-span of): E4 Time-span
(e.g.1 4th of June 2019, e.g.2 winter of 2019)
* socPxx requires actor (is required actor of): E39 Actor (e.g.1 mayor
John Smith)
* socPxx requires material substantial (is required material substantial
of): S10 Material Substantial (e.g.1 wedding ring, e.g.2 air in NMW
store room)
* ?? socPxx requires condition (is required condition): E89
Propositional Object? (e.g.2 that the RH > 20%)
----------------------------------------------------------
socExx Activity Plan
subclass of: E29 Design or Procedure
Scope note:
This class comprises plans foreseeing specific predefined activities or
kinds of activities taking place. They consist of descriptions of
specific constraints, patterns or types of activities that could be
realized. They may also foresee that the planned activities are realized
at times explicitly foreseen by the actor intending the application of
the plan, for instance, to organize a conference, in which case we may
talk about “active plans”. Alternatively, times of realization may be
foreseen in reaction to external events of a kind foreseen by the plan,
for instance the rescue activity after an earthquake following a rescue
plan, or a penal action in the case of criminal activity according to a
penal code, in which case we may talk about “reactive plans”. The
specification of the related planned or unplanned events can be done
using instances of socExx Event Specification. The fact that an instance
of socExx Activity Plan is linked to an instance of socExx Event
Specification does not require that it will only be executed after
events conforming to that specification take place.
The existence of an instance of Activity Plan does not necessarily imply
the intention of any Actor to apply it. It may be created together,
before or without the will to apply it. For instance, laws are created
before they are passed by parliament. Any Activity Plan may require
specific conditions for it to be applicable. For example, a plan to
excavate a river bank may require that the river is flooded, or my plan
to lime plaster my stone wall requires that it is winter (i.e. wet and
cold).
Examples:
The disaster plan of Tate Archives in case of the Thames flooding.
The proposal for conservation work for MS Greek 418 at the Saint
Catherine library.
Provisions of Law 3730/2008 of the Greek Government against smoking in
work places.
Properties:
socP100 concerns: socExx Event Specification
socP4 is assessed by: E31 Document
In the 44th joint meeting of the CIDOC CRM SIG and ISO/TC46/SC4/WG9; 37th FRBR - CIDOC CRM Harmonization meeting, the sig reviewed the HW by TV regarding the scope note definitions for socExx Event Specification and socExx Activity Plan, plus the properties linking them to other CRM classes. The reviewing process primarily involved editorial work as well as changes in the content. You may find here the editorial work.
Paris, June 2019
Posted by Thanasis on 20/10/2019
Dear all,
I spent a bit of time putting together some scope notes and examples for the Trigger Event Template properties (also attached as a document (in .odt)with an updated diagram). I forwarded these to Stephen only last week so he had not had a chance to review them, but maybe we can do that at the meeting next week. FOL statements and Quantification produced by OntoMe.
All the best,
Thanasis
socP24 specifies material substantial (is specified material substantial)
Domain:
socE4 Trigger Event Template
Range:
S10 Material Substantial
Quantification:
0,n:0,n
Scope note:
This property associates an instance of socExx Trigger Event Template with an instance of S10 Material Substantial which the template specifies to be used or be present for the planned activity.
Examples:
The disaster plan of the Tate Archives (socE2 Activity Plan) concerns the possible event (socE4 Trigger Event Template) which specifies (socP24 specifies material substantial) the river Thames (S10 Material Substantial / S14 Fluid Body) flooding.
In First Order Logic:
socP24(x,y) ³ socE4(x)
socP24(x,y) ³ S10(y)
socP23 specifies actor (is specified actor of)
Domain:
socE4 Trigger Event Template
Range:
E39 Actor
Quantification:
0,n:0,n
Scope note:
This property associates an instance of socExx Trigger Event Template with the instance of E39 Actor who is specified by the template to be part of the planned activity.
Examples:
The template specifying my wedding (socExx Trigger Event Template), specifies (socP23 specifies actor) Rev Glyn Tidwell (E39 Actor) to be present to undertake the wedding service.
In First Order Logic:
socP23(x,y) ³ socE4(x)
socP23(x,y) ³ E39(y)
socP22 specifies time-span (is specified time-span of)
Domain:
socE4 Trigger Event Template
Range:
E52 Time-Span
Quantification:
0,n:0,n
Scope note:
This property associates an instance of socExx Trigger Event Template with the instance of E52 Time-span which is specified by the template as the time-span for the planned activity.
Examples:
The template specifying my wedding (socE4 Trigger Event Template), specifies (socPxx specifies time-span) the the wedding takes place between 14:00 and 23:00 of the 12th of August 2006 (E52 Time-span).
In First Order Logic:
socP22(x,y) ³ socE4(x)
socP22(x,y) ³ E52(y)
socP21 specifies place (is specified place of)
Domain:
socE4 Trigger Event Template
Range:
E53 Place
Quantification:
0,n:0,n
Scope note:
This property associates an instance of socExx Trigger Event Template with the instance of E53 Place which is specified by the template as the place where the planned activity should take place.
Examples:
The template specifying my wedding (socE4 Trigger Event Template), specifies (socP21 specifies place) the location of Cardiff Castle (E53 Place) for the wedding party to take place.
In First Order Logic:
socP21(x,y) ³ socE4(x)
socP21(x,y) ³ E53(y)
socP19 specifies actor role (is specified actor role of)
Domain:
socE4 Trigger Event Template
Range:
E55 Type
Quantification:
0,n:0,n
Scope note:
This property associates an instance of socExx Trigger Event Template with the E55 Type of the role of an E39 Actor which is specified by the template. This property does not require the instance of E39 Actor to be specified by socP23 specifies actor (is specified actor of).
Examples:
The template specifying my wedding (socE4 Trigger Event Template) specifies (socP19 specifies actor role) that someone acts as a disc jokey (E55 Type) to play music for the wedding guests.
In First Order Logic:
socP19(x,y) ³ socE4(x)
socP19(x,y) ³ E55(y)
socP18 specifies event type (is specified event type of)
Domain:
socE4 Trigger Event Template
Range:
E55 Type
Quantification:
0,n:0,n
Scope note:
This property associates an instance of socExx Trigger Event Template with the type (E55 Type) of the E5 Event which would trigger the planned activity. Typically the instance of E5 Event is not known when the planned activity and the trigger template are being produced, so it cannot be specified.
Examples:
The disaster plan of the Tate Archives (socE2 Activity Plan) concerns the event of the river Thames flooding (socE4 Trigger Event Template) which specifies an event of type (socPxx specifies event type) "flood" (E55 Type).
In First Order Logic:
socP18(x,y) ³ socE4(x)
socP18(x,y) ³ E55(y)
socP20 specifies type of thing (is specified type of thing of)
Domain:
socE4 Trigger Event Template
Range:
E55 Type
Quantification:
0,n:0,n
Scope note:
This property associates an instance of socExx Trigger Event Template with the type (E55 Type) of a thing which the template specifies to be used or be present for the planned activity. The instance of the thing can be specified using the property socP24 specifies material substantial (is specified material substantial).
Examples:
No example yet.
In First Order Logic:
scoP20(x,y) ³ socE4(x)
scoP20(x,y) ³ E55(y)
In the 45th joint meeting of the CIDOC CRM SIG and SO/TC46/SC4/WG9; 38th FRBR – CIDOC CRM Harmonization meeting, the sig began reviewing the scope notes for the properties linking socE4 Trigger Event Template with other CRM classes (HW by TV).
The sig thoroughly discussed the scope note and example for the first property and did some editing, but then dropped it, as it seemed that most examples conflated Trigger Event Templates with Active Plans instead of Reactive ones and the scope ones were ambiguous btw an active and a reactive reading.
HW: TV is to redo the current HW, bearing in mind that active plans presuppose agency on behalf of the person intended to carry out the plan, from conception up to implementation. On the other hand, reactive plans are triggered by events that the person intended to carry out the plan has no control over.
Specifically for socPxx specifies material substantial (is specified material substantial) [D: socE4 Trigger Event Template, R: S10 Material Substantial] the example is OK and accepted [*], but there could be additional examples from an art conservator’s perspective, like the deterioration of the glue on the back of a book or a varnish layer on some painting.
[*] Example:
The Tate Archives Flooding Disaster Plan Trigger Event Template specifies material substantial The River Thames (S14).
Heraklion, October 2019
Posted by Thanasis on 21/2/2020
Dear all,
In the last meeting we reviewed previous HW with scope notes for CRMsoc properties around activity plans and discovered that we (I) had been inconsistent with describing trigger events and activities. Following discussion with George and Martin I have reworked the model and scope notes to have a general template for any type of event with one property pointing to trigger event specifications and another to action/event specifications. I have also embedded condition checking using I11 Situation.
Please see the drawing and the revised scope notes attached. It would be useful to finalise these at the meeting next week. Happy to receive comments in the meantime.
In the 46th joint meeting of the CIDOC CRM SIG and ISO/TC46/SC4/WG9; 39th FRBR - CIDOC CRM Harmonization meeting; The sig reviewed the HW by TV –scope notes and examples for properties connecting from/to socE4 Event Template.
In short:
- the sig assigned HW to TV to look "system workflow specifications" on the different levels of event templates, i.e. one event template being a specialization of another.
- The scope notes and examples for the following properties have been accepted with minor modifications:
- socPxx foresees (is foreseen by)
- socP17 has trigger (is trigger for)
- socP24 specifies material substantial (is specified material substantial)
- socP23 specifies actor (is specified actor of)
- socP18 specifies event type (is specified event type of)
- socP20 specifies type of thing (is specified type of thing of)
- socP19 specifies the role type of a required actor (is the role type of a required actor)
- socP22 specifies time-span (is specified time-span of)
- socP21 specifies place (is specified place of) - HW: The sig appointed MD to rewrite the scope note and example for this new socP21. This is to be done separately, in a new issue, which would also involve rewriting the scope note and examples for socP22. (issue 481)
- socPxx matched template (is template for) - HW: TV to rethink this property (with the help of the LCD community). HW: TV, GB, MA (Marta Acierno) to find suitable examples from the domain of risk assessment in conservation, especially data from disaster prevention networks and anything that relates to the conservation/restauration of architectural monuments in case of earthquakes or other disasters.
Upon discussing this property, the sig resolved to start a new issue concerning the possibility that the CRM can contribute to the semantic representation in risk assessment (in conservation). The idea is to take into account the state-of-the-art in the domain and methods of risk assessment in conservation and see whether the CIDOC CRM can interface the domain. HW: CM, MA, DF(Donatella Fiorani), ML. Linked Conservation Data consortium is to be contacted directly (TV) and especially Amina.
- socPxx specifies situation
The minor modifications of the above properties can be found here.
Athens, February 2020
Post by Thanasis Velios (8 June 2021)
Dear all,
During discussions on the future of activity plans it appears that we have 3 options:
1) Activity plans to remain as part of CRMsoc. This makes sense since obeying laws and receiving penalties take place in societies and such things appear to match the model for activity plans. However, they are not central to the current CRMsoc discourse.
2) Activity plans to move to CRMbase. This makes sense given that Purchase is in core and there is an increasing amount of interest in business transactions, but again perhaps not central enough to the CRMbase focus.
3) Activity plans to become its own extension. This makes sense as it is a construct focussing on possible future events rather than past events mainly concerning the CRM and its extensions otherwise. Also it being a separate extension could create a space for business transactions.
I support option 3 and I would like us to discuss this at the next SIG meeting and decide. I am happy to act as the maintainer of such an extension.
All the best,
Thanasis
Post by Achille Felicetti (9 June 2021)
Dear Thanasis,
I also tend to be in favour of your option 3 because in my opinion, the planning problem is transversal and concerns many disciplines and many areas, not just the social one. Recently, I have been working on the modeling of laboratory analyses, their preventive planning and the related definition of research protocols that require this type of approach.
But the same kind of planning is required, for example, for the preparation and 3D digitisation of objects and monuments in archeology and for many other similar activities.
I think that having an extension dedicated exclusively to this topic could have a general value and usefulness for many researchers and I would naturally be very happy if you could coordinate its development.
Ciao,
Achille
Post by Francesco Beretta (10 June 2021)
Dear Achille, Thanasis, all
In my opinion, your discussion raises two questions, a specific and a general one.
The specific:
In which part of the CRM family is it better to have the activity plans ? You have good arguments for the third option proposed by Thanasis – waiting since years with this unsolved issue. This would suggest to move on.
The general:
But one could also argue that the domain of the CRMbase is "information exchange and integration between heterogeneous sources of cultural heritage information", that activity plans as intended by Thanasis belong precisely to this domain, and therefore there's no need to add another extension. Because if you model this domain, you do not model activity plans in the generic sense of social life, e.g. having the plan to rob a bank (CRMsoc), nor plans of how to digitize things (CRMdig), but a rescue plan for museum objects in case of flood.
Not that I want to contradict you with this, but just raise once again the general question: shouldn't we have an in-depth discussion on the articulation of CRMbase and all its extensions, the mutual relations between them and their stricter specification, including explicit and visible indications of reference versions for each of them and minimal number of classes and propertes from CRMbase that should be there? so that these complex relationships are not only visible to informed specialists but to the entire community that wishes to use the model?
I try to figure out where this issue is expressed among the issues, there was a discussion in Cologne and we should have proposed to work on this under the lead of Christian Emil, if I remember well, about a core or similar, but I cannot find it now. And probably the discussion is ongoing, or solved, and I'm unaware of it.
But I think there is a real need for methodological clarification to avoid a growing community of users being confused by this already complex universe of extensions. And that it is more clearly visible where this issue is solved, if it is the case.
All the best
Francesco
In the 50th joint meeting of the CIDOC CRM SIG and SO/TC46/SC4/WG9; 43nd FRBR – CIDOC CRM Harmonization meeting, TV gave an outline of the issue –pointing to 3 directions:
- Activity plans to remain in CRMsoc –but they are not quite central to it.
- Activity plans to be reintroduced to CRMbase –definitely not core
- Activity plans to be made an extension in its own right –makes sense, only model that is future oriented
Discussion Points:
MD: Activity Plans and the Business Model (commercial transactions, that are important for museum documentation) should become part of the same extension.
CB: Harmonizing the Spectrum model backs option (3). The model documents transactions AND restoration activities/activity plans (as in retroactive techniques to apply, given a certain condition state). It’s a highly specialized model and it would encumber CRMbase infinitely to add to it all these classes and properties whereby to link them.
Proposal: to make Activity Plans a separate extension of CRM. This makes sense as it is a construct focusing on possible future events rather than past events mainly concerning the CRM and its extensions otherwise. (or core to an extension where things may be added/ like business transactions)
HW: reformulate the scope of the extension (intro text) and decide to work either on OntoMe or another system (despite the classes already being there).
Coordinator: TV
Group: SdS, MD, FB
DECISION: Once the scope of the extension has been formulated, close the issue. A new space on the website has to be created for this model, CRMact (suggested name).
June 2021
Post by Thanasis Velios (1 February 2022)
Dear all,
Please find attached the version of CRMact which is submitted here for approval at the next SIG. Scope notes have been agreed already but please check the introductory text and bring comments to the meeting.
Many thanks to Vincent for the OntoMe support which made this work easier and to George for his comments.
All the best,
Thanasis
In the 52nd joint meeting of the CIDOC CRM SIG and ISO/TC46/SC4/WG9; 45th FRBR - CIDOC CRM Harmonization meeting; TV walked the SIG through the current state of the issue (he was assigned to draft the scope of the CRMact, which he did and circulated it through the mailing list).
Proposal: vote to accept the scope and then close this issue and move ensuing open topics of discussion to new issues. Discuss where it will go on the site
Discussion points:
- The previous decision for 419 was that CRMact will be a stand-alone extension for the time being, there might be dependencies with CRMbiz and CRMsoc, to be re-examined in the respective issues.
- Compartmentalizing family models is a good thing, it allows classes and constructs that for some reason or another no longer naturally fall within the scope of some model to still be implemented (we can still provide migration paths to them), before coming up with a definitive solution –recall FRBRoo classes that form no longer an integral part of LRMoo.
- a text illustrating the purpose of linking event templates only to types of entities, without specifying instances thereof should be added
Decisions:
- to accept the scope as it is (as a starting point) & upload the document (Definition of CRMact; an extension of CIDOC-CRM to support activity plans –Version 0.2) on the site under a designated space (CRMact) .
- generate a new space on the site for CRMact, which will be maintained by TV -CB to arrange with FORTH the creation of the designated sub-site and grand TV access to edit it
- All issues for CRMact will refer to CRMact v0.2
Issue Closed