1 / 47

WIJIS Messaging Model

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

rodh
Télécharger la présentation

WIJIS Messaging Model

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. WIJIS Messaging Model G. W. Pasdirtz, Ph.D., WIJIS Joe Mierwa, Visionair

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

  3. The Context

  4. WIJIS Federated SOA

  5. Workflow

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

  7. GJXDM & NIEM NIEM 1.0 U-Core GJXDM 3.X Core HomelandSecurity Justice Other

  8. GJXDM Shallow Objects

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

  10. Object-Relational Mapping XML Schema (XSD) Object Schema (UML) RDB Schema (SQL) Object-Relational Mapping XML Data Binding

  11. The Problem

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

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

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

  15. Existing Mechanism #2 • Use of references • Also referred to as Aggregation

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

  17. Proposed Solutions

  18. Object Separation • Role.Of (Georgia Tech) • XML-DB • Single Association Table (NDEx)

  19. Role.Of UML

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

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

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

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

  24. Single Association Table UML NDEx proposes a single association table using references & codes

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

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

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

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

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

  30. Associations

  31. The WIJIS Approach

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

  33. Multiple Association Tables

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

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

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

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

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

  39. Association Mapping

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

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

  42. Has It Become Too Complicated?

  43. Alternatives

  44. Does It Matter?

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

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

  47. Questions?

More Related