Microsoft PowerPoint - Justice XML Technical 1Apr2003.ppt

April 2003

Justice XML Data Model

Technical Overview

April 2003

Why Justice XML Data Model Version 3.0?

• Aligned with standards (some were not available to RDD)

• Model-based Æ consistent

• Requirements-based – data elements, processes, and documents

• Object-oriented Æ efficient extension and reuse

• Expanded domain (courts, corrections, and juvenile)

• Extensions to activity objects/processes

• Relationships (to improve exchange information context)

• Can evolve/advance with emerging technology (RDF/OWL)

• Model provides the basis for an XML component registry

that can provide

• Searching/browsing components and metadata

• Assistance for schema development/generation

• Reference/cache XML schemas for validation

• Interface (via standard specs) to external XML registries

April 2003

Design Principles

• Design and synthesize a common set of reusable, extensible

data components for a Justice XML Data Dictionary (JXDD)

that facilitates standard information exchange in XML.

• Generalize JXDD for the justice and public safety communities

– do NOT target specific applications.

• Provide reference-able schema components primarily for

schema developers.

• JXDD and schema will evolve and, therefore, facilitate change

and extension.

• Best extension methods should minimize impact on prior

schema and code investments.

• Implement and represent domain relationships so they are

globally understood.

• Technical dependencies in requirements, solutions, and the

time constraints of national priorities and demands will require

rational compromises.

April 2003

What Standards Apply?

XML.gov Draft Federal XML Schema Developer’s Guide (04/02)

ISO / IEC 11179 Specification & Standardization of Data Elements

UN / CEFACT ebXML Core Components Technical Spec 1.9 (12/02)

ASC X12 Reference Model for XML Design (10/02)

FBI Electronic Fingerprint Transmission Spec v7 (01/99)

ANSI / NIST Data Format for Interchange of Fingerprint, Facial, & SMT

OASIS XML Common Biometrics Format Committee (09/02)

Dept of Navy Draft XML Registry Requirements (09/02)

DoD DoD 5015.2-STD Design Criteria Std for E-RMS Apps (06/02)

IC Intelligence Community Metadata Language (ICML)

DC Dublin Core metadata for documents

W3C XML Schema Specification (05/01)

W3C RDF and RDF Schema Specification (02/99)

April 2003

Justice XML Data Dictionary Components

Activity ~45%

(other objects ~55%)

Activity ~45%

(other objects ~55%)

Location

Contact

Info

Contact

Info

Property

other

Document

Relationships

ReferenceDocument.xsd

Content

Metadata

Registry

Metadata

Infrastructure

Metadata

Person

Organization

IS-A

April 2003

Assembling the Pieces

Doc.xsd

Incident

Rpt

Incident

Rpt

Booking

Rpt

Booking

Rpt

Charge

Doc

Charge

Doc

Case

File

Case

File

Arrest

Warrant

Arrest

Warrant

Arrest

Rpt

Arrest

Rpt

Protect

Order

Protect

Order

Sentence

Order

Sentence

Order

Activity

Pers

Loc

Cnt

Prop

Org

???

Doc

Relate

Incident

Activity

Investigate

Arrest

Book

Confine

Prosecute

Indict

Adjudicate

Sentence

Incarcerate

Bond

Supervise

Release

Charge

Pardon

Parole

Fine

April 2003

Justice XML Data Dictionary v3.0 Database Statistics

JXDD v3.0 (April 2003)

Complex types 300

Elements 2,000

JXDD v3.0 (April 2003)

Complex types 300

Elements 2,000

Total components 2,300

RDD v1.0.1 (October 2002)

Complex properties 30

Simple properties 250

RDD v1.0.1 (October 2002)

Complex properties 30

Simple properties 250

Total components 280

According to one government data consultant, all branches and departments

of a typical state government use about 20,000 unique data elements.

According to one government data consultant, all branches and departments

of a typical state government use about 20,000 unique data elements.

Source requirement references = 35

Source requirement components = 16,000

Source requirement references = 35

Source requirement components = 16,000

April 2003

XML Namespace and Versioning

<?xml version="1.0" encoding="UTF-8"?>

<xsd:schema

