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: mar...@ics.forth.gr
Web-site: http://www.ics.forth.gr/isl
_______________________________________________
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
