[Crm-sig] Modelling an Actor carrying out an action at the Behest of Another

George Bruseker george.bruseker at gmail.com
Fri Apr 17 11:12:48 EEST 2020


Dear Martin,

Thank you for your feedback. Here are some follow up reflections.



> So next potential solution. I think that p14.1 in the role of, won't cut
> it, because that would only point to a role 'diplomat' 'conceptual
> modeller' whatever. This does not create the relation to the instance of
> E39 actor which the E21 acts on behalf of/under the auspices of.
>
> We can use two P14 carried out by links, in which the activity is that of
> the Group P14.1 in the role of : "employer", and P14.1 in the role of:
> "implementer".
>
> This describes well the incidental connection between employer and
> employee in actions on behest of the employer.
>
> Note, that all such proposals should be documented, and a good practice of
> role types be collected!
>


I don't think this solution fully works because if one is working for one
organisation that is doing a job for another one, then one gets

E7 Activity "Lawn Mowing"
pc01i is domain of PC14 Carried Out by pc02 carried out by E21 "George
Bruseker"
pc01i is domain of PC14 Carried Out by p14.1 in the role of E55
"implementer"
pc01i is domain of PC14 Carried Out by pc02 carried out by E74 "Conceptual
Lawn Mowers R Us"
pc01i is domain of PC14 Carried Out by p14.1 in the role of E55 "Employer"

We already don't have a direct connection between the E74 and the E21. I
have to mentally infer it. This especially comes out if we add the next
actor, the one who is actually paying:

pc01i is domain of PC14 Carried Out by pc02 carried out by E21 "Lee M.
Citizen"
pc01i is domain of PC14 Carried Out by p14.1 in the role of E55 "Employer"

Now I have no machine decidable way of deciding who is employing who, but I
suppose it would be a reasonable documentation scenario to put just exactly
this.


> Alternatively, and compatible with that, would be a description of an
> overarching activity of the Group, such as "Conceptual Modelling Research"
> at FORTH ICS CCI, and my individual works as "forms part of" the larger one.
>

 This sounds like the suggestion of Rob which is great if that kind of
analytic documentation is being carried out, but in many scenarios it will
not be. The individual doing the documentation can only note the facts that
are before them. A represented B. They could, in principle, also create
event records for the total activity of an organization, but in principle
they are probably even loathe to document separately the organization
itself qua entity. So while the model may be sound semantically, it takes a
distance from actual documentation practice.

>
> Another option would be to do event partioning and then say that the
> person participated in a sub activity in which they were 'representing' x.
> I also think this creates a lot. of complication and is not self
> explanatory as a modelling solution (half the time you should look for
> actors carrying out the activity under p14 and half the time under a sub
> event of E7 with a special type).
>
> That is actually not a problem. See above. I would not use a
> "representing" x, but "forms part of". I think the concept of an
> overarching activity is very clear. The "part of" implies the "on behest
> of". .
>
> We always need to complement search by deductions, inferences between the
> general and the specific. Therefore "half the time you should look for
> actors carrying out the activity under p14 and half the time under a sub
> event of E7 with a special type" is not an argument at all. The closure of
> all reasonable paths is what people must look at. A good practice guide
> should enumerate such solutions.
>
I think frustrated software designers and non semantic savvy end users
(almost everyone) may see this issue less expansively.


> The solution is monotonic in two directions, which is very important:
>
> A) start with the individual activity, not knowing on who's behalf. Adding
> later a forms part of.
>
> B) start with the Group activity, not knowing the implementer. Adding
> later the subactivity.
>
> The same holds for the two roles solution above.
>
In the real scenario I describe, the problem is not that the documentarist
does not know on whose behest the person is working, it is that they do not
and are not going to create separate records of the entire activity of an
organization separate from that organisation in order to make the CIDOC CRM
modelling work. So in order to use the part of type modelling proposal they
need to create a node for the 'whole activity of organization x' which is
in fact a useless node because it will be a blank hidden node that will get
recreated many times to satisfy the model, but will in the knowledge base
just create endless duplicate 'whole activity of organization x' nodes
which not only don't help retrieval but hinder it.

 My general problem with the portioning solution, however, has two parts.

a) if we endorse both the p14.1 in the role of and the partitioning by E7
Activity for this very basic human and documentation phenomenon, then in
CIDOC CRM it is as if we have created irregular verbs. So it is like having
created Esperanto but then immediately adding in irregular verbs to spice
it up. To me this is not ideal. A sentence of the form 'Bob played the role
of Y in Activity X' should ideally have one translation in CRM (or a long
cut and a shortcut which are logically equivalent). Perhaps it is too
purist.

b) the partitioning solution may get called on to do too much. So I think
of the DOREMUS example, which is great. There, because the actions of each
individual in the performance have so many variables, a partitioning is
performed so that each player in the orchestra performs their own
individual activity within the whole.  Beautiful. The principle of
partitioning is also clear. Ah, but what now, if in my dystopian present,
some of the players in the band are commissioned or paid for, or stand for
some other organization. The 'Pepsi sponsored violinist'. Now I must also
do partitioning in this overall orchestral act but whereas before I had one
principle of partitioning (role as musician in the musical whole of the
performance) now I have two (role as brand sponsor in advertising
campaign). So Sally the violinist whom plays the first violin in one act
must in a different act (or in a sub act of this act, or maybe the
sponsorship is the overall act of her sub act and her performance the sub
activity of the sponsored activity) perform the being sponsored
relationship.

>
> So I don't find any of my imagined solutions very satisfactory. What do
> other people think? Does anyone have a solution that I haven't thought of
> with existing CRM mechanics? If there isn't a pre-existing solution, do you
> ideas on how to cover this scenario?
>
> I encounter it relatively frequently.
>
> One solution I could imagine would be a new .1 type property off the PC14
> class that would be something like 'as representative of'. I am not wedded
> to such a solution, but I suggest it because I think it might link to a
> more general issue that it is difficult to express 'manner' in a
> grammatical sense with CRM and somehow the .1 properties aid with this
> important kind of construct.
>
> I do not like it, because it sounds linguistically nice, but leaves the
> form of representation under-determined. It cannot distinguish between
> representing an organisation, such as a procuration, and carrying out a
> task as employee.
>
I think a common scenario (the typical knowledge state of the documentarist
in the culture heritage institution) would be of having this level of
underdetermined knowledge (which is yet knowledge!) and only very
particular research being able to recover more details. So this could be
the first pass of knowledge and then if researchers came in they could
document the activities of the group that is being represented and then
eventually contracts signed that lead to the particular motivated
activities, but in the meantime this basic level of knowledge captured.

Again I'm not wedded to the solution, but I do see problems with the above
formulations, at least for the scenarios I have at hand.

Cheers,

George
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20200417/985704ff/attachment-0001.html>


More information about the Crm-sig mailing list