targetNamespace= "http://www.it.ojp.gov/jxdd/prerelease/rap/2.3.0/rap.xsd"

xmlns:xsd= "http://www.w3.org/2001/XMLSchema"

xmlns:jxdd= "http://www.it.ojp.gov/jxdd/prerelease/3.0.0.0/jxdd.xsd"

xmlns:rap= "http://www.it.ojp.gov/jxdd/prerelease/rap/2.3.0/rap.xsd">

<xsd:import

namespace= "http://www.it.ojp.gov/jxdd/prerelease/3.0.0.0/jxdd.xsd"

schemaLocation= "http://www.it.ojp.gov/jxdd/prerelease/3.0.0.0/jxdd.xsd" />

<xsd:element name="RapSheet">

. . .

</xsd:schema>

April 2003

Basic Concepts and Terminology

XML schema: Concept:

• Type • Object/Class

• Element • Property

XML instance: Reality:

• TagName • Instance of Class

• Value of TagName • Value of Property

• XML Types define data structure

• XML Elements define data semantics

April 2003

Named Types vs. Elements

Question: Why define standard named types?

Answer

: At times you will want to compare (similar) object instances with different

semantic meanings but with same syntax and structure. If they are of the same type

then you can easily compare or operate on them.

Example

: ArrestDate and ReleaseDate have different semantic meaning. But it is easier

to compute a time interval between them if they are both of the same data type (date).

Question

: Why define standard elements?

Answer

: To discourage different element names for the same data concept (instance type).

Users want to recognize semantically equivalent elements (that have same meaning).

Also, enables users to define standard relationships and relate data objects more easily.

Examples

: Are SentencingOrder and DispositionOrder the same?

How can software understand the difference between OrganizationID and AgencyID?

Question

: Why is inheritance useful?

Answer

: Organizes objects by their common properties (elements).

Allows software to treat objects with common properties in a uniform way.

Object types may share a common definition (eliminates duplicate definitions).

Extension mechanism for adding new properties is intuitive (the way we think).

Example

: Can treat all “conveyances” (vehicles) in a uniform way.

April 2003

is-a

Type

has-a

Element

Object Model Example

with inheritance

Object Model Example

with inheritance

PersonType

BirthDate

LastName

OrganizationType

FirstName

ConveyanceType

LocationType

is-a

has-a

is-a

SuperType

MetaDataText1

has-a

JudicialOfficerType

GovtOrgType

SubjectType

CommercialOrgType

ArrestDate

BarID

AddressType

is-a

BarIssueDate

CautionText

is-a

NOTE: Element and type

names are to illustrate

inheritance and are not

necessarily compliant

with JXDD naming rules.

April 2003

Rules for Object Model Extension

1. A derived type may add (extension) additional fields

(elements / attributes) to its base type.

2. A derived type may restrict one or more fields of its base type,

but only so that a derived field is a subset of the field of the base type.

Examples

: A derived type may …

• restrict an enumeration from a large set of options to a smaller set of options,

as long as every option in the derived set appears in the base set.

• remove a field of the base type, but only if the field is optional in the base type.

• require a field to appear, but only if the field is optional or required to appear

in the base type.

3. A derived type may not modify a field of its base type such that it violates

the constraints of its base type.

Examples

: A derived type may NOT …

• add additional enumerations to a field.

• remove a field that is required by its base type.

• modify the type of a field of its base type.

Webb’s

Rules

Webb’s

Rules

To ensure inheritance hierarchy integrity and consistency:

April 2003

Vehicle Odometer Brand Code

ISO Standard 11179

Data Element Naming Syntax

ISO Standard 11179

Data Element Naming Syntax

Object Class Term

(leftmost)

Representation Term

(rightmost)

Property Term

(follows object class term)

Qualifier Term(s)

(optional)

ISO 11179 standardizes data dictionary design, names, definitions.

April 2003

1. Amount – Monetary value with units of currency.

2. BinaryObject – Set of finite-length sequences of binary octets.

(secondary: Graphic, Picture, Sound, Video)

3. Code – Character string that for brevity represents a specific meaning.

4. DateTime – Date+time; point in time.

(secondary: Date, Time)

5. Identifier – Character string used to establish identity of, and uniquely

distinguish one instance of an object within an ID scheme.

