Looking Ahead: Next DDMSence Release
33 views
Skip to first unread message
Brian Uri!
Mar 21, 2013, 6:45:48 PM3/21/13
to ddms...@googlegroups.com
Hello DDMSence adopters!
DDMS 5.0 was released on January 14, 2013, and has some dramatic modifications:
1) The GML profile for modeling geospatial locations has been replaced by geometries from NGA's Time-Space-Position Information specification (TSPI v2.0).
2) DDMS has been recast as an Assertion in the Intelligence Community's "Trusted Data Format" specification (IC-TDF V2).
The latter change may take some effort to wrap your head around. In the past, a DDMS metacard was a top-level XML construct containing all of the security and discovery information to describe some resource. It was like the card in the card catalogue, and could be stored or passed between systems on its own.
IC-TDF represents the result of ongoing IC/DoD efforts to move towards cloud-oriented data ingest. To oversimplify TDF, there are separate buckets for all of the various metadata you might need as your payload moves from agency to agency. Security goes in one bucket, and discovery goes in another. This clean separation of concerns has the side effect that each bucket on its own is no longer sufficient to describe and protect the resource.
In this new world, a DDMS metacard (the ddms:resource XML element) is no longer a standalone construct. The top-level security markings and "Extensible Layer" have been stripped away and placed in other TDF areas, and the metacard is pure discovery information. However, you need the entire TDF bundle to fully understand the context of the described resource -- a ddms:resource on its own is incomplete.
When you add together all of the IC and GML-related schema files, the DDMS ecosystem now consists of over 100 schema files. As I plan the way forward for DDMSence, I want to make sure that the library remains as small and as useful as possible. At this point, I expect that the next version of DDMSence (v2.2.0) will focus solely on the ddms:resource as a TDF Assertion, ignoring the fact that it is incomplete on its own. Systems could still use the library to generate a valid DDMS Assertion and then insert it into TDF on its own. My key focus has always been on the metacard -- modeling the entire TDF structure might be overkill with no measurable added benefit. However, I would like to solicit your feedback on this approach before I commit, and welcome any feedback or use cases you might have.
The DDMS 5.0 schema package (containing a Release Notes document describing the major changes from 4.1) can be found on the DDMS homepage. Unfortunately, new releases of DDMS are no longer Public Release, and a CAC or DSE account is required for access:
http://metadata.ces.mil/dse/irs/DDMS/
A brief description of TDF can be read here:
http://www.dni.gov/index.php/about/organization/chief-information-officer/trusted-data-format
The DDMSence homepage can be found here:
http://ddmsence.urizone.net/
Regards,
BU
DDMS 5.0 was released on January 14, 2013, and has some dramatic modifications:
1) The GML profile for modeling geospatial locations has been replaced by geometries from NGA's Time-Space-Position Information specification (TSPI v2.0).
2) DDMS has been recast as an Assertion in the Intelligence Community's "Trusted Data Format" specification (IC-TDF V2).
The latter change may take some effort to wrap your head around. In the past, a DDMS metacard was a top-level XML construct containing all of the security and discovery information to describe some resource. It was like the card in the card catalogue, and could be stored or passed between systems on its own.
IC-TDF represents the result of ongoing IC/DoD efforts to move towards cloud-oriented data ingest. To oversimplify TDF, there are separate buckets for all of the various metadata you might need as your payload moves from agency to agency. Security goes in one bucket, and discovery goes in another. This clean separation of concerns has the side effect that each bucket on its own is no longer sufficient to describe and protect the resource.
In this new world, a DDMS metacard (the ddms:resource XML element) is no longer a standalone construct. The top-level security markings and "Extensible Layer" have been stripped away and placed in other TDF areas, and the metacard is pure discovery information. However, you need the entire TDF bundle to fully understand the context of the described resource -- a ddms:resource on its own is incomplete.
When you add together all of the IC and GML-related schema files, the DDMS ecosystem now consists of over 100 schema files. As I plan the way forward for DDMSence, I want to make sure that the library remains as small and as useful as possible. At this point, I expect that the next version of DDMSence (v2.2.0) will focus solely on the ddms:resource as a TDF Assertion, ignoring the fact that it is incomplete on its own. Systems could still use the library to generate a valid DDMS Assertion and then insert it into TDF on its own. My key focus has always been on the metacard -- modeling the entire TDF structure might be overkill with no measurable added benefit. However, I would like to solicit your feedback on this approach before I commit, and welcome any feedback or use cases you might have.
The DDMS 5.0 schema package (containing a Release Notes document describing the major changes from 4.1) can be found on the DDMS homepage. Unfortunately, new releases of DDMS are no longer Public Release, and a CAC or DSE account is required for access:
http://metadata.ces.mil/dse/irs/DDMS/
A brief description of TDF can be read here:
http://www.dni.gov/index.php/about/organization/chief-information-officer/trusted-data-format
The DDMSence homepage can be found here:
http://ddmsence.urizone.net/
Regards,
BU
Reply all
Reply to author
Forward
0 new messages