FAQs
In NIEM, harmonization is a process for modeling and integrating new and existing data components in ways that remove duplication, resolve conflicts, reduce variation, and achieve consistency. The goal of harmonization is to bring new content into NIEM while reestablishing and maintaining standardization and uniformity across the data model under the NIEM Naming and Design Rules (NDR).
Upon identification of information exchange requirements, the process of mapping data elements to NIEM requires developers to search through the model to identify semantic equivalent elements between an organization's data set and the NIEM model. There are a number of ways to explore the model to aid this process: the Data Model Browser; several alternate model formats, such as spreadsheets and a database; the Subset Schema Generation Tool (SSGT); and third party toolsets.
The NIEM architecture consists of two sets of vocabularies-NIEM Core and the individual NIEM domains. NIEM Core includes "universal" components, concepts that are commonly understood across all (or the majority of) NIEM domains, such as person, activity, date, time, and location. The individual NIEM domains contain mission-specific data components that build upon concepts in NIEM Core.
The current NIEM release can be found here.
Data Model Browser is a great tool for the user to practice before they get into the real NIEM work. This tool create by GTRI developer team that associate along with the Subset Schema Generation Tool (SSGT). Before you get to this browser or receive an error while try to access to this tool, please follow the instruction below to configure your browser:
First, go to "Internet Options", click on "Security" tab on top, click on "Trust sites", and click on the "Sites" button. After that, you add the this site http://tools.niem.gov/ to here.
Download the JAVA Runtime Environment 7 version or above, and install on your computer.
Please unlock the pop-up to this site http://tools.niem.gov/
Federal Enterprise Architecture (FEA) is constructed through a collection of interrelated “reference models” designed to facilitate cross-agency analysis of services provided to citizens and to identify duplicative investments, gaps, and opportunities for collaboration within and across federal agencies.
Reference Models released by the Federal Enterprise Architecture Planning Management Office (FEAPMO) include:
• The Performance Reference Model (PRM), a standardized framework to characterize the performance of information technology (IT) initiatives and their contribution to program performance. PRM can help produce enhanced IT performance information to improve strategic and daily decision-making; improve the alignment and contribution of IT to outputs and outcomes, thereby creating a clear “line of sight” to results; and identify performance improvement opportunities across traditional agency boundaries.
• The Business Reference Model (BRM), which is a function-driven framework for describing the business operations of the federal government independent of the agencies that perform them. BRM provides an organized, hierarchical construct for describing the federal government’s day-to-day business operations.
• The Data and Information Reference Model (DRM) helps to describe the types of interactions and information exchanges that occur between the federal government and its various constituencies. It will categorize the government’s information along general content areas specific to BRM sub-functions and decompose those content areas into greater levels of detail, ultimately to data components that are common to many business processes or activities. DRM will establish a commonly understood classification for federal data and enable information sharing between agencies. A common data classification model will streamline the processes associated with information exchange, both within the federal government and between the government and its external stakeholders.
• The Service Component Reference Model (SRM) is a business- and performance-driven functional framework that classifies service components with respect to how they support business and/or performance objectives. SRM is intended for use to support the discovery of government-wide business and application service components in IT investments and assets.
• The Technical Reference Model (TRM), which is a component-driven, technical framework used to identify the standards, specifications, and technologies that support and enable the delivery of service components and capabilities. TRM provides a foundation to support the construction, delivery, and exchange of business and application or service components that may be used and leveraged in a Component-based or Service-oriented Architecture.
Taken together, the FEA reference models create a comprehensive government-wide framework to guide agency IT investment activities, identify opportunities to collaborate on and consolidate initiatives, and integrate government activities at the local, state, tribal, and federal levels.
XML elements have different types of relationships between each other. Primary relationships are the common XML relationships that exist between an xsd:complexType and its defining properties (elements and attributes that compose it and make it complex). The properties are generally inherent in the nature of the complexType being defined. For example, PersonNameType has several inherent properties, including PersonFirstName, PersonMiddleName, and PersonLastName. These properties are actually parts of or compose a PersonNameType. Any complexType can be built with all primary relationships. However, sometimes this is not possible, practical, or sensible, depending upon the situation.
Secondary relationships provide an alternate method for representing relationships. Secondary relationships exist between two fully attributed instances. A simple example is a family relationship between two persons. A secondary relationship mechanism enables you to create a FatherOf relationship between two fully attributed PersonType instances without having to define an XML complexType that requires one to be inside the other.
Alias, AKA, is the Name Category metadata being considered for use by the Intel Community Metadata Working Group Person Data Exchange Standard. After several discussions in the XML Structure TAsk Force (XSTF) regarding Alias and AKA, the language in the following example is considered to differentiate the two:
NameCategory Name NameCategory Context Terrorist Watchlist Person of Interest Data Exchange Definition Denotes that the name is a provided name, an alias, an aka, or, for systems that do not support the different meanings of alias and aka, ''aliasoraka'' Reference Reference Authority Identifier Version Draft 12-10-03 Cardinality 1 Representation Representation Category Character representation (ISO/IEC 10646) Form of Representation Code Datatype xs:NMTOKEN Maximum Size 12 Minimum Size 3 Layout of Representation Permissible Values ProvidedName,Alias,AKA,AliasOrAka Usage Examples Comment ProvidedName is the name which is obtained from the source of the record and which is not known to be an alias or aka name.
Alias is an alternative name that is suspected to be in use for deceptive purposes. AKA is an alternative name associated with the individual but not for deceptive purposes (e.g. nickname, street name). Aliasor AKA is used when it is not possible to determine whether the alternative name is an alias or aka.
When dealing with types that are derived from other types, the order is important in validating. For instance, if the schema has PersonGivenName before PersonSurName, it would not validate if the sequence is switched. How does a derived type get affected by this? For example, CaseOfficial is a CaseOfficialType. CaseOfficialType is derived from SuperType, PersonType, and JudicialOfficialType.
What should be the order of tags from any of the Base types should be so that the xml file still validates? The rule is that parent properties (in sequence) always come first. So, since CaseOfficialType extends JudicialOfficialType extends PersonType extends SuperType, then a CaseOfficial will have element properties defined in SuperType PersonType JudicialOfficialType CaseOfficialType, in that order, and sequenced as in each respective type. Attribute properties can be used in any order. T here has been much discussion and no resolution other than a recommendation to use sequence as the GJXDM suggests on where reference PersonGivenName is before PersonSurName .
There are several groups and individuals who believe that element sequence within a type is an unnecessary restriction. However, it depends upon how the instance is processed. If the program/parser traverses the hierarchy looking for each element in the hierarchy in sequence (PersonName, PersonSurName, PersonGivenName) then one must retain the sequence in your instances or the program/parser breaks. Those in favor of not validating based upon sequence consider this an antiquated restriction and a processing problem, not an XML problem. If the program/parser looks for Subject and then looks for PersonName and PersonSurName and PersonGivenName are unique within PersonName there does not have to be any particular sequence. As one goes up the hierarchy, PersonName should not have to appear in any particular order within Subject (a PersonType) but it must appear within Subject or it loses context.
XML Schema provides two constructs for tagging data in XML instances – elements and attributes. Which construct to employ is not always clear. While data can often be stored as attributes or elements, there are a number of constraints on attributes that generally impact one's decision:
· XML does not support specification of structure in attribute values; attribute values are just strings. Elements may contain additional structure as sub-elements or attributes.
·Attributes are not easily extended (for future changes). However, you can add additional sub-elements and attributes to an element through type subclassing and type substitution.
·Mixed content (mixing simple values and elements together) is hard to work with, and harder to specify. This means that properties of a simple data type must be included as attributes (in order to avoid having to use mixed content).
For this reason, GJXDM and NIEM take the approach of tagging most data in elements. Attributes are reserved generally for metadata.
Each external code table has a proxy schema whose only purpose is to add the metadata attributes on the SuperType so that they can be used with the properties that use those code values. The "base" contains the code values and the "base proxy" hooks (or adds) the SuperType metadata to the code (enumerated) elements. jxdm.xsd imports the base proxy (and adds the SuperType metadata) and the base proxy imports the base (and adds the values).
Here is an example that illustrates the concept of proxy schema. Suppose we want to specify the color of a person's eyes using the NCIC code for eye colors. The XML would look like
<Person></Person>
...
<PersonEyeColorCode>BLU</PersonEyeColorCode>
<Person>Person</Person>
<PersonEyeColorCode reporteddate="2004-01-01">BLU</PersonEyeColorCode>
It would have been easier if we could have directly added the metadata reference to the external type rather than creating a proxy type, but we are not the owners of the external types and namespaces and cannot change their data to suit our needs.
The Information Sharing Listserv is an electronic forum created for the purpose of developing and broadening the community of Justice XML expertise and support for the application of the National Information Exchange Model (NIEM) and consistent standards and practices in the information sharing industry. The Listserv promotes the exchange of ideas and experiences associated with information sharing projects and provides an opportunity to discuss lessons learned and implementation tips.
Who Should Join?
Justice and public safety practitioners, managers and policy makers; developers and programmers involved with building applications using NIEM; and local, tribal, state, federal, and private sector communities of practice who are involved in data integration efforts using XML can all find benefit in discussing information sharing in an open environment. Industry journalists and interested parties should also feel free to subscribe to the Listserv; however, topics are limited to industry-specific issues and may be moderated.
For more information on the Listserv membership and rules, please see https://bja.ojp.gov/program/it/policy-implementation/practitioners
The change log is a list of all the changes made in the current GJXDM release versus the old GJXDM release. It lists all the change and the associated bug number which have been entered in bugzilla. To find more information about the change user can click on the hyperlink associated to the bug number.
Namespaces are the solution to naming conflicts (also known as collisions) in XML. Using XML namespaces can help alleviate issues that arise where XML elements and attributes use identical names.
XML namespaces help to identify and resolve conflicts between elements that have the same name but mean different things. An XML namespace is a domain that contains a set of element declarations and type definitions.
An analogy is women's clothing sizes. A size eight is not always the same size eight, because women's clothing is designed in junior, misses, and petites. These various size eights, which may represent different specifications, can exist in several domains. To solve this issue, each domain will need to be identified with a different namespace.
Each XML schema provides a unique identification (ID) in the form of a Uniform Resource Identifier (URI), which can point to an external file that defines the namespace.
The URI may either be a Universal Resource Locator (URL), which points to a web server, or a Universal Resource Name (URN), which names a resource but does not specify a network object that can be de-referenced.
The URI is defined in the format illustrated below.
• The protocol part either specifies a real network transfer protocol, such as HTTP or FTP for a URL, or the string “urn:” for a URN.
• The host part specifies a registered host name, resolvable through Domain Name Service (DNS).
• The path part specifies a unique ID on that host, and its meaning is under the control of the parties that control the host.
Metadata, or data about data, provides detailed information that supports the actual content of data instances. Metadata may include details about the origination of data, when it was created, or who authenticated it. Metadata information also helps determine approximate information including the specification of ranges, precision, and patterns, as well as units of measure. The GJXDM/ NIEM metadata methodology uses the basic “Types/Property” scheme, but requires a bit of rigor when creating definitions. Failure to keep in mind the difference between simple and complex types will result in unexpected XML structures. The ability to attach metadata to any field is very important to support semantically rich information sharing. Metadata allows:
• All GJXDM/ NIEM domain systems to assemble data from various sources while maintaining the origination information.
• Systems to operate from business rules on data access, ownership, and dissemination that are defined by justice stakeholders.
• The collection of detailed information regarding when the data was generated, by whom, or how long the information must be
There are two basic kinds of relationships – an “is-a” relationship and a “has-a” relationship. In database design and object oriented program architecture, “has-a” is a relationship where one object "belongs" to another object, and behaves according to the rules of ownership. Multiple “has-a” relationships will combine to form a possessive hierarchy. This is contrasted with an “is-a” relationship which constitutes a different kind of hierarchy.
If Dog and Cat subclasses inherit directly from the mammal super class, the relationship is referred to as an "is-a" relationship because a cat is a mammal. When a subclass inherits from a superclass, it has all of the characteristics of the super class. Therefore, a dog and a cat are considered extensions of mammal.
It also is natural to think of objects as containing other objects. For example, a computer, which can be considered an object by itself, may also contain a hard drive and a video card, which are also considered valid objects. It is possible to open up the computer and remove the hard drive, so both the computer and the hard drive are considered objects. In this manner, objects are sometimes built, or composed, from other objects. This is called composition. A composition relationship is described as a "has-a" relationship.
The GJXDM provides three basic ways of associating two pieces of information: inclusion, referencing, and relationships. Inclusion means, in the XML sense, that one piece of information is contained within another. Inclusion is one of the fundamental building blocks of GJXDM and is used throughout the data model. It is implemented in GJXDM by an element simply being included in a sequence within a complex type. For example, the j:PersonType structure in GJXDM contains an element called j:PersonBirthLocation, which represents the place where someone was born. Linking the person to that place can be accomplished by inclusion, i.e., by including the j:PersonBirthLocation element (which is of j:LocationType) within the j:Person element, like this:
<j:Person>
<j:PersonBirthLocation>
<j:LocationAddress>
<j:LocationCityName>Boston</j:LocationCityName>
<j:LocationStateCode.USPostalService>MA
</j:LocationStateCode.USPostalService>
</j:LocationAddress>
</j:PersonBirthLocation>
</j:Person>
The GJXDM provides three basic ways of associating two pieces of information: inclusion, referencing, and relationships. Referencing links one piece of information using a reference or “pointer” to another piece of information described elsewhere in the XML instance. The referencing facility exists natively in GJXDM. As every element included within each complex type is paired with a “reference” element that points to a structure at some other place in the instance. These reference elements are of GJXDM’s type “ReferenceType”, which basically just contains an attribute that references an element with a particular unique identifier attribute. Using referencing, an example that represents a person’s birth location would look like this:
<j:Location j:id=”location1”>
<j:LocationAddress>
<j:LocationCityName>Boston</j:LocationCityName>
<j:LocationStateCode.USPostalService>MA
</ j:LocationStateCode.USPostalService>
</j:LocationAddress>
</j:Location>
…
<j:Person>
<j:PersonBirthLocationReference j:ref=”location1”/>
</j:Person>
The GJXDM provides three basic ways of associating two pieces of information: inclusion, referencing, and relationships. The association method is accomplished by using a separate structure, called a relationship that links two pieces of information. This facility is also provided by GJXDM’s “RelationshipType” structure, which contains attributes for a “subject” (one side of the association), an “object” (the other side of the association), and a name for the association or relationship. Using a relationship, an example that represents a person’s birth location would look like this:
<j:Location j:id=”location1”>
<j:LocationAddress>
<j:LocationCityName>Boston</j:LocationCityName>
<j:LocationStateCode.USPostalService>MA
</j:LocationStateCode.USPostalService>
</j:LocationAddress>
</j:Location>
<j:Person j:id=”person1”>
</j:Person>
<j:Relationship j:subject=”person1” j:object=”location1” name=”j:PersonBirthLocation”/>
Inclusion is recommended as the "default" choice and should be used in all cases where the information is hierarchical (e.g. if there is a containment relationship and the information is not represented somewhere else).
References are useful when the object of an association has a unique identity and appears in multiple places. However, schema designers should ensure that the object truly has identity, and not use references because the information happens to be the same. Using a reference conveys semantics about two subjects referencing the same object and should not be used as a tool to reduce the size of instances.
Relationships can be used under similar circumstances as references, but are particularly useful when the association is not already defined in the GJXDM. Relationships result in simpler extensions and more flexibility than extending GJXDM types to include new elements. However, using relationships requires the schema designer to choose names for the relationship (in cases where the association is not represented by an existing GJXDM property). As of this moment, there is no agreed upon standard for these names.
References or relationships potentially add complexity and memory consumption of software built to process instances, because the software must maintain a list of objects and their identifiers to re-establish association links as the instance is parsed.
With the increase of travel throughout the United States and beyond, Intelligent Transportation Systems (ITS) are vital to ensuring safety, protecting environment and relieving traffic congestion. Working in cooperation with the United States Department of Transportation (USDOT), the Institute of Electrical and Electronics Engineers, Inc. (IEEE) is developing a family of standards known as 1512®.
This IEEE 1512 family of standards supports the exchange of incident-related data between transportation, public safety, and other responding agencies.
Click Here to read more about the IEEE 1512 family of standards.
UBL, the Universal Business Language, is the product of an international effort to define a royalty-free library of standard electronic XML business documents such as purchase orders and invoices. Developed in an open and accountable OASIS Technical Committee with participation from a variety of industry data standards organizations, UBL is designed to plug directly into existing business, legal, auditing, and records management practices, eliminating the re-keying of data in existing fax- and paper-based supply chains and providing an entry point into electronic commerce for small and medium-sized businesses.
Click Here to read more about the Universal Business Language (UBL).
Nillability allows tags to exisit without content and have that lack of content be meaningful.
Without some prior agreement, the absence of an element does not have any particular meaning. Take PersonMiddleName as an example. The following snippet of XML does not mean that the person has no middle name. It only means that no middle name was included in the exchange.
<PersonName>
<PersonGivenName>John</PersonGivenName>
<PersonSurName>Smith</PersonSurName>
</PersonName>
To show that the person in question really has no middle name, the PersonMiddleName can be set to nil via the xsi namespace:
<PersonName>
<PersonGivenName>John</PersonGivenName>
<PersonMiddleName xsi:nil="true"></PersonMiddleName>
<PersonSurName>Smith</PersonSurName>
</PersonName>
Nillability lets you show where the lack of data is meaningful. GJXDM and NIEM elements are nillable.
Biometrics is the science of automated methods for uniquely recognizing humans based upon one or more intrinsic physical or behavioral traits.
In information technology, the term “biometric authentication” refers to technologies that measure and analyze human physical and behavioral characteristics for authentication purposes. Examples of physical characteristics include fingerprints, eye retinas and irises, facial patterns and hand measurements, while examples of mostly behavioral characteristics include signature, gait and typing patterns.
Although biometrics have primarily been utilized by law enforcement, biometric technologies are now being used by other government agencies to authenticate a person’s identity and to secure the nation’s borders. Biometric systems recognize a person based on physiological characteristics, such as fingerprints, hand and facial features, and iris patterns, or behavioral characteristics that are learned or acquired, such as how a person signs his name, types, or even walks. The Commerce Department’s National Institute of Standards and Technology (NIST) has been a partner with Justice in improving the nation’s human identification systems.
The successful use of the classic biometric, fingerprints, has benefited from NIST research and development. For more than 30 years, NIST has helped the Federal Bureau of Investigation (FBI) improve the automation process for matching “rolled” fingerprints taken by law enforcement agencies or “latent” prints found at crime scenes against the FBI’s master file of fingerprints. NIST test data have been used to develop automated systems that can correctly match fingerprints by the minutiae, or tiny details, that investigators previously had to read by hand. In cooperation with the American National Standards Institute (ANSI), NIST also developed a uniform way for fingerprint, facial, scar, mark, and tattoo data to be exchanged between different jurisdictions and between dissimilar systems made by different manufacturers.
Within GJXDM and NIEM one can use BiometricType property to describe information used to measure a biological or behavioral characteristic.
Data integration is the method of combining data from different sources and providing the user with a unified view of the information. During recent years, data integration has been implemented in a variety of integration applications, for example:
§ By synchronizing the data of different applications to ensure that all changes in one application are reflected in another;
§ By migrating information from one system to another, e.g., populating databases of one application with information from another;
§ Using a ETL (Extract, Transform and Load) method to pull data from various sources into a data warehouse;
§ Providing access to a specific set of data for viewing, reporting, etc., e.g., via a portal.
However, data integration using these methods often provides information that is not current. Depending on the architecture, the data can be weeks, even months, old, and the data warehouse is usually updated through a batch, extract-aggregate-and-load, process. FTP is still the primary form of data integration today.
Fortunately, the recent development and standardization of web services, driven by the adoption of service oriented architecture (SOA), will allow the user to design an enterprise integration approach with a standards-based bus so that he can orchestrate sequences of services to perform complex business processes. SOA solutions allow all participating databases and services to receive new data constantly, thus providing more value to those using the source and target systems existing within the SOA.
A group of agencies acting together in a peer relationship to share sensitive information with each other, subject to applicable access control policies.
The establishment of an inter-federation trust model between like and unlike federations.
An Enterprise Information Exchange Model (EIEM) is a MPD based on Business Information Exchange Components (BIEC). A BIEC is a NIEM-conforming XML schema data component (type, element, attribute, or other XML construct) that is reused, subsetted, and/or extended, that meets a business requirement for an information-sharing enterprise. An EIEM is a collection of BIECs organized into a subset and one or more extension schemas. Constraint schemas and non-NIEM-conforming external standards schemas with type adapters are optional in an EIEM.???????????
Links: http://reference.niem.gov/niem/guidance/business-information-exchange-c…
Documents
https://bja.ojp.gov/media/document/29991
The NIEM Conformance Tool or ConTesA Tool is an option available for you to validate schema. The Conformance Validation Tool is a dynamic tool that allows you to upload an IEPD, a set of schemas in a zip file, or an individual schema.? This free public release tool of the NIEM Conformance intended to assist developers by automatically identifying potential locations of non-conformance within IEPD artifacts (including schemas, metadata, catalogs, and XML). The tool will generate the report after your file has been uploaded and generate a report in HTML, EXCEL, or XML format. The tool uses the NIEM Naming and Design Rules (NDR) 1.3 and associated IEPD specifications. This tool will soon integrate into NDR 3.0.
User need to have a NIEM Tool Account which is local account to access the tool or you can use your own personal Yahoo or Google account because this tool is using Open Id.
NIEM Tools Account Registered Link: http://tools.niem.gov/niemtools/user/user-add.iepd
Conformance Tool Link: http://tools.niem.gov/contesaNIEM/
Naming and Design Rules 1.3 and 3.0: http://reference.niem.gov/niem/specification/naming-and-design-rules/
The Information Sharing Environment (ISE) broadly refers to the people, projects, systems, and agencies that enable responsible information sharing for national security. This includes many different communities: law enforcement, public safety, homeland security, intelligence, defense, and foreign affairs. The people in these communities may work for federal, state, local, tribal, or territorial governments. The Program Manager for the Information Sharing Environment (PM-ISE) is Kshemendra Paul. The PM-ISE has government-wide authority to plan, oversee the build-out, and manage use of the ISE. He also co-chairs the White House’s Information Sharing and Access Interagency Policy Committee (ISA-IPC).
ISE's mission and vision:
- Advance responsible information sharing to further counterterrorism, homeland security, and cybersecurity missions
- Improve nationwide decision making by transforming from information ownership to stewardship
- Promote partnerships across federal, state, local, and tribal governments, the private sector, and internationally
Resources:
ISE's document libary
ISE's Programs
Video Interview with ISE's Program Manager
NIEM Github is the Sharing Spot is for the community to have access to resources that will help them use NIEM and make NIEM easier for others to use. At its very core, GitHub is a web-based hosting platform for Git repositories. Git is a popular version control system that's widely used among programmers and developers for developing and maintaining code.
For more information on this tool, please click on the links below.
Resources:
http://www.lynda.com/GitHub-tutorials/What-GitHub/162276/173432-4.html
A description of a subset can be saved as a "wantlist". A NIEM / GJXDM wantlist is an XML instance (based on a schema) for identifying the NIEM / GJXDM components required for a given subset. It is the intermediate format that the SSGT itself uses and edits, and can be persisted (saved to disk, emailed, published online, etc.) to feed the selected types and elements into the SSGT at a later time.
By employing this open XML-based specification, it is possible for other tools (such as editors or schema builders) to interact with the SSGT and to exchange subset definitions between tools.
Wayfarer is an exploration tool for the NIEM and the GJXDM. It provides advanced searching capabilities combined with detailed information about elements and types. It was developed in-house by the NCSC and is freely available to the NIEM and GJXDM communities.
http://www.ncsc.org/Services-and-Experts/Technology-tools/National-stan…
NIEM Wayfarer Tool: http://apps.ncsc.org/niem/
GJXDM Wayfarer Tool: http://apps.ncsc.org/wayfarer/
Wayfarer shows details about various elements and types and the relationships between them. The main interface to Wayfarer is the search box. Users can search element and type names and definitions, as well as code tables. Clicking on an element or type name will bring up details on that element or type.
Element pages give detailed information about the "has-a" relationships, e.g. a Person "has-a" a PersonName.
Type pages give detailed information about the "is-a" relationships, e.g. a Judicial Official "is-a" Person.
The recommended way to access Wayfarer is to go to the online version. This is always the most up-to-date version. There is also a localized version that allows one to use Wayfarer without having access to the Internet. It's based on transforming the database information into a series of static web pages. The end result is nearly 3000 separate pages, one for each element and type. As with the online version, the localized version requires a JavaScript-enabled browser, but it no longer requires any additional software.
Wayfarer Tool Website: http://apps.ncsc.org/niem/
SuperType is the root object in the type inheritance hierarchy. It incorporates attributes such as, @sensitivityText, @reportingOrganizationText, @reportedDate, @effectiveDate, and so forth. SuperType provides a base object with properties that can be associated to any element in the entire GJXDM.
The SuperType is basically any thing. Using a SuperType as a root of the model enables the association of certain attributes common to all of the types. In other words, all types in the model can inherit basic attributes such as “@source Text” (the name or identification of an information resource from which the content came) or “@reportedDate” (the date information was observed, measured, identified, or became known). This is commonly known as metadata.
Derived from the SuperType are other types, such as PersonType or ActivityType. Each of these types has properties of its own, and the important objective of component reuse is achieved by using the OOP concept of inheritance.
The “SuperType” contains properties that are applicable to all components of the GJXDM; therefore, all fields will include the properties of “SuperType”. All GJXDM components are derived from “SuperType”, so that all components inherit all the “SuperType” properties. At the same time, “SuperType” has neither complex nor simple content. In fact, it has no content; it's empty. Thus, objects with simple content can still be derived from “SuperType”, because it cannot contain any subordinate elements. And finally, one can consider “SuperType” properties generic enough to be metadata (such as, “probabilityNumeric”, “distributionText”, “reportedDate”, “expirationDate”, etc.) on all GJXDM components.
To find a component (type or element), it is helpful to understand how they are named and be aware of the challenges for searching introduced by the inheritance relationships in GJXDM and NIEM.
One design criteria for GJXDM and NIEM is to provide a set of data element names that are relatively complete, semantically precise, and globally understood. The meaning of any given tagname should be determinable within a variety of circumstances, ranging from well-structured documents with rich context to transaction- or message-oriented formats that may be weak in context. To accomplish this goal, GJXDM and NIEM prohibit synonyms and use ISO/IEC Standard 11179 (Specification and Standardization of Data Elements) syntax for naming elements consistently and precisely.
As a result, GJXDM and NIEM have wide applicability and a larger scope, but also longer tagnames. However, it is not difficult to codify the tagnames for transmission efficiency or to apply compression techniques. The Federal XML Developer's Guide requires that XML data element names (tagnames) be specified using the syntax rules of ISO/IEC Standard 11179 (Specification and Standardization of Data Elements). Therefore, all XML data element names contain three basic parts: object class term, property term, and a representation term. Each of these terms may be further supplemented with optional qualifier terms (essentially adjectives), as required to clarify or focus semantic meaning.
Each component lists the ways in which it may be required , and other components which it may require.
A component is any of the following:
- Namespace prefix declaration: A namespace prefix declaration is required when the declared prefix is used anywhere within the schema file. For example, if an entity from the 'http://xyz.com/ns' namespace is used within the schema, then a namespace declaration must be included for that namespace.
- Import of a schema: Each schema defines the contents of a single namespace (the target Namespace of the schema). If Schema B refers to an entity of Schema A (an entity in the namespace defined by Schema A), then Schema B must import Schema A. If Schema B does not refer to an entity of Schema A, then Schema A need not import Schema B. An import is required when any component from the namespace which it imports is used within the schema file.
- Type definition: A type definition is required when:
- The type is used by the consumer of the schema (either in an instance or an outside schema)
- It is used as the type of an element or attribute
- It is the base type of another type definition This requirement should not be ignored. When defining a type, it is important that all base types of that type be included in the schema. Even if they are empty (i.e. have no attributes or elements), they should be included. A base type may be empty if there are no requirements for elements or attributes of that type to appear in instances or outside schemas . Even in such a case, the type should still be included, preserving the type hierarchy.
A type definition may require other components:
- The base type of the type. This type may be simple or complex. Also required are the base type of that type, and the base type of that type, etc.
- The SuperTypeMetadata attribute group
- Occurrences of attributes in the SuperTypeMetadata
- Occurrences of attributes in the type
- Occurrences of elements in the type
Global element definition Every element that represents a data model entity has a single definition in the schema. A global element definition is required when:
- It is referenced in a type definition, as an occurrence of an element in a type
- It is referenced by a non-data model schema, such as a schema for local extensions. A global element definition requires:
The type definition for its data type. -Global attribute definition Every attribute in the schema that represents a data model property is given a single definition. Each use of the attribute references that definition (using ref=)
A global attribute definition is required when:
- It is referenced in a type definition, as an occurrence of an attribute in a type
- It is referenced in the SuperTypeMetadata attribute group
A global attribute definition requires: The type definition for its data type -Occurrence of an element in a type
An occurrence of an element in a type is required when:
- An instance of a type uses the element. For example, if an instance of PersonType contains PersonName, then the element PersonName is required to occur in the type PersonType.
- An instance of a subclass of the type uses the element. For example, an instance of EnforcementOfficialType requires PersonName, then the element PersonName is required to occur in the type PersonType, since EnforcementOfficialType inherits PersonName from PersonType.
An occurrence of an element in a type definition requires: The global definition of the element -Occurrence of an attribute in a type definition
An occurrence of an attribute in a type is required when:
- An instance of a type uses the attribute
- An instance of a subclass of the type uses the attribute
- It requires: * The global definition of the attribute -Occurrence of an attribute in the SuperTypeMetadata
An occurrence of an attribute in the SuperTypeMetadata is required when:
- An instance of the SuperType uses the attribute
- An instance of any subtype of SuperType uses the attribute -Enumeration
An enumeration is required when: An instance may include the enumeration as a data value.
Global Justice XML Data Model (GJXDM) schema designers should become familiar with the tools available to search GJXDM for desired types and elements. These tools include the National Center for State Courts (NCSC) Wayfarer, the Schema Subset Generation Tool (which subsumed the functionality of the GJXDM Model Viewer), and the GJXDM spreadsheet that is part of the distribution for each release.
Regardless of which finding aid utilized, it is important to remember that each type in GJXDM inherits properties from types higher in the inheritance hierarchy; it is often the case that the property being sought is actually in a base type, and so may have an unexpected name. This concept, called contextual data elements (article #4), can frustrate some search attempts, but is beneficial because it fosters reuse within the model, represents important semantic relationships between general and specialized types, and makes the data model smaller. The XSTF is investigating a set of techniques and mechanisms that could be used to improve searches with contextual data elements.