6. Indicator – Boolean (exactly two mutually exclusive values).

7. Measure – Numeric value determined by measurement with units.

8. Numeric – Assigned or determined by calculation.

(secondary: Value, Rate, Percent)

9. Quantity – Non-monetary numeric value or count with units.

10. Text – Character string generally in the form of words.

(secondary: Name)

Representation Terms

(ebXML Core Component Tech Spec v1.9)

Representation Terms

(ebXML Core Component Tech Spec v1.9)

April 2003

ISO Standard 11179

Element / Tagname Issues

ISO Standard 11179

Element / Tagname Issues

Syntax: [Q] Object [Q] Property [Q] Representation

Strict adherence to 11179 results in

• Longer data names (although easily translated by machines).

• Potential need for compression or translation (through tables).

• More elements (more for humans to remember, apps to understand).

• Precise element semantics (for a large-scale, multi-use standard).

• Reduced element dependence on context in instances.

• Elements are understood in isolatation or within context

(e.g. in a document or complex element container)

XML.gov Federal Guideline requires 11179-compliant tagnames.

If object term is omitted:

• XML nesting (or XPath names) can provide context in many instances.

• Additional reuse of tagnames (they are independent of object context)

• Length savings is minimal (object term is usually a single word).

• UBL moves tagname context (object term) into schema definitions.

April 2003

ISO Standard 11179 – Example (1)

Syntax: [Q] Object [Q] Property [Q] Representation

<PersonLastNameText>Kindl</PersonLastNameText>

</PersonName>

</Person>

<Name>

<LastNameText>Kindl</LastNameText>

</Name>

</Person>

XPath: /Person/Name/FirstNameText

April 2003

ISO Standard 11179 – Example (2)

Syntax: [Q] Object [Q] Property [Q] Representation

<PersonLastNameText>Kindl</PersonLastNameText>

</PersonName>

</ContainerElement>

<Name>

<LastNameText>Kindl</LastNameText>

</Name>

</ContainerElement>

Xpath: /ContainerElement/Name/FirstNameText

Person

Context

Missing

Person

Context

Missing

April 2003

<?xml version=“1.0” encoding=“UTF-8”?>

<InstanceRootElement

xmlns=“http://www.it.ojp.gov/jxdd/beta/3.0.0”

xmlns:ncic=“http://www.it.ojp.gov/jxdd/beta/ncic/1.0.0”

xmlns:aamva=“http://www.it.ojp.gov/jxdd/beta/aamva/1.0.0”

xmlns: . . . [ reference additional tables as needed ]

... >

<ncic:HUL>ML</ncic:HUL>

<aamva:BHMC>Fe</amvaa:BHMC>

</BoatHullMaterialCode>

Rusted Iron

</BoatHullMaterialText>

...

</InstanceRootElement>

XML Instance

External Enumerations (codes)

(1) Avoids maintenance of

numerous code tables

(2) Allows use and validation

of any code table

(3) Preserves code ownership

(4) Provides option for literal

(5) Similar to UBL method

BUT ... must have the codes!

(1) Avoids maintenance of

numerous code tables

(2) Allows use and validation

of any code table

(3) Preserves code ownership

(4) Provides option for literal

(5) Similar to UBL method

BUT ... must have the codes!

April 2003

Local_Instance.xml

Standard_Instance.xml

xmlns:xsi

W3C XML

Instance

W3C XML

Instance

namespace references

Schema Reference Architecture

W3C XML

Schema

W3C XML

Schema

Support

Types

Support

Types

Element and

Relationship Names

Element and

Relationship Names

Entity

Types

Entity

Types

xmlns:Justice

xmlns:Local

Standard

Tag Names

Standard

Tag Names

Data Types

that do not fit into

the class hierarchy

Data Types

that do not fit into

the class hierarchy

Primary Data Model

-- Class Hierarchy

Primary Data Model

-- Class Hierarchy

import

+ ns ref

ns ref

Reference Documents

e.g. Arrest Warrant

Reference Documents

e.g. Arrest Warrant

Local

Extension

Local

Extension

import

+ ns ref

import

+ ns ref

xmlns:xsd

April 2003

Justice XML Data Model

