- Ref: DataReferenceModel_09_2004 (2K96)
- 1. Introduction to Comments (2K97)
- EA Areas of Emphasis at Our Agency (2K98)
- In addition to thorough and thoughtful treatment from our internal agency EA community of interest, our agencies' Enterprise Architecture Group has solicited both Model Driven Architecture and Semantic Web experts that we currently have engaged on various projects for their insights and comments regarding the DRM. We believe these areas of emphasis provide a solid foundation from which to discuss DRM ideas and implementations in the context of the FEA and EA in general. In addition, we also continue to utilize Aspect Orientation, which we have shown to be easily applied to the FEA and here extend to include more commonly discussed ideas about security, privacy and rights management policy which appear thematically throughout our internal and external agency generated comments. (2K99)
- Executable EA, OSERA and FEARMO (2K9A)
- Over the past year and a half, we have been implementing EA methodologies using Model Driven Architecture (MDA) techniques, which are proving to be extremely powerful in helping to unify business processes. The results are so compelling and positively received by our business stakeholders, that our next steps are to execute a model driven legacy transformation of a mission critical financial management system at our agency, resulting in a simplified FM-IT infrastructure. (2K9B)
- Our efforts and approach to creating our ‘Executable FEA’ based on MDA have been previously described to the Architecture and Infrastructure Committee (AIC). We have since continued to evangelize and demonstrate the utility of our open standards approach to process-centric and service oriented business and technical architecture modeling with numerous EA stakeholders and interested parties in a variety of Federal and EA related forums. We have also described to the AIC and others our work in adapting various open source toolsets into a cohesive suite of design and runtime tools we call the Open Source eGov Reference Architecture (OSERA), a preview of which will be available in March 2005, that we hope will be warmly received by the EA and eGov communities. (2K9C)
- Most recently with the addition of our newest team member, our work has been expanded to include creating an FEA Reference Model Ontology in OWL that we are excited to share with the AIC and larger EA community in the months to come. OWL-based inference and reasoning capabilities, will provide further executable capability and will ultimately help automate the correlation of EA assets to the FEA and evolve the FEA itself. (2K9D)
- Scope of DRM Comments (2K9E)
- Comments here attempt to briefly connect our executions of the ideas in MDA, Ontologies and Semantic Web related works in progress, ideas on Aspect Orientation, open source implementations related to each of these subjects, and to synthesize many of the issues expressed by agency EA stakeholders, with respect to the goals and objectives of the DRM in support of the FEAPMO. (2K9F)
- Our agency EA Group hopes to have the opportunity to discuss in greater detail these ideas with the EA community at large in the near future. (2K9G)
- 2. Model Driven Architecture (MDA) and DRM (2K9H)
- MDA is an important phenomenon in industry, invoking a modeling discipline that fundamentally decouples architecture from tools, while enabling semantic interoperability of tools and a continuously traceable thread from high-level business models to information technology infrastructure. (2K9I)
- MDA is in many ways equivalent to the concepts expressed by domain specific modeling and ‘software factories’. Some ‘branded’ version of ideas central to MDA is strategically championed by our largest, most successful and prominent technology companies. (2K9J)
- A full treatment of MDA is not given here, as there are substantial expert resources available on this topic, having a very wide scope of applicability to our EA and eGov communities. Only those ideas that are most accessible and directly relevant to challenges faced by the DRM are discussed here. (2K9K)
- A primary objective of our agency MDA adoption was motivated by the desire to simplify our expressions of EA artifacts while enabling direct execution of business models, based on the proven ability to generate code from elaborated technical models. We refer to this as Executable Enterprise Architecture, and have extended this to Executable FEA. Our approach has numerous powerful consequences on EA and eGov that also are outside the scope of this DRM comments document, however we would be pleased to interact with those interested in more information. (2K9L)
- 2.1 Metalevels and Standardization Targets (2K9M)
- We call attention to the comments of David Frankel, noted MDA expert/author regarding ‘metalevels’ for the purposes of having a unified discourse in describing various potential targets of the DRM standardization effort. We agree with David and believe that the notions adopted by Object Management Groups (OMG) Meta Object Facility (MOF) standard are extremely useful for this purpose. Adopting this metalevel thinking will provide clarity currently lacking from our DRM standardization efforts for sharing information. (2K9N)
- We believe that this understanding of ‘metalevels’ (which as Frankel points out is not owned or invented by the OMG community) is an important prerequisite for DRM discourse. Many comments have been made about the uncertainly of concepts and names in the DRM largely due to overloading of terms, often based on improperly crossing these metalevel boundaries. We agree with Frankel, that the DRM work needs to be clear about separating concerns along these metalevel standardization efforts as we go forward. (2K9O)
- We also agree with many who have noted that as data standardization targets go to either philosophical (upper ontologies) or technological (xml schema instances) high/low extremes, the historical truth is that these types of efforts move from difficult to intractable. (2K9P)
- We believe that sharing will be facilitated by simple, consistent and repeatable mechanisms for understanding the meaning of data and how it is or can be used. (2K9Q)
- 2.2 Collaboration as Context/ Category (2K9R)
- Both Frankel and Ralph Hodgson, noted Ontology expert and well known in the FEA community, have pointed out in their respective comments a deeper requirement for providing data context. We have for some time evangelized our adoption of an open MDA standard called Enterprise Distributed Object Computing (EDOC), which addresses this issue substantially, as was briefly mentioned by Frankel. We give a more thorough introduction of how data context is achieved in our use of EDOC here. (2K9S)
- The EDOC standard contains the Component Collaboration Architecture (CCA) specification and defines a formal grammar of ‘collaborative role interactions’. Using this approach, a collaboration data model emerges as the information contained in role interactions, which are said to be the ‘conversations’ between roles. The roles themselves are contained in the context of a particular collaboration that further delineates the context. The notion of ‘party’ that Hodgson mentions is analogous to actors that play roles, and we’ve shown how the progressive elaboration of these roles can describe any level of service granularity and can be directly aligned with the SRM component hierarchy expression. Our use of this approach is organized by and linked directly to Value Chain Analysis, which adds additional business context to the collaborative role interactions. (2K9T)
- The result of this type of architecture modeling is a precise specification of interoperability that introduces an Information Exchange Package heuristic. The collaboration data model begins with a formal idea in EDOC/CCA, known as a ‘protocol’, which groups ‘ports’ that are attached to components that implement roles. The idea should sound familiar to those who know WSDL, and is also richer than an object oriented ‘interface’, because it supports bi-directional asynchronous specifications. These protocols are the ‘conversations’ between roles, and they may nest other protocols, which may contain other ports. This provides a useful way to model a set or package of related data entities, and therefore a natural association with the Information Exchange Package idea in the DRM arises. (2K9U)
- We believe that information context should be carried with this notion of collaborative role interactions, in addition to the entire FEA Line of Sight. The important idea from MDA here is that in our treatment of an IEP, we can automate the generation of the ‘protocol adapter’ to a chosen deployment technology, which is entirely independent of the contract that the protocol specifies between service components (roles). This idea is further explored in section 2.3 regarding generation of multi-modal data representations from a protocol adapter, and again in section 3.1 below to suggest that this provisioning step should be driven by policies that inform us as to how the information must be treated with respect to security, privacy, quality, ownership, and any other declarative attributes important to some target environment. An MDA ‘business’ model specifies the behavior and responsibilities of roles and the choreography of information they must provide and consume in a collaborative process, as distinguished from an MDA technical model, which adapts the role as a service and the information to a data representation appropriate for the physical environment. (2K9V)
- Much has been said by others regarding ‘Super Type’ as a poor naming choice for the coarser grained ideas of categorical distinction. The comment from our agency OCAO that I’d like to reify here is that the work of the Interagency Committee on Governmental Information (ICGI) Categorization of Government Information Working Group (CGI-WG) seems as if it should be providing the exact same solution, either to or from the FEAPMO-DRM, since these appear to be activities of a very similar, if not equivalent, nature. (2K9W)
- Further, we amplify this observation by suggesting that the entire Line of Sight related to any information in our EDOC-based collaborative role interactions and therefore the FEA itself, should be considered as potential candidates for both communities’ categorical device solutions in accordance with ideas of the Knoxville Framework. Some codification of each taxonomic element in each FEA Reference model as it exists in the collaboration specific FEA Line of Sight would allow for something like a URN: Agency: Collaboration-GUID: FEA-LoS-Codelist type of dynamic search and discovery, not only for data and information, but perhaps for entire contextualized sets of EA assets returned by queries across the entire Government information space. A third party service provider could create dynamic visualizations of the entire namespace, enabling ‘at a glance’ comprehension of government services and the related information to citizens, in addition to providing URN search services until such time as ubiquitous web browsers have this native support or we have this capability using existing DNS infrastructure. (2K9X)
- Another way to express this idea might be to say that we’re describing an ontology of G2G/G2B/G2C collaborations, and this also has implications regarding the ability to infer commonality and compose-ability in ways that are at the core of the FEA and OMB goals. (2K9Y)
- The last two ideas haven’t been thoroughly analyzed, but our hope is that there is enough information here to warrant some discussion in each community, as our agency EA Group continues to explore ideas like these and many more surrounding the integration of MDA and Semantic technologies, or the ‘Model Driven Semantic Web’. (2K9Z)
- 2.3 Schema Representations and Assembly (2KA0)
- The representation of an object is often required to be multi-modal, suited to a particular purpose or mode of delivery. We want to be able to derive isomorphic representations (equivalent information taking different forms) of the same data entity in whatever form is most appropriate to the environment that data is used in. For example, a data entity will be more useful as a Java object in some circumstances than an XML document or schema instance, and vice versa. The point is that the representation has little to do with the utility of the information, and should be a decision that is constrained by a deployment environment that will enact a usage scenario, not by the usage scenario itself. A business model describes the scenario; a technical model describes the representation, or the implementation of the scenario. (2KA1)
- This plays to a well known strength and objective of model driven techniques, to isolate the meaning and definition of a data entity (or any model element) from its technology representation, because the goal of collaborative usage scenarios will not change as frequently as technology specifications used for representations (i.e. versions of XSD/SOAP/WSDL/etc.) that require representation revisions of the same data entity. The idea is to generate the multi-modal object to the new representation specification whenever a target representation specification is different or changes, from the same model. (2KA2)
- UBL-like aggregation of core components into increasingly business context or usage scenario-based documents are ideally composed in much the same fashion, by maintaining an opus of core component models and assembling them based on usage scenario requirements into more and more context sensitive and collaboration specific documents, or collaboration data models. Assuming there is a difference between a collaboration data model and what you need to persist within your IT infrastructure operational data stores, it seems like there could be a reasonable expectation that the years of work that came out of EDI into UBL core components should be leveraged as an initial opus of raw data materials from which to create context driven collaborative conversations with. (2KA3)
- There are numerous potential areas and even more interesting are the levels of reuse possible here, as the accumulation of UBL-like intermediate assemblies dynamically evolve over time based on collaborative usage statistics, without human intervention. A registry should be required to accumulate statistics (learn) the most widely used aggregates and core components; COTS and open source registry tools in this space have this capability out of the box or as a simple extension. (2KA4)
- It is also probably worth noting that model-driven techniques can also manage and execute required transformations from a collaboration data model to an operational data store for persistence. This will be a common requirement in eGov scenarios, and the DRM rightly shouldn’t try to dictate how persistence needs to happen since this will need to be governed by issues such as statefulness, security, privacy, ownership, etc. and will be driven by the unique requirements from the diverse value chains and resulting collaborations. (2KA5)
- If we further enrich this knowledge of collaboration data with the context carried by the ideas expressed in 2.2 above, we would provide a mechanistic way to evolve a comprehensive view of how data is employed across the Federal Government. The recommendation here is to employ techniques that allow for the complex problem to reveal itself holistically over time. (2KA6)
- Ideas about assembly and representation are further explored in the next section with respect to policy driven assemblies and platform specific representations, and further in later sections on Semantic technologies. (2KA7)
- 3. Aspect Oriented Architecture (2KA8)
- Security is the canonical example in the Aspect Oriented Programming (AOP) community. The idea of Security AOP is not to manually code security into every object as asserted by an overriding security policy, which all applications must have in accordance with their organizational standards. Instead, an ‘aspect compiler’ will later ‘weave’ in the proper security code at appropriate ‘join points’, or the places in the code where security applies. The positive effects are at least three-fold; the security policy itself is now free to change without requiring intrusive manual changes to your code base – you simply reapply the aspect compiler and the new security policy is woven in, enhancing developer productivity, build management, and deployment time. (2KA9)
- This is a powerful idea that we suggest has tremendous implications with respect to comments and observations by many regarding the lack of various data related concerns in the DRM draft. A full treatment of AOP is not given, as there are substantial expert resources available on this topic, having a very wide scope of applicability to our EA and eGov communities. Only those ideas that are most accessible and directly relevant to challenges faced by the DRM are discussed here, where we further extend our MDA based EA modeling ideas with aspect orientation. (2KAA)
- 3.1 FEA LoS (2KAB)
- We have shown the AIC and others how we treat the FEA as an Aspect of architectural models, and in our agency EA Practice we currently use this approach to provide an additional contextual view of the information contained in our collaboration models. We have demonstrated how this approach makes the generation of reports such as 300’s trivial, but more importantly how our approach provides a clear Line of Sight throughout the entire set of FEA Reference Models for every collaborative role interaction we model. (2KAC)
- For any data entity that composes any set of data components regardless of type (properties are types too) that satisfies some interoperability scenario, we have a correlation of this information (that we call a collaboration data model above) and its relationship to every FEA Reference Model. This is a literal interpretation and powerful implementation of FEA Line of Sight, and allows us to understand and analyze reuse with more breadth and depth than described by the DRM draft. (2KAD)
- We have demonstrated our correlation framework to accomplish the FEA Line of Sight in accordance with our approach to using EDOC/CCA to describe collaborative role interactions in our MDA business models, summarized very simply as follows: (2KAE)
- Collaboration (business process) - BRM (2KAF)
- Role (party, or actor) – SRM (2KAG)
- Interaction (information exchange) – DRM (2KAH)
- Protocol – IEP (2KAI)
- Data Flow Port – multiple data entity/types/representations (2KAJ)
- The TRM correlation represents existing or planned deployment decisions regarding how the collaboration (J2EE container/app server), roles (EJB, POJO, Servlet,) and protocols (JMS, Web Services) are implemented using a specific technology platform or paradigm (just using a Java stack here as an example), usually in the MDA technical models of the same collaboration. (2KAK)
- The PRM correlation wraps the entire context collaborative role interaction context with metrics based on the type of model (business or technical) and as appropriate for each FEA Reference Model, using a number of approaches such as the well-known ‘ilities’ or ‘transparencies’ as suggested by Ralph Hodgson. So a PRM metric for a TRM decision might be about latency, while a PRM metric for an SRM component that implements a role might be about scalability, and a BRM collaboration would have a business-related PRM metric, possibly an increased customer base for some line of business (not that these exist in the PRM, just examples here). (2KAL)
- 3.2 Security, Privacy, Quality and Rights Management (2KAM)
- The FEA Security Profile can be treated in exactly the same way as we are treating all the other FEA Reference Models, by applying it as an aspect of the collaborative role interaction models that specify interoperability requirements regardless of deployment details. Based on the chosen existing or planned deployment technologies, any attributes from any structured expression of a security policy should determine the provisioning requirements when a model/collaboration/role/protocol is adapted to a runtime platform implementation. (2KAN)
- As suggested above in section 2.2 and above, UBL-like assemblies will likely also need to be driven by policies. Our approach to adapting CCA protocols and ports for automated provisioning to target deployment technologies accommodates any of these areas in the same fashion. For example, we should be able to express that a particular payload of a multipart SOAP w/ Attachments message and a particular header in that SOAP message are treated independently (only some things need to be signed/encrypted, and they can only be handled by certain parties, etc.) from the other message contents, as specified by a security and privacy policy. This is the type of problem that is addressed by digital rights management as it is extended beyond desktop productivity tools to multi-hop enterprise boundary crossing collaborations germane to eGov interoperability scenarios. (2KAO)
- To realize our citizen centric eGov vision, we believe that establishing a framework for federated trust brokering is required, and our approach to modeling collaborative role interactions also has a direct parallel to visualizing and implementing these security related roles and requirements. The collaboration itself represents a circle of trust and may carry assurance levels, the roles of each will have security policies that they must enforce as they are ultimately implemented by disparate partners' IT infrastructures in a value chain, and the nature of the data itself will also assert constraints on the interaction. This approach allows for the analysis, accumulation and rationalization of multiple disparate security domains and policies. (2KAP)
- It may also be that data quality can be applied in much the same fashion, if for example we consider the above example again, the acknowledgement of when/where/how validation of data exchanges will likely be driven by the collaborative role interaction itself, which will get adapted in accordance with various policies as described here, thereby allowing for data quality assurance to be applied as the usage scenario dictates as service level agreements in a binding collaboration contract. An additional layer of data quality and validation can also occur in the same fashion, as transformations are required for operational data store persistence. (2KAQ)
- Ownership and Provenance may require treatment at every level of data detail. To continue with the UBL example, it may be that there exists significant ownership/provenance constraints occurring at any or all of core component, aggregated component, or document object levels, in a collaborative data model. (2KAR)
- The auditing of any of this policy-driven security, privacy, ownership, quality can be seen as a commonly reused set of protocols and ports - just another set of messages – employed by the collaborative role interaction implementations. The difference between auditing and more vertically-oriented ideas such as ‘activity based costing’ are difficult to discern here, and there are also huge implications for distributed data warehouse and mart architectures. (2KAS)
- We would suggest that the combination of the aforementioned collaborative modeling techniques from MDA and AOP treatment of policies provides an approach to solving the difficult problems that are currently either not addressed or not fully treated by the DRM draft, and worthy of exploration in the AIC/CAF and other Federal related EA community of practice. (2KAT)
- 4 Semantic Web and Ontologies (2KAU)
- The work of Ralph Hodgson and TopQuadrant on their ‘Capabilities Manager’ Pilot to be shown at the upcoming Semantic Web Applications for National Security conference (SWANS) is based on an FEA Ontology, and appears to provide the type of functionality that perhaps FEAPMO desires from FEAMS or something like it – that such a system might provide information and pointers to Agencies in search of capabilities provided or planned by others, in order to facilitate shared capital planning. Frankel suggested that leveraging the Semantic Web would ‘aid architects in finding definitions that meet certain criteria’ while elaborating on Michael Daconta’s assertion that the DRM leverage the Semantic Web – this is precisely what Hodgson and TopQuadrant have done with their Capabilities Manager. (2KAV)
- We support this and will make an effort to have it gain visibility. In addition, we have begun initial work with Ralph and our agency EA Group to work towards an initial version of an FEA Reference Model Ontology, to be made available throughout our community of interest in the near future, which seeks to make explicit the deep but implicit structures that currently exist in the FEA Reference Models. (2KAW)
- In addition, we will explore the ideas expressed above in section 2.2, where we’d like to explore ideas to extend the functionality of the TopQuadrant Capability Manager, perhaps to reason over a Federal Collaboration Ontology, allowing us to examine details provided by the business collaboration models which can enable a discovery that isn’t necessarily budget process driven, but rather could emphasize efficiency and effectiveness of service to Citizens. (2KAX)
- As per Frankel, the OMG has working groups whose goal is to unify the work in the Semantic Web community and the MDA community. There are numerous interesting EA and eGov related design-time and runtime potential outcomes, such as the ability to automate bi-directional movement from ontologies to and from metamodel instances, even when either the ontology or metamodel was previously unknown, which implies a requirement to dynamically generate mappings from the ideas captured in either the ontology or the metamodel. (2KAY)
- Ultimately, we are interested in the ability to enable natural language processing to suggest ontologies where machine reasoning may then infer a relationship to a conceptual framework from which we have or generate a mapping to some other conceptual framework. An example of this idea from ‘end to end’ might be the ability to create a CCA collaborative role interaction model from a Word document, perhaps using a Federal Collaboration Ontology, see these team member comments for other insights into these ideas. There is increasing momentum and understanding of this work in a community that envisions a ‘Model-Driven Semantic Web’, whose efforts are to automate ‘synthesizing systems of systems’, exemplified by the Synsyta Consortium, with whom our agency EA Group has consulted with informally and will likely establish a more formal relationship in the near future. (2KAZ)
- We will also note here, without any additional background information, the existence of ISO 19736, specifying an Ontology Registry/Repository - based on ISO 11179, and note that members of OMG and NIST communities know a lot about this standards effort. (2KB0)
- 5 Open Source Infrastructure (2KB1)
- Our agency is pursuing the Open Source eGov Reference Architecture (OSERA) initiative, which brings together MDA design and SOA runtime tools, targeting our own EA practice and eGov projects. Our hope is that the EA and eGov communities at large will also find our approach to these tools useful. The disruptive realization is that much of what we need in MDA design and SOA runtime machinery and tools either already exists or shows tremendous momentum in various open source communities. The OSERA toolset has initial MDA design tool implementations based on Eclipse, and SOA runtime tool implementations based on either JBoss or Jonas. (2KB2)
- Here we make the case that the infrastructure and machinery required to implement the DRM in various forms is available as free and open source to the community at large in the form of highly visible and well funded-initiatives of large software companies and open source consortiums, which our agency EA Group is already leveraging in our OSERA initiative. (2KB3)
- 5.1 Metadata Management (2KB4)
- Frankel depicts ISO 11179-5 at the MOF 2 metalevel, using UML as a representation. He has also described the work of the OMG ODM group, allowing us to move in and out of OWL Ontologies and UML models. An infrastructure that can tie together all of these various types of MDA and OWL models and instances are those based on OMG standards, including MOF and the XML Metadata Interchange standard (XMI). (2KB5)
- Other related standards such as JMI that provide a Java API for interacting with MOF objects without requiring serialization to-from XMI. Other OMG efforts including MOF Query, Views and Transformations (QVT) provide standardized capabilities to support transformations, both horizontally and vertically across MOF metalevels and reflections therein. (2KB6)
- Here we simply reify Frankels’ comments and previous agency EA tools studies on existing open source tools based on Eclipse that support creation of data representations in XSD or Java objects from UML models, and suggest that the work we’re doing in OSERA will augment these capabilities to enable a variety of EA related views, such as transforming a collaboration visualization from a CCA style to a BPMN style, reading an OWL Ontology to create a CCA collaboration model, and many more modeling areas of practice (see Frankels comments on ‘Leveraging MDA’). (2KB7)
- 5.2 Operational DRM (2KB8)
- Many have noted concerns about discussing the DRM Volumes out of context with other Volumes suggested to follow, or developing these Volumes out of sync with each other. We believe that the purpose of the DRM will only be understood in terms of how it will be fully operational, and that an example that is consistently applied across all of the subject divisions in each volume must be used for parallel development of each Volume. (2KB9)
- If FEAPMO intends to operationalize the DRM in terms of a knowledge discovery mechanism, then it looks like it should fulfill the Registry roles described by the ‘publish’ and ‘find’ SOA paradigm. If we also include the ‘bind’ part of the SOA Repository idea, then the DRM intends to be part of actual operations and the day-to-day transactions of Government, then its implementation begins to look like the so-called Enterprise Information Integration (EII) COTS space, and acts like a ‘middle data tier’. (2KBA)
- If you query a URN namespace for a federation of registries and/or repositories, DNS referral can take over and provide location transparency while ownership of namespace resolution can be delegated to the Agency that ‘owns’ or manages the collaboration as a service provider. This is just one example, virtual federation, which suggests if we use the existing capabilities of the Internet, we have tremendous flexibility with respect to how DRM and related FEA infrastructure can add value to Agencies and Citizens alike. (2KBB)
- Our suggestion is that we can simplify and unify the IT infrastructure that either exists or is planned for use by FEAPMO by exploiting existing tools, and further discuss below additional implications. (2KBC)
- 5.3 Registry/ Repository Federation/ Syndication (2KBD)
- We have previously suggested to the AIC that the MDA business models we create to describe collaborative role interactions provide the requisite level of detail for knowledge discovery in terms of promoting shared services across the Government. Since then, the ‘center of excellence’ idea included in the Line of Business initiatives have reiterated the application service provider model, and here again we submit that the business models that describe collaboration contracts are one solution to establish this service provider/consumer dialog, implying that we would intend to publish this information to some well known Registry so that it may be found by the community of service consumers at large. (2KBE)
- What we’re talking about here is not just information about the data that should be published, but as has been the theme of these comments, the information about the data is in the context of collaborations correlated to the FEA Reference Models, and describes the contracts of interoperability – which of course includes collaboration data model. This is a much richer way to establish the capability of a service provider or conversely the usability for a service consumer. (2KBF)
- We have suggested that the infrastructure described above can provide standards-based manifests (Reusable Asset Specification – RAS) of business model elements serialized as a set of XMI documents, which can be reconstructed and transformed for any modality of interaction appropriate to the syndication endpoint, which may be a central Registry, or perhaps a Registry that the central Registry points to, or a Registry used by a potential partner Agency who is exploring some extension of a service from another Agency. The OSERA implementation will assume that there is some syndication endpoint that is interested typically in either business or technical models, or both, and could in fact syndicate actual implementations of those models (source code) using exactly the same technology standards and techniques as described above in section 5.1. (2KBG)
- What we need is a common syndication mechanism, that will let the federation of Registries and Repositories form as appropriate to various runtime topologies and value chain choreographies dictate in accordance with the ‘ilities’ and policies they require. We don’t believe that a Registry needs to necessarily be permanently centralized, nor do we think it a good idea to or a requirement for a DRM implementation to act as a Repository and be in the middle of every collaborative interaction across the Government. The latter idea runs counter to what is in many ways the most successful technical architecture in existence – the World Wide Web. (2KBH)
- 6. Conclusions/ Recommendations (2KBI)
- The DRM should be conceived in a holistic way, discussing the ideas and their implementations concurrently. (2KBJ)
- We should not pursue standardization of individual DRM Volumes independent of each other. (2KBK)
- The DRM must provide an example that is comprehensible to its stakeholders and that illustrates the concepts in operation. (2KBL)
- The DRM Volume I should not reinvent names for well-known concepts and clarify those identified in various comments. (2KBM)
- Consider the MDA MOF ‘metalevel’ terminology to control the vocabulary in DRM discourse. (2KBN)
- Leverage the ideas and infrastructure that is enabling the Model-Driven Semantic Web, and examine open source implementations that are immediately accessible to the entire community. (2KBO)
- DRM sharing needs business and technical context, and our agencies' approach to Executable FEA should be examined as one solution. (2KBP)
- Align the DRM Categories with the Interagency Committee on Governmental Information (ICGI) Categorization of Government Information Working Group. (2KBQ)
- Examine our agencies' suggestions for using the FEA Line of Sight in addition to Collaboration models as Category keys to context. (2KBR)
- Leverage existing standards and model-driven techniques to simplify data assemblies based on collaborative context and policies. (2KBS)
- Utilize Aspect Orientation and the MDA modeling framework to weave security, privacy, quality and rights management policy into business models and technology implementations. (2KBT)
- Don’t create infrastructure that already exists or isn’t necessary for sharing, examine our agencies' suggestions regarding the potential of URN/DNS and federation/syndication possibilities. (2KBU)
