PROBLEM:Relationships Within GJXDM

July 28, 2005

From:Scott Edson

Scott Came

Winfield Wagner

Joe Mierwa

PROBLEM:Relationships within GJXDM

RECOMENDATION:GJXDM accurately model the semantics (not be arbitrary)

Discuss the following at next face to face

This is a hybrid approach that still allows relationships to be represented by inclusion. This is mainly to satisfy the following concerns raised by Winnie and others.

• Performance/memory hit to processing instances with pointing all over the place favor relationships by inclusion

• Natural readability and understanding of instances (a primary goal of the GJXDM) favor relationships by inclusion

The key features of the hybrid approach are:

1. Relationship objects are defined as separate types in the schema.

Examples: RoleType, InterpersonalRelationshipType, AffiliationType.

2. Each relationship type would have at least one element of type ReferenceType, to "point to" the related object. For example, RoleType might have elements person and activity; AffiliationType could have elements person and organization. We believe InterpersonalRelationshipType would have further subtypes depending on the nature of the relationships. For instance, SpouseType would have two reference elements: one called husband, the other called wife. But SiblingType would have one element, called sibling, that occurs 2..*. In general, for relationship types, the GJXDM pattern of optional/overinclusive elements should be tightened down for whatever makes semantic sense. That is, the husband element within SpouseType should not be 0..unbounded, because there is no situation anywhere in which that makes sense (or is there, Utah?)

3. Each relationship type would optionally have other elements as needed. For instance, SpouseType and AffiliationType might have a start and end date.

4. It is still an open issue whether the relationship types should be generically named (e.g., "RoleType") and then further qualified by an element bound to a codelist that describes it further (e.g., "AO=ArrestingOfficer"), or whether types of Roles should be identified by the name of the type (e.g., "ArrestingOfficerType extends RoleType"). The WIJIS view that Joe Mierwa and George Pasdirtz shared with us in Atlanta leans towards the former... Most of us lean this way and Scott Came is on the fence. The approach would allow users to limit or control the usable roles for an object through the constraint schema associated with a document subset schema.

5. Now, for the hybrid part. An element of each relationship type would be included as an optional element within each of the related types. That is, both PersonType and ActivityType would include an element of type RoleType (called "role"). For those who like to do inclusion, they would use the included element in whichever type is the more natural "owner" of the relationship. (Scott Came don't favor doing this, for instance, we don't know which spouse is the more natural "owner" of the relationship.) Winfield Wagner makes the argument that the event, activity or document type being generated by the agency will identify the natural owner of the relationship. For example, in a field interview the Person Type with role of Subject will own Person Type of role Acquaintance since the primary person of interest is the Subject of the interview. When using the included Role element, the reference element inside the relationship type that points to the including structure would be disallowed. For instance, if you include role under ActivityType, then in that situation RoleType/activity must not appear.

6. If you don't do inclusion, then you simply tie the two related objects together by using the appropriate relationship type object as their peer.

7. There is no question that this hybrid approach is complex, which is why Scott Came still favors the simpler approach of not including relationships within the related object structure. It doesn't make semantic sense, and forces this complex rule upon us. And most of us don't believe the performance/memory impacts are really that much of an issue (having implemented many of these things.) But it's the best we could do in terms of compromise.