Functions and Capabilities

Justice XML Data Model

Functions and Capabilities

• Represents an object-oriented XML data model.

• Enables forms-based maintenance / reconfiguration.

• Automatically generates XML Schema for the JXDDS.

• Will automatically generate equivalent RDF Schema.

• Stores and maps data element requirements; this enables

• Tracing and tracking to source data components.

• Measurement by source data requirements.

• Maintains metadata for XML data dictionary registry.

• Provides search filters, maintenance forms, and tools.

April 2003

Entity-Relationship Diagram for Justice XML Model

SourceDataElement

Source

maps-to

from

Tracks data

requirements

Property

is-a

Type

is-a

has-object

has-subject

TypeFacet

has

Implements an

object-oriented

data model

Enables

RDF

April 2003

PersonLastName

Conceptual Basis

for the Justice XML Data Model

A simple example

Conceptual Basis

for the Justice XML Data Model

A simple example

PersonNameType

XML schema:

</sequence>

</complexType>

xsd:string

Subject

Property

Property’s

Subject Type

Property’s

Subject Type

Property’s

Object Type

Property’s

Object Type

Object

"Type PersonNameType

has-a PersonLastName

of type xsd:string"

"Type PersonNameType

has-a PersonLastName

of type xsd:string"

April 2003

SuperType

A Property (Defendant) with Multiple Object Types

(This example implements Court Filing Actor)

A Property (Defendant) with Multiple Object Types

(This example implements Court Filing Actor)

PersonType

IS-A

Object

OrganizationType

PropertyType

IS-A

Defendant

Object

<xsd:choice>

April 2003

Primary and Secondary Relationships

Containers

Documents & transactions

create local relationships

Relationships

Explicitly defined;

globally understood

Owns

Sold

Son_of

Viewed

Secondary

Data Objects

Object class

hierarchy built from

“is-a” and “has-a”

primary relationships

Primary

Relationships

April 2003

Secondary Relationships

Why are they necessary?

When should they be used?

Secondary Relationships

Why are they necessary?

When should they be used?

Use secondary relationship form of a property when:

• Convenient; do not want to “pollute” an object with

properties that are not inherently associated with it.

• Passing a set of standard objects (such as documents)

within a container and user must explicitly relate

imbedded objects between documents.

• Impossible to create primary property relationship

for a given situation.

April 2003

Primary Relationships (1)

Two object instances:

</Person>

</Person>

Two object instances:

</Person>

</Person>

Primary property, by nesting:

</Sister>

</Person>

Primary property, by nesting:

</Sister>

</Person>

April 2003

Primary Relationships (2)

Primary, by reference (ad nauseam):

</Person>

<SecondCousinOnceRemoved

ref="jill"/>

. . .

</Person>

Primary, by reference (ad nauseam):

</Person>

<SecondCousinOnceRemoved

ref="jill"/>

. . .

</Person>

Primary, by reference

</Person>

</Person>

Primary, by reference:

</Person>

</Person>

April 2003

Secondary Relationships

Secondary relationship:

</Person>

</Person>

</Person>

Secondary relationship:

</Person>

</Person>

</Person>

April 2003

Relationship Examples

Primary

Name

EyeColor

Make

Secondary

Owns

XML schema (concept):

• Type (Object/Class)

• Element (Property)

XML instance (reality):

• TagName (Instance of Class)

• Value of TagName (Value of Property)

April 2003

HTML

HyperText Markup Language

HTTP

HyperText Transfer Protocol

TCP / IP

Transmission Control Protocol

/ Internet Protocol

Intelligent Software Agents

decision + action

presentation

network

transmission

Semantic Web

The 3

Generation Internet

Semantic Web

The 3

Generation Internet

XML

eXtensible Markup Language

syntax +

content

syntax +

content

OWL

RDF / RDFS

Web Ontology Language

(based on DAML+OIL)

Resource Description

Framework and Schema

semantics +

inferencing

relationships

+ metadata

April 2003

Object

Subject

Property

Resource Description Framework

(RDF) Conceptual Model

Resource Description Framework

(RDF) Conceptual Model

The conceptual model for the database

representing the object-oriented

Justice Data Dictionary looks like RDF.

This is no coincidence!