[Crm-sig] ISSUE: sequence of modelling steps (Modelling an Actor carrying...)

Martin Doerr martin at ics.forth.gr
Mon Apr 20 16:03:11 EEST 2020


Dear George, All

On 4/17/2020 11:12 AM, George Bruseker wrote:
> 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
I think we should not go for a cure-all solution. What you describe is 
what I meant by commission. I think contractual service provision should 
not be attributed to the activity of the commissioner. I was a bit 
sloppy with "employer". You can find a better term. If you have leased 
labour, the one who is in command of what is done should be the second P14.
>
> 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.

Well, all this can be detailed. Nothing forbids you to add the 
membership of the Group. One concern is who's activity it is.

If work is commissioned, the service provider is responsible for the 
details. Then, I'd argue we have two distinct activities, one motivated 
by the other.

>     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.

This is an argument that I cannot follow in this simple form, it 
actually violates our methods in CRM-SIG.

The CRM does not aim at natural language analysis. I am not aware of 
real life situations, in which no further context is known than "A 
represented B". In case of ambiguity, we need multiple models. The CRM 
representation must be unambiguous, and not carry linguistic ambiguity 
with it.

Any real modelling discussion must come with relevant and sufficient 
context data. Our method is, to give access to sufficient records and 
contextual information BEFORE any attempt of modelling to the group of 
discussion. Please provide complete evidence. Of course I never do 
question the existence of applications referred on this list, which 
should be obvious.

The ontological analysis comes prior to any other consideration.

> 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.
That was never an argument for CRM-SIG. We always made arguments to 
improve actual practice, if the effort can be justified. If the effort 
can be justified, can only be outcome of a thorough ontological analysis.
>
>>
>>     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.

Well, it is a question of know-how. These inferences run perfectly in 
ResearchSpace, and we have an even more flexible tool at FORTH close to 
be released. If software designers are frustrated, we can offer 
tutorials. Then, the non semantic savvy end users will not see any 
problem. The need of multiple possible paths has been understood in 
CRM-SIG since many years. "unique" solutions have generally failed so 
far for information integration.(I assume a triple store or graph 
database. If you talk about other systems, I should know in order to 
make a qualified statement.)

A good practice guide is needed, and cannot be replaced by sloppy 
modelling. The library community has many years of experience, how to 
make globally interoperable precise data. They rely on cataloguing rules.

>     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.
Then please share these data with us!
> 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.

I lost you. If you add ten thousand times the 'whole activity of 
organization x' of the same organization, it will create only one node 
in the KB (RDF triple store or graph database). May be we talk about 
different kinds of data bases??

Further, I proposed the solution A for those cases, , i.e., two P14 
links, and not an unknown activity of X. It has the same complexity as 
your "represented".

>
>  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.
Definitely, see above. As a Group, we can only make qualified statements 
if you lay sufficiently data open. The "one translation" idea has been 
abandoned by CRM-SIG long ago, due to overwhelming evidence. May be 
someone can help digging out respective documentation. There was a paper 
long ago that maintained that the CRM is useless, because it does not 
provide unique translations, and proposed a much smarter model, that 
avoided the problem.
>
> 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.

See above. I definitely did not support the partitioning solution as a 
general cure-all, just the opposite..

>>
>>     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.

Well, since I have no knowledge of your context, I cannot comment more. 
But I assume a basic knowledge of the kind of representation involved 
must exist. Even if you start with an unqualified "represents", and 
later more evidence will come up, you may end up with a non-monotonic 
solution, and non-unique representations.

A new .1 type property off the PC14 class that would be something like 
'as representative of' may be misleading, because makes PC14 a 
subactivity on behest of someone. The activity itself should be "on 
behest of", and not the way one Actor is involved. Anyway, I do not see 
how we can cover with one term a range from leased workers to liaison 
persons in committee meetings and contracted service provisions.

>
> 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.

I think this is an interesting issue. If we want to take it up 
seriously, we should start with the sequence:

A) provide a relevant complete data set. Representative samples with 
complete context published to the Group (In the past, we required that 
prior to discussing any solution). If there are confidentiality or IPR 
issues, this must be clarified first.

B) provide the research questions ("competency questions"), i.e., how is 
the documentation typically used. (We had 160 documented competency 
questions for CRMbase in 2002, as deliverable for the European Project 
CHIOS)

C) Deep ontological analysis: Relevant ontological distinctions, 
exploring the width of the problem.

D) Reduction of the ontological distinctions relevant to the given 
research questions, and those that become apparent discussing distinctions.

E) Implementation of the schema (following steps described already in 
the Principles document).

F) User guides, how to deal with "loathe and non-savvy users"

I kindly ask all the group to respect these principles for any issue 
that does not offer an immediately satisfactory solution. Such 
discipline is helpful for the long-term quality of our Model, and saves 
a lot of time and misunderstandings in communication, in particular 
maintaining the right sequence of arguments.

I therefore I make an ISSUE here: CRM-SIG should create a methodological 
document, apparent on the Site, with title "Guidelines for Submitting a 
Modelling Issue", explaining these steps and making proposals how e-mail 
discussions can be structured to make the progress apparent.

All the best and thank you for your detailed thoughts on that!

Martin

>
> Cheers,
>
> George


-- 
------------------------------------
  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: martin at ics.forth.gr
  Web-site: http://www.ics.forth.gr/isl

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20200420/32f877a2/attachment-0001.html>


More information about the Crm-sig mailing list