What follows below is XML examples from Scott Came (support of #6 above) and a problem use case examples from Winnie (support #5 above).

Example 1:

Scott is John's friend

GJXDM 3.0.2:

<jxdm:Person>

<jxdm:PersonName>

<jxdm:PersonFullName>John Aerts</jxdm:PersonFullName>

</jxdm:PersonName>

<jxdm:PersonSocialFriend>

<jxdm:PersonName>

<jxdm:PersonFullName>Scott Edson</jxdm:PersonFullName>

</jxdm:PersonName>

</jxdm:PersonSocialFriend>

</jxdm:Person>

Note how the choice of including Scott within John (rather than vice versa) is totally arbitrary, and requires a rule in the GJXDM architecture that says this kind of inclusion does not infer semantic meaning. This is awkward, and should be removed from GJXDM if possible.

Proposed solution:

<jxdm:Person jxdm:id="JA">

<jxdm:PersonName>

<jxdm:PersonFullName>John Aerts</jxdm:PersonFullName>

</jxdm:PersonName>

</jxdm:Person>

<jxdm:Person jxdm:id="SE">

<jxdm:PersonName>

<jxdm:PersonFullName>Scott Edson</jxdm:PersonFullName>

</jxdm:PersonName>

</jxdm:Person>

<jxdm:PersonSocialFriendRelationship>

<jxdm:RelationshipEffectivePeriod>

<jxdm:RelationshipBeginDate>2004-07-27</jxdm:RelationshipBeginDate>

</jxdm:RelationshipEffectivePeriod>

<jxdm:FriendReference jxdm:ref="JA"/>

<jxdm:FriendReference jxdm:ref="SE"/>

</jxdm:PersonSocialFriendRelationship>

Example 2 (more involved):

Scott Edson is employed by the LA County Sheriff, is assigned to LA County ISAB, and is a member of the XSTF

John Ruegg is the Director of LA County ISAB

Scott's wife Melanie and John's wife Michele are friends

GJXDM 3.0.2:

<jxdm:Person>

<jxdm:PersonName>

<jxdm:PersonFullName>Scott Edson</jxdm:PersonFullName>

</jxdm:PersonName>

<jxdm:Employment>

<jxdm:EmploymentEmployer.Organization>

<jxdm:OrganizationName>LA County Sheriff</jxdm:OrganizationName>

</jxdm:EmploymentEmployer.Organization>

<jxdm:EmploymentAssignedUnit.Organization>

<jxdm:OrganizationName>LA County ISAB</jxdm:OrganizationName>

<jxdm:OrganizationPrincipalOfficial>

<jxdm:PersonName>

<jxdm:PersonFullName>John Ruegg</jxdm:PersonFullName>

</jxdm:PersonName>

<jxdm:PersonSpouse jxdm:id="SR">

<jxdm:PersonName>

<jxdm:PersonFullName>Michele Ruegg</jxdm:PersonFullName>

</jxdm:PersonName>

<jxdm:PersonSocialFriendReference jxdm:ref="ME"/>

</jxdm:PersonSpouse>

</jxdm:OrganizationPrincipalOfficial>

</jxdm:EmploymentAssignedUnit.Organization>

</jxdm:Employment>

<jxdm:PersonAffiliationOrganization>

<jxdm:OrganizationName>XSTF</jxdm:OrganizationName>

</jxdm:PersonAffiliationOrganization>

<jxdm:PersonSpouse jxdm:id="ME">

<jxdm:PersonName>

<jxdm:PersonFullName>Melanie Edson</jxdm:PersonFullName>

</jxdm:PersonName>

<jxdm:PersonSocialFriendReference jxdm:ref="MR"/>

</jxdm:PersonSpouse>

</jxdm:Person>

Now, a couple of semantic difficulties with this:

1. What if we're representing some kind of history of Scott Edson or John Ruegg here? We have no idea when the various relationships were in effect. Or anything else about them.

2. The fact that John Ruegg's identity is contained within a hierarchy under the definition of Scott Edson is semantically (not to mention socially) awkward. It's totally arbitrary. The fact that John Ruegg is the director of ISAB and Scott Edson is assigned to ISAB are completely independent (or at least mostly so...maybe the next director wouldn't like this Scott Edson guy, and so they are in fact linked!) Yet the semantics of the hierarchy imply a link. The goal of the proposed approach is to disentangle these concepts.

3. The hierarchical-inclusion awkwardness gets worse with John's wife, Michele. Imagine what would happen to this structure if she was invited to join the XSTF, and in a moment of weakness accepted the invitation.

4. What if we included the PersonSocialFriendReference in the MR structure, but not in the ME structure? Does that imply that Michele thinks they're friends but Melanie doesn't? (Certainly not...probably just an oversight.) This is where the RDF-triple pattern breaks down semantically, at least when implemented in XML Schema.

5. I'm sure you recognize that this is not at all a contrived example (in terms of complexity) when you think about information in the intel world...

Proposed solution:

<jxdm:Person jxdm:id="SE">

<jxdm:PersonName>

<jxdm:PersonFullName>Scott Edson</jxdm:PersonFullName>

</jxdm:PersonName>

</jxdm:Person>

<jxdm:Person jxdm:id="ME">

<jxdm:PersonName>

<jxdm:PersonFullName>Melanie Edson</jxdm:PersonFullName>

</jxdm:PersonName>

</jxdm:Person>

<jxdm:Person jxdm:id="JR">

<jxdm:PersonName>

<jxdm:PersonFullName>John Ruegg</jxdm:PersonFullName>

</jxdm:PersonName>

</jxdm:Person>

<jxdm:Person jxdm:id="MR">

<jxdm:PersonName>

<jxdm:PersonFullName>Michele Ruegg</jxdm:PersonFullName>

</jxdm:PersonName>

</jxdm:Person>

<jxdm:Organization jxdm:id="LACS">

<jxdm:OrganizationName>LA County Sheriff</jxdm:OrganizationName>

</jxdm:Organization>

<jxdm:Organization jxdm:id="ISAB">

<jxdm:OrganizationName>LA County ISAB</jxdm:OrganizationName>

</jxdm:Organization>

<jxdm:Organization jxdm:id="XSTF">

<jxdm:OrganizationName>XSTF</jxdm:OrganizationName>

</jxdm:Organization>

<jxdm:SpouseRelationship>

<jxdm:HusbandReference jxdm:ref="SE"/>

<jxdm:WifeReference jxdm:ref="ME"/>

</jxdm:SpouseRelationship>

<jxdm:SpouseRelationship>

<jxdm:HusbandReference jxdm:ref="JR"/>

<jxdm:WifeReference jxdm:ref="MR"/>

</jxdm:SpouseRelationship>

<jxdm:EmploymentRelationship>

<jxdm:RelationshipEffectivePeriod>

<jxdm:RelationshipBeginDate>2004-07-27</jxdm:RelationshipBeginDate>

</jxdm:RelationshipEffectivePeriod>

<jxdm:EmployerReference jxdm:ref="LACS"/>

<jxdm:EmployeeReference jxdm:ref="SE"/>

</jxdm:EmploymentRelationship>

<jxdm:AffiliationRelationship>

<jxdm:RelationshipEffectivePeriod>

<jxdm:RelationshipBeginDate>2004-11-01</jxdm:RelationshipBeginDate>

</jxdm:RelationshipEffectivePeriod>

<jxdm:AffiliatedOrganizationReference jxdm:ref="XSTF"/>

<jxdm:AffiliatedPersonReference jxdm:ref="SE"/>

</jxdm:AffiliationRelationship>

<jxdm:EmploymentRelationship>

<jxdm:EmployerReference jxdm:ref="ISAB"/>

<jxdm:EmployeeReference jxdm:ref="JR"/>

<jxdm:EmploymentRelationshipDescription>Director</jxdm:EmploymentRelationshipDescription>

<jxdm:EmployeeIsPrincipalOfficialIndicator>true</jxdm:EmployeeIsPrincipalOfficialIndicator>

</jxdm:EmploymentRelationship>

<jxdm:PersonSocialFriendRelationship>

<jxdm:RelationshipEffectivePeriod>

<jxdm:RelationshipBeginDate>2004-07-27</jxdm:RelationshipBeginDate>

</jxdm:RelationshipEffectivePeriod>

<jxdm:FriendReference jxdm:ref="ME"/>

<jxdm:FriendReference jxdm:ref="MR"/>

</jxdm:PersonSocialFriendRelationship>

While a little more verbose in terms of tags, the benefit is that the semantics are not arbitrary, and are perfectly clear.

Problem Use Cases

One of the major obstacles for further successful acceptance and implementation of the GJXDM standard is the current means of establishing associations or relationships between the information components (complex types) when constructing reference documents. Currently, associations between components are dependent on complex type tag names that represent a relationship between two complex type elements. This association can either represent an “IS A’ or ‘HAS A’ relationship between two complex type entities. For example:

An Incident ‘HAS A’ an IncidentSubject that ‘IS A’ Subject and the Subject ’IS A’ Person.

The following diagram illustrates how Incident inherits its related information about the Person through its inherited ‘IS A’ and ‘HAS A’ relationships with other complex components:

The same relationship can be represented using a different inheritance relationship path and still conform to the GJXDM standard In this case:

An Incident ‘IS A’’ Activity, that “HAS A ‘ AcivitySubject, that ‘IS A’ Subject and the Subject ’IS A’ Person,

The inheritance path is now:

The difference between the two hierarchal paths shown in the two diagrams has no impact on collecting data about the person but it does impact the process of capturing the association of the information between the incident complex type and the person complex type elements.

This becomes more of a critical issue in developing reference schemas and applications when one begins to add additional complex type relationships to represent a Field Investigations Report. In the following example, the Charge and Statute captured in the Field InvestigationsReport can be represented through a multitude of conforming paths:

Here a just a few of the different paths and element names defined by different document types.

Group / Path / Complex Type Element Name
Charging Document / Case\CaseCharge / CaseCharge
Sentencing Order / Charge / Charge
Field Interview / Activity\ ActivityCrimePotentialCharge / ActivityCrimePotentialCharge
Incident / Arrest\ArrestCharge / ArrestCharge

As more and more complex type packets of information (incident location, associated person, vehicle location, person employment, etc.) are added to the reference model for a Field Investigations Report, it is more complicated to discover all the inheritance paths that conform to the GJXDM standards and that path changes with each document schema created by the criminal justice community.

These problems increase when there are no complex types (tag names) available within the GJXDM hierarchy to represent a specific domain ‘IS A’ or ‘HAS A’ relationship between information packets. There are a number of current solutions to this problem. The simplest approach allows one to embed any complex type object, such as a Vehicle into an existing complex type tag name, as shown in the following:

<j:Person >

<j:PersonElements {A,B,C}>

<j:Vehicle>

<j:Vehicle Elements {D,E,F}>

</j:Vehicle>

</j:Person>

</FieldInterview>

This is an acceptable approach as long as the complex type inherits directly from the Super Type complex type object (highest level) of the GJXDM model. The only problem with this approach is the ‘IS A’ or ‘HAS A’ relationship is not defined in the structure of the schema and or instance of the information packet. It also will not validate against the GJXDM.

To define the relationship and its meaning within the context of the information packet, the current solution is to create a new complex type tag name that either inherits information from an existing GJXDM tag through type substitution or cascading extension of an existing complex type. For example, in a Field Investigation vehicle information may be included in the report. The information for the vehicle could be connected to the person by substituting a new complex type definition for the Person as follows:

<j:Person xsi:type=”new:PersonType” > ***type substitution***

<j:PersonElements {A,B,C}>

<j:Vehicle>

<j:Vehicle Elements {D,E,F}>

</j:Vehicle>

</j:Person>

</FieldInterview>

The second method is to create a new cascading extension of a Person object that includes new tag names for both the Person and Vehicle as follows:

<my:Person >

<j:PersonElements {A,B,C}>

<my:PersonVehicle>

<j:Vehicle Elements {D,E,F}>

</my:PersonVehicle>

</my:Person>

</ FieldInterview >

These are just a few examples of the special conditions or adjustments that are currently allowed by GJXDM when attempting to present relationships between information entities within a hierarchical single schema structure.

The community of practitioners and technologists that has attempted to implement GJXDM reference documents has discovered an additional issue. There is confusion on how to utilize the Activity complex type element that plays a major role within the representation of a document. There are many complex type tag names that are of type of Activity but the Activity provided little of its own elements to the parent. It appeared that the Activity is used only as a hierarchical connector to other entities such as Person, Charge, Location, etc. The method in which the Activity is embedded in the hierarchical path added additional path complexity to reference document construction.

The bottom line problem is that a single hierarchical single schema structure model, like GJXDM, does not provide the flexibility to accurately compose documents or transaction instances that are based on the day-to-day information exchange process. During the horizontal review of reference documents created by the SEARCH/COPS workshops, the participants recognized the following impediments in utilization of the GJXDM for real world applications:

The current hierarchical inheritance paths, existing in the GJXDM, are not robust to accurately portray the relationships between entities during the processes of collecting and exchanging information between exchange partners or domains.
As other domains, such as emergency services or transportation, begin to utilize the GJXDM, the ability to identify relationships between information packets or core components of information, required by the hierarchal structure, will add more confusing to the model.
The current approaches that handle newly defined compositional relationships that do not exist in the hierarchal structure impede the development of open standards applications.
Development of reference documents and applications are still in the ‘one off’ mode and as more users defined custom relationships (extensions) the further the criminal justice environment moves away from an integrated standard of sharing information.

Currently, practitioners, technologists, and industry standards groups are searching for a method to disassemble the GJXDM hierarchical (one schema model) into some form of component standard without losing the foundations established by the current model of the GJXDM. The OASIS Justice Integration XML Technical Committee has veered towards work done by the Universal Business Language TC for guidance on development of a component model. This standard, based on the ebXML Core Component Technical Specification 2.01, utilizes Core Components (CC) and Business Information Entities (BIEs) structures that are modular, reusable and extendable.