# Presentation: 322612

## Justice XML Data Dictionary Schema

**Justice XML Data Dictionary Schema**
**Implementation Design and Structure**

## XSTF Assumptions 

**Design / synthesize ****common set of reusable, extensible data components****for a Justice DD to facilitate standard information exchange in XML.**
**Components should enable building XML schemas for:****	****Documents**** (persistent business records)****	****Data transactions**** (transient data/info for query/response)**
**Generalize**** for large justice community – do NOT target specific applications.**
**Provide ****reference-able**** schema components primarily for**** schema developers****.**
**Justice XML DD and Schema will ****evolve**** – will be ****changed / extended****.**
**Best extension method = ****minimum impact**** on prior schema/code investments.**
**Implement / represent**** domain relationships**** so they are globally understood.**
**(Technical dependencies in requirements and solutions) + (****time constraints ****of National priorities and demands)**** = (need for ****rational trade-offs****)**

## Highlights of XSTF Issues Considered

**A standard Justice XML DD Schema**
**Requirements (e.g., use cases)**
**Object-oriented approaches & extension mechanisms**
**Data model & rules for sizing & structure of objects**
**Standard named types and elements**
**Reference architecture and namespaces**
**Version control data and mechanism**
**Business context components & containers**
**Representation of domain relationships**
**Representing data constraints, codes, & special semantics**
**Other metadata**
**Applicability of other XML and data related standards**
**Future / emerging XML and Internet technologies**

## Issues (1)

**Implement a ****standard XML schema**** ****for the Justice XML Data Dictionary (DD).**
**Define ****requirements**** (e.g., use cases).**
**Define ****data model, rules, ****and**** rationales**** ****to guide component sizing, data structuring, and relationship cataloging.**
**Implement ****sub-class base with composition**** (multiple inheritance is required).**
**Implement ****global element names**** with globally understood meaning (local elements optional).**

## Issues (2)

**No aliasing**** / no component synonyms.**
**Define standard ****named types**** – from which ****all standard elements are derived.**
**Define ****value constraints**** & ****standard codes**** ****(e.g. NCIC tables).**
**Define a ****schema**** ****reference architecture**** ****to organize ****namespaces****.**
**Design ****version**** data mechanism in schemas and instances for compatibility id & control.**

## Issues (3)

**Monitor and deploy ****future XML technologies**** when appropriate.**
**Taxonomies or ontologies are unnecessary****; ****rule-guided, consistent, unambiguous design ****of component names, definitions, and structures should suffice.**
**Store / distribute ****DD in common format**** (e.g. Access & PDF).  Generate DD schema from DB.**
**Define ****metadata**** requirements.  ****Inherit common metadata from root object.**

## Issues (4)

**Define standard ****business container objects ****and components ****in DD and DD Schema.**
**Incorporate ****external data definitions**** / schemas****from expert organizations (when they exist).**
**Consult other applicable ****standards****, including:**
**Federal XML Schema Developer’s Guide (Apr02)**
**Universal Data Element Framework (UDEF) – ****17 property words**
**ISO/IEC Standard 11179 ****Specification & Standardization of Data Elements**

## Issues (5)

**Identify / define ****core**** (top-level) objects.**
**Establish ****rules/rationale**** for defining, component size and structure ****(i.e., what *****HAS-A***** parts should ****each consist of?).  **
**Component structure and global meaning are closely related to element naming conventions and may require changes to RDD names in future versions. **

**Issues (5)**

## Issues (6)

**Identify / define / classify relationships.**
**Example categories of relationships:*****core***** – inherent property, defines very nature, ****	*****CONSISTS-OF, HAS-A, IS-PART-OF, IS-A******fundamental***** – not core, but used often; ****	****always together, tight coupling*****domain***** – not fundamental, but specific; ****	****important for particular functions*****associative***** – unspecified or difficult ****	****to specify, loose coupling**
**What ****standard used to represent ****and implement****relationships? New representations?  ****One method for all or different for each ?**** **

**Issues (6)**

## Issues (7)

**How is extensibility ****defined****?  **
**How is local extensibility defined?  **
**How are data dictionary and XML schema extensions and modifications handled?**
**What analysis can determine the ****best method for extension/modification****? **
**Is an appropriate criterion for extension ****least impact of change on (in priority order):  ****	****	****(1) validation of XML schemas / instances****	****	****(2) applications code****	****	****(3) other impacts?**

**Issues (7)**

## Issues (8)

