[ICA-EGAD-RiC] Relationships in RiC

[Pitti, Daniel V. (dvp4c)]

Dear Chris,

Thank you very much for beginning the discussion, and in particular for focusing on relations. 

I think you are correct in saying that the current list of relations under each of the high-level entities is not a conceptual model. I would say that working our way to the relations being properly conceptually modeled is underway but by no means complete. The list as is, however, would not be a good implementation specification because, as you point out repeatedly, it is redundant. The list, in fact, comes from a much shorter list of unique types, expanded to make explicit each possible relation of each entity, as domain, to each of the other entities, as range. We did this to make it easy for a reader to explore the possible ways each entity may be related to the other entities. (We also assumed that some people would be alarmed at the length of the list!). Aside from the methods we use to develop and maintain the relations, we are contemplating, that the relation types ought to be expressed in at least two ways in the printed model: an ordered list (alphabetical?), classified by conceptual type (along the lines you suggest in your classification below, though more in a minute), with among other bits to be decided, clear definitions; and then additional lists (tables, really), one for each entity, giving the available relations for each entity to each of the other entities. Also, I think, it would be good to make the relation types available as an online reference resource, to enable searching and exploring from multiple perspectives. We would welcome suggestions in this regard. 

The unique list of types used to generate the repetitive lists as given, by the way, would make a better implementation specification.

The need to classify and conceptually organized the types is very much on our agenda. I think your first pass very good, but others have been suggested. Gavan McCarthy advocated categorizing them to me a while back, though we have not had a chance to pursue his suggestions. And more recently, Ken Thibodeau did the same, with a suggested approach based on UML. And so a good open discussion that leads to rough consensus (“I can live with that”) if not absolute consensus, would be very welcome. I think it would be a great opportunity to push our understandings and the model to greater clarity. Also, to make consensus easier to achieve, it is perfectly possible that some relation types might, in fact, be classified in more than one way. I have not thought this through, but it is almost always the case when the set of things to be classified is sufficiently complex, that a strict classification frequently leads to dilemmas. 

As for “associated with.,” you state that "We’ve used that for years as a cop out for making links where we are too lazy or too uncertain to be specific.” I do think it certainly can be used when one is lazy. The model has no cure for that! But it also may be used as a matter of economy, when someone simply does not have the time to investigate further. And finally, it may well be the case there is sufficient evidence to say that A and B are associated with one another, but not enough evidence to be more specific. Further, I would argue, as unsatisfying as “associated with” may be, it is actually quite powerful to know that A and B, as two entities floating around the universe, are somehow associated as opposed to not knowing it. Of course we would want to say “based on this evidence,” as the assertion that A and B are related needs to be based on evidence, sparse though it may be at the time of the assertion. (We have not yet modeled being able to say that Agent A (holding the Position …) asserts that A and B are related based on this evidence (say, a specific record). It is on the agenda.

Again thank you for initiating this discussion. 

Regards,
Daniel 


> On Sep 17, 2016, at 5:32 AM, Chris Hurley <descriptionguy at gmail.com> wrote:
> 
> Someone has certainly been busy - 792 relationships and still counting.
> Phew!  I read somewhere that a diligent German historian was only able to
> find 210 reasons for the fall of the Roman Empire.  We certainly got that
> beat.  This is a list of implementation options rather than a conceptual
> model – some of the logical possibilities when designing and implementing
> an application.  To explore the full range of possibilities, two things are
> needed :
> 
>   1. the underlying relationship-types must be identified;
>   2. the terms must be defined (cf. p.39) so that we all interpret the
>   words in the same way.
> 
> Then we can pay more attention to refining or expanding those concepts that
> are currently being most contested (e.g. “create”) and to discovering
> additional instances (e.g. “received by” under Transmission, “involved
> party” under Formation, “adopted (by)” under Existential Features, etc.).
> But it is more important to conceptualise than to itemise, therefore (by
> way of example):
> 
> One could begin with a thesis (inviting the antithesis) that provenance is
> to be found in Relationship-Type : Formation (see below).  This could be
> tested by examining whether the 63 instances listed so far are, in fact,
> acceptable statements of provenance and whether any other ideas about
> provenance, of the kind that have been put forward lately in the
> literature, can fit within the instances listed or require additional
> instances to accommodate them.  Is provenance only to be found within
> Formation?  Are there formative relationships that are not allowable
> statements of provenance?  Can provenance be found in other
> Relationship-Types?  Does a formative relationship between Agents
> ("establish", for example) confer ambient provenance vicariously on a
> document-type?  If so, how would that differ from "uses [agent-delegate]"
> which I have nominated as Existential?  Alternatively, should ambience and
> provenance be kept conceptually separate? Does the Relationship-Type
> framework assist or hinder in (re)defining or (re)imagining our core
> concepts such as provenance.
> 
> 
> I have trouble with two of the proposed entity-types (viz. Date and Place)
> of which more anon, so I can’t yet come to terms with those proposed
> relationships involving one or other or both of those (204 out of the
> total).  Interestingly, I singled these two out as problems long before I
> reached p.91 where Date and Place are also nominated as "properties" of
> relationships so maybe I'm not alone in needing to think some more about
> them.  And I don’t think it’s worth dwelling long over the
> relationship-type “associated with” (292 out of the total).  We’ve used
> that for years as a cop out for making links where we are too lazy or too
> uncertain to be specific.  Anything can be associated with anything and,
> once you’ve said that, there’s not much more to say and little benefit from
> saying it 292 times.  Of the remainder, here is my first attempt at a
> categorisation into relationship-types (without the benefit of certainty as
> to what any of the terms mean):
> 
>   -
> 
>   Relationship-Type : Formation (63 instances) viz. “create/created by”;
>   “authored”; “collect(ed); “wrote/written”; results from/in”; “accumulate”;
>   “assemble”; “arrange”; “establish”.
>   -
> 
>   Relationship-Type : Governance (42 instances) viz. “owns/owned by”;
>   “rights held”; “controls”; “directs”; “manages”; “superior/subordinate”.
>   -
> 
>   Relationship-Type : Succession (22 instances) viz.
>   “successor/predecessor”; “parent/child”.
>   -
> 
>   Relationship-Type : Belonging (30 instances) viz. “part/part of”;
>   “member of”; “is/has example”.
>   -
> 
>   Relationship-Type : Possession (12 instances) viz. “held/holder”.
>   -
> 
>   Relationship-Type : Transmission (4 instances) viz. “sent by”.
>   -
> 
>   Relationship-Type : Documentary Features (73 instances) viz. “copy of”;
>   “draft/original of”; “subject of”; “addressee”; “documentary form”;
>   “evidence of”.
>   -
> 
>   Relationship-Type : Existential Features (57 instances) viz. “has/had
>   functional relation”; “assumed identity”; “sibling/spouse”; “uses
>   [agent-delegate]”; “pursues/occupies [position or occupation]”; “fulfils
>   [function]”; “performs [activity]: “authorize(d)”; “required competency”;
>   “defined/revised [by mandate]”.
> 
> There is, of course, much room for debate (e.g. is “authorize” an instance
> of the Governance or Existential type?).  Nevertheless, I would find
> discussion at that level more rewarding than simply multiplying instances
> before something like that has been done.
> 
> All the best
> 
> Chris Hurley
> www.descriptionguy.com
> _______________________________________________
> ICA-EGAD-RiC mailing list
> ICA-EGAD-RiC at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/ica-egad-ric