470 likes | 500 Views
This document provides an in-depth examination of the WIJIS messaging model, including associations, existing mechanisms, proposed solutions, and a WIJIS-specific solution with a focus on Object-Relational Mapping. It discusses issues like object inclusion vs. separation, object reference, aggregation vs. composition, and associations within the context of WIJIS Federated SOA Workflow and the WIJIS Index. It highlights the need for more sophisticated mechanisms to handle reflexive relationships and better translation between objects and database entries.
E N D
WIJIS Messaging Model G. W. Pasdirtz, Ph.D., WIJIS Joe Mierwa, Visionair
Agenda • High Level Overview • Associations • Current mechanisms • Proposed Solutions • A WIJIS solution • GJXDM Object-Relational Mapping Issues • Object Inclusion vs. Object Separation • Object Reference • Aggregation vs. Composition • Associations
The WIJIS Index • Relies on a Publish/Subscribe model • Does NOT extract data from ODSs or Data Warehouses • Is NOT a data mart • It is a pointer system optimized for searching
GJXDM & NIEM NIEM 1.0 U-Core GJXDM 3.X Core HomelandSecurity Justice Other
Multiple Message Models • XML-DOC: incident, arrest, citation, etc. • XML-RPC: query • XML-DB: publish to the WIJS index • Flat File: SOA Class C Systems
Object-Relational Mapping XML Schema (XSD) Object Schema (UML) RDB Schema (SQL) Object-Relational Mapping XML Data Binding
Problem Statement • Existing GJXDM mechanisms are too simplistic to reflect information kept in the Index • Don’t handle reflexive relationships very well • Don’t translate very well from objects into database entries
Activity “I saw the whole thing” Bob2 (EnforcementOfficialType) Bob1 (WitnessType) “Bob” “Bob” “Investigator” Existing Mechanism #1 • XML-DOC Object Inclusion • Also referred to as hierarchical inclusion ActivityWitness ActivityOfficial.Enforcement Same-As WitnessAccountDescriptionText PersonName ActivityOfficial.Enforcement PersonName
Example: Object Inclusion Instance <WIJIS namespace stuff goes here xsi:schemaLocation="http://schemapathdefinition/WijisIndex.xsd"> <Activity j:id="ActID1"> <ActivityID>4-00-09796-0399-181</jdd:ActivityID> <ActivityDate>2000-08-23</jdd:ActivityDate> <ActivityEndDate>14:31:00</jdd:ActivityEndDate> <ActivityOfficial.Enforcement ID=“PID1”> <PersonName><PersonFullName>Bob</PersonFullName></PersonName> <EnforcementOfficialTypeText>some text </EnforcementOfficialTypeText> <EnforcementOfficialBadgeID> <ID>1234</ID> <EnforcenmentOfficialBadgeID> <EnforcementOfficialUnit ID="OID1" > <OrganizationID><ID>1234</ID></OrganizationID> <OrganizationName>NameText</OrganizationName> </EnforcementOfficialUnit> </ActivityOfficialEnforcement <j:ActivityWitness ID=“PID1”> <PersonName><PersonFullName>Bob</PersonFullName></PersonName> <WitnessID></WitnessID> <WitnessAccountDescriptionText></WitnessAccountDescriptionText> <WitnessDate></WitnessDate> </j:ActivityWitness> </Activity> </WIJIS> Objects are included within the Activity. ID value indicates they are the same person.
Existing Mechanism #2 • Use of references • Also referred to as Aggregation
Example: References Instance <WIJIS namespace stuff goes here xsi:schemaLocation="http://schemapathdefinition/WijisIndex.xsd"> <Activity j:id="ActID1"> <ActivityID>4-00-09796-0399-181</jdd:ActivityID> <ActivityDate>2000-08-23</jdd:ActivityDate> <ActivityEndDate>14:31:00</jdd:ActivityEndDate> <ActivityOfficialReference.Enforcement ref=“PID1”/> <j:ActivityWitnessReference ref=“PID2” /> </Activity> <EnforcementOfficial ID=“PID1”> <PersonName><PersonFullName>Bob</PersonFullName></PersonName> <EnforcementOfficialTypeText>some text </EnforcementOfficialTypeText> <EnforcementOfficialBadgeID><ID>1234</ID></EnforcenmentOfficialBadgeID> <EnforcementOfficialUnit ID="OID1" > <OrganizationID><ID>1234</ID></OrganizationID> </EnforcementOfficialUnit> </EnforcementOfficial> <j:Witness ID=“PID2”> <PersonName><PersonFullName>Bob</PersonFullName></PersonName> <WitnessID></WitnessID> <WitnessAccountDescriptionText></WitnessAccountDescriptionText> <WitnessDate></WitnessDate> </j:Witness> </WIJIS> Objects are referenced from the Activity.
Object Separation • Role.Of (Georgia Tech) • XML-DB • Single Association Table (NDEx)
Activity “I saw the whole thing” Bob2 (EnforcementOfficialType) Bob1 (WitnessType) Bob3 (PersonType) “Bob” “Investigator” Role.Of Data Graph ActivityWitness ActivityOfficial.Enforcement WitnessAccountDescriptionText Role-Of Role-Of ActivityOfficial.Enforcement PersonName
Role.Of Instance <WIJIS namespace stuff goes here xsi:schemaLocation="http://schemapathdefinition/WijisIndex.xsd"> <j:Activity> <j:ActivityWitness j:id="b1"> <j:RoleOf.Person j:id="p1"> <j:PersonName> <j:PersonGivenName>Bob</j:PersonGivenName> </j:PersonName> </j:RoleOf.Person> <j:WitnessAccountDescriptionText> I saw the whole thing </j:WitnessAccountDescriptionText> </j:ActivityWitness> <j:ActivityOfficial.Enforcement j:id="b2"> <j:RoleOfReference.Person j:ref="p1"/> <j:EnforcementOfficialTypeText>Investigator</j:EnforcementOfficialTypeText> </j:ActivityOfficial.Enforcement> </j:Activity> <WIJIS>
Role-Of Issues • Does not handle all possible associations between objects. • E.g. GJXDM field EmploymentEmployer could be modeled as RoleOf.Employer. • However • EmploymentAssignedUnit.Organization, describing association between person object & assigned unit in an organization • Not a good fit for Role.Of modeling • Nor does EmploymentLocation • An association between person and organization location
NDEx Approach • NDEx proposes to handle missing associations in GJXDM via: • Single Association Table • Codes • AssociationCodeOrganizationType • Includes codes for • Unknown, Other, None, Affiliate, Contractor, & Sub-contractor. • AssociationCodeOrganizationLocation • Include codes for Unknown, Other, None, Physical Street Address, Mailing Address and Billing Address. • AssociationCodeOrganizationPerson • Includes codes for Unknown, Other, None, Owner, Full-time Employee, Part-time Employee, Contractor and Member. • Etc… • Approach is a hybrid • IncidentVictim & IncidentWitness handled via references instead of codes describing association of person with incident.
Single Association Table UML NDEx proposes a single association table using references & codes
Single Association Table Instance <!-- Person Location Association --> <i:Association j:effectiveDate="1999-07-15"> <i:AssociationSubjectReference j:ref="PID1"/> <i:AssociationObjectReference j:ref="LID1"/> <i:AssociationCode.PersonLocation> 3 </i:AssociationCode.PersonLocation> </i:Association>
Question • Can GJXDM constructs such as IncidentVictim & IncidentWitness be eliminated in favor of association codes? • Would lose data related to association • WitnessAccountDescriptionText field. • More modeling could handle this problem • Document object with PersonActivity association coded as “statement”.
Associations - I • In theory, many possible associations between GJXDM objects exist • For indexing, most important associations derive from relationships to activity • ActivityPerson (victim, witness), • ActivityProperty (seized property) • ActivityOrganization (ActivityClearer.Organization) • ActivityDocument (incident report) • ActivityLocation (ActivityLocation) • Associated GJXDM attributes are in parentheses.
Associations - II • There are also many direct relationships of interest • PersonOrganization (EmploymentEmployer) • OrganizationPerson (OrganizationPrincipalOfficial) • PersonContactInfromation (PersonDayContact) • OrganizationContactInformation (OrganizationDayContact) • PersonLocation (EmploymentLocation) • OrganizationLocation (OrganizationLocation) • PropertyPerson (PropertyTitleHolder.Person) • PropertyLocation (PropertyLocation)
Associations - III • There are also relationships between the same object • Referred to as Reflexive assocations • PersonPerson (PersonAlias) • OrganizationOrganization (OrganizationSubunit) • DocumentDocument (document correction) • ActivityActivity (previous incident).
WIJIS Solution • Extend GJXDM to handle object relationships using multiple association tables • One for each of the associated objects • Facilitates mapping for indexing databases • Semantics of the associations are more easily modeled
Schema Snippet - I … <xs:complexType name="AssociationType"> <xs:attribute ref="j:ref"/> </xs:complexType> <xs:complexType name="ActivityActivityType"> <xs:complexContent> <xs:extension base="ext:AssociationType"> <xs:attribute name="code" type="codes:ActivityActivityCodeType" default="none"/> </xs:extension> </xs:complexContent> </xs:complexType>
Schema Snippet - II <xs:simpleType name="ActivityActivityCodeType"> <xs:restriction base="xs:token"> <xs:enumeration value="unknown"/> <xs:enumeration value="other"/> <xs:enumeration value="none"/> <xs:enumeration value="activity_previous_incident"/> <xs:enumeration value="activity_related_incident"/> <xs:enumeration value="activity_previous_court"/> <xs:enumeration value="activity_related_case"/> <xs:enumeration value="activity_related_activity"/> </xs:restriction> </xs:simpleType>
Schema Snippet - III <xs:complexType name="ActivityType"> <xs:complexContent> <xs:extension base="j:ActivityType"> <xs:sequence> <xs:element ref="ext:ActivityActivity" /> <xs:element ref="ext:ActivityDocument“ /> <xs:element ref="ext:ActivityLocation" /> <xs:element ref="ext:ActivityOrganization" /> <xs:element ref="ext:ActivityPerson" /> <xs:element ref="ext:ActivityProperty" /> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType>
XML-DB Instance <WIJIS > <Activity id="ACTID1“> <ActivityPerson ref=“PID1” code=“witness”/> <ActivityPerson ref=“PID1” code=“enforcement_official”/> </Activity> <Person id="PID1" > <PersonName> <PersonFullName>Bob</PersonFullName> </PersonName> <PersonOrganization ref=“OID1” code=enforcement_official”/> </Person> <Organization id="OID1> <OrganizationORID><ID>1234</ID></OrganizationORID> <OrganizationName>Local PD</OrganizationName> </Organization> </WIJIS>
Object-Relational Map • Very straightforward CREATE TABLE WIJIS ( WIJISID INTEGER PRIMARY KEY, reportingOrganizationText VARCHAR(124) NOT NULL, reportedDate DATE NOT NULL, reportedTime TIME NOT NULL, sourceIDText VARCHAR(124) NULL, sensitivityText VARCHAR(124) NOT NULL, commentText VARCHAR(124) NULL, distributionText VARCHAR(124), RECEIVEDDATE DATE NOT NULL, RECEIVEDTIME TIME NOT NULL ) CREATE TABLE ACTIVITY ( ACTID INTEGER PRIMARY KEY, WIJISID INTEGER NOT NULL, ActivityID VARCHAR(12) NOT NULL, ActivityDate DATE NOT NULL, ActivityEndDate DATE NULL, FORIEGN KEY (WIJISID) REFERENCES WIJIS (WIJISID) ) Each object has table with Primary & Foreign key related to parent object
Association Mapping • Mapped in a similar manner • Have 2 foreign keys CREATE TABLE ACTIVITYACTIVITY ( CODE VARCHAR(24) NOT NULL, ACTAID INTEGER PRIMARY KEY, ACTID1 INTEGER NOT NULL, ACTID2 INTEGER NOT NULL, FOREIGN KEY (ACTID1) REFERENCES ACTIVITY (ACTID), FOREIGN KEY (ACTID2) REFERENCES ACTIVITY (PERID) )
XML-RPC Instance • For queries, association codes are used for searching <?xml version="1.0" encoding="UTF-8"?> <WIJIS_PersonSearch> <Person PersonName=”Martha Stewart" > <ActivityPerson code="arrest_subject"/> </Person> </WIJIS_PersonSearch>For queries,
Relational DB Storage • Unstructured Storage • Entire XML document stored entirely as Character Large Object (CLOB). • Provides • rapid throughput • document fidelity • flexibility. • Document processing can be expensive • Document Object Model (DOM)-level operations are required.
Relational DB Storage • Structured Storage • Provides many advantages • Optimized memory management • Xquery and Xpath capabilities • Reduced storage requirements • B-tree indexing and in-place updates. • Schema annotations used to control storage of XML collections: • CLOB - XML text stored in a Character Large Object. • VARRAY in a LOB - Each element converted into database-native object. • VARRAY as Nested Table • Each element converted into database native object • Stored as set of rows in Index Organized Table (IOT). • VARRAY of REF XMLType as LOB - Each element treated as separate CMLType value. • VARRAY of REF XML Type as Nested Table - Each element treated as separate CMLType value stored as Nested Table