***Range***** – between 20 and 25 years old**
***Numeric precision***** – 5ft 3in vs. 5ft  ****(How is precision defined?)**
***Units***** – feet, inches, meters, ****centimeters, and conversions **
***Partial values***** – Phone number ends in ****"–3111" but *****AreaCode*****+*****Prefix***** unknown.**
***Null****** categories***** – ****unknown, none, N/A, null value, etc.**

**Issues (8)**

## Issues (9)

**Create new element names (<alias>, <moniker>, etc.) ****all *****NameType  *****(not recommended)**
**Create new element in *****PersonType***** name=”NameCategory” ****enumerating alias, moniker, etc.  (recommended)**
**Create new attribute in *****NameType***** name=”NameCategory” ****enumerating alias, moniker, etc.  ****(OK ... BUT ... Federal XML Schema Developer's Guide ****says avoid use of attributes)**

**Issues (9)**

## Person Type

**Subject**

**Person**

**LegalEntity**

**SuperObject**

**Citizen**

**Official**

**Suspect**
**Criminal**

**Juror**
**Witness**
**Victim**

**CJPers**
**Officer**
**Lawyer**
**Judge**

**UniqueID**

**Name**

**LegalName**

**BioMetricID**

**AssignedID**

**PhysicalID**

**DNA**
**FingerPrint**
**PalmPrint**
**DoB**
**BloodType **

**Gender****Height**
**Weight**
**EyeColor**
**HairColor**
**Photo**

**SSN**
**PersIDNo**

**Prefix**
**FirstName**
**MiddleName**
**LastName**
**Suffix**
**FullName**

**ContactInfo**

**Residence**

**Medical**

**Employment**

**CautionInfo**

**NonGovtOrg **

**GovtOrg **

## Sample Objects and Relationships

**Person**
**Organization**
**Agency**
**Location (address, lat/long, ...)**
**Contact Info (tel, fax, email, ...)**
**Property**
**Weapon**
**Vehicle**
**Other**
**Incident**
**Accident**
**Case**
**Event**
**Conviction**

**Person ******** Organization**
**	****Works_for**
**	****Affiliated_with**
**	****Supervised_by**
**	****member_of**
**	****leader_of**
**	****customer_of**
**	****Owns**
**	****Arrested_by**
**	****Convicted_by**
**	****incarcerated_by**
**	****booked_by**

**Person ******** Person**
**	****Works_for**
**	****Affiliated_with**
**	****Supervised_by**
**	****leader_of**
**	****customer_of**
**	****Arrested_by**
**	****Convicted_by**
**	****incarcerated_by**
**	****booked_by**
**	****family (father_of)**
**	****work (works_for)**
**	****seen_with**
**	****victim_of**
**	****business_partner_of**
**	****committed_crime_with**

**Core Objects**

**Relationships**

**Relationships**

## XSTF Plan

**Release Justice XML DD Schema (JXDDS) v1.0.0****	**** ****	****direct implementation of RDD v1.0.0**** ****	****	****reference-able schema components****	****normative (standard) schema forms ****	****reusable named type definitions****	****global element names & definitions****	****passes XML schema validator**
**Release JXDDS v1.1.0 –****	****	****	****	****	****	****UpperCamelCase for types & elements per****	*****Federal Developer’s XML Schema Guide Apr02***
**Develop / release XSLT migration package –**** ****	****compatibility between JXDDS v1.0.0 ******** v1.1.0**
**Develop JXDDS v2.0.0 –implements core objects****    ****	****and relationships per recommendations of XSTF **
**Develop XSLT or other migration package v1.1 to v2.0**
**Develop JXDDS v3.0.0 –implements standard****	****	****global domain relationships with W3C RDF**
**Develop XSLT or other migration package v2.0 to v3.0**

## JXDDS 3.0 Work Plan

_**Proposal**_**:  In 90 days, tie together several independent justice XML efforts.**
_**Tasks**_**:**
**ID set of core objects.**
**ID metadata to be inherited (on values, elements, types).**
**ID standard elements (from RDD and other sources).**
**Design rules for object (type) size and structure.**
**Design rules for naming elements (based on ISO Std 11179).**
**ID and classify primary domain relationships.**
**Design rules for relationships (RDF Block vs. composition).**
**Prototype and test RDF Block for relationships.**
**Develop and formalize rules for extension.**
**Build JXDDS 3.0 using RDD ****& ****current document schemas as input.**
**Build XML documents that adequately represent justice domain and:**
**employ prototype JXDDS 3.0**
**define business context components inside documents**
**employ RDF Block for domain relationships in documents**
**As available, all products to be placed on GTRI website as RFC by XSTF+.**