Governance Issues Governance Dimensions of data access infrastructures Rob Atkinson Social Change Online

AUKEGGS workshop, Edinburgh Sept 2005 Governance Policy Design Technology Implementation Cost-effectiveness of components established Design has to be informed by governance (policy implementation) but also by implementation Governance of components: Catalogues Common Models Service Level Agreements Technology can be driven by policy Lessons Learned

AUKEGGS workshop, Edinburgh Sept 2005 Overview Business Realities Standards Lifecycles Semantic interoperability Within-domain consistency Cross-domain enablement

AUKEGGS workshop, Edinburgh Sept 2005 Business Realities Scalable infrastructures must be adopted to be successful  One or two infrastructure paradigms per “node”  Current capabilities maintained  New ones trialled  Must be no significant barriers to adoption  Technical complexity of system vs simplicity of managing a node  Critical mass and community expectation ultimately wins

AUKEGGS workshop, Edinburgh Sept 2005 Business Realities Fear of change is overwhelming  Even when change is an acknowledged necessity! No solution is deployed, so all face scepticism Needs to provide obvious value  But more importantly needs to be seen as the simplest route for individual players Commitment of major players required  But within a governance framework that others are comfortable with

AUKEGGS workshop, Edinburgh Sept 2005 Business Realities It’s the future that matters  Is it a business risk to go a particular route? But the future is viewed through the present..  Are safe, productive, easy steps being offered?  Is there a commitment and capacity to manage infrastructure?  Is it adaptable and scalable?

AUKEGGS workshop, Edinburgh Sept 2005 Standards  Layer upon layer…  Encapsulate the “hard yards” into easy to use components  Easy to use only if the complete standards stack supported by quality implementations  Often multiple competing options  Usually due to poor separation of concerns  Typically forced to use a “poor” (ad-hoc) encoding because it’s the only semantic framework available…

AUKEGGS workshop, Edinburgh Sept 2005 Standards Lifecycle  Existing practice  Identified need to harmonise and extend  Roadmap  delegation to working group  Drafts  Revision  Testing  Adoption as baseline  Update strategy  Deprecation  Decommissioning

AUKEGGS workshop, Edinburgh Sept 2005 Semantic Interoperability No über-model exists Communities of practice  Commitment and business drivers  Re-usability and utility  Existence of a governance structure Semantics are declared not inferred  “This WCS serves MODIS data”  MODIS is not self-describing! Semantics implemented as a result of delegation  Delegate spatial semantics to OGC  IHO defines maritime navigation features  IHO delegates to ISO content standards  Etc

AUKEGGS workshop, Edinburgh Sept 2005 Within-domain consistency Achieved by reuse of semantic elements  By declaration The good news:  Reuse is easy for lazy people  Productive people are “strategically lazy”  Reuse means power  Standard nuts and bolts means powered tools are economically feasible  Graphics libraries means games programmers don’t need to know much 3D geometry Factor metadata around governance  Governance enables reuse!

AUKEGGS workshop, Edinburgh Sept 2005 Practical considerations No rocket science Clearly delineate roles with respect to necessarily reusable artefacts  The entity creating a data server might be the person who defines the data specification  OGC specs tend to assume it is (IMHO a simplification that causes a complex problem)  But in general, interoperability demands that the definition is agreed in a broader community

AUKEGGS workshop, Edinburgh Sept 2005 The “USER” will “DISCOVER” “DATA” and “ACCESS” it. Means a lot of work somewhere… We can model (and implement!) what is required

AUKEGGS workshop, Edinburgh Sept 2005

What it means Infrastructure must:  Define (or adopt) component standards (schemas for metadata artefacts)  Deploy capable components  Define governance arrangements – how are these roles assigned  Be a viable business proposition to participate  As one of a very few active participations!  Broker interoperability with other infrastructures  Have a strategy to adapt and adopt new expectations

AUKEGGS workshop, Edinburgh Sept 2005 Case study: biological observations Typical query:  What threatened species have been recorded in area X? a “join” is required between separately managed sources of information:  Taxonomy – terms, synonyms and hierarchy  Grouping – e.g. status according to Schedule A  Records  Spatial constraint

AUKEGGS workshop, Edinburgh Sept 2005 Join-in-situ at Data Access Service Data Access Service Term(s) Grouping type Term List (preferred) Record Set (with synonyms, Groupings, Preferred terms) Synonyms Used Groupings Records

AUKEGGS workshop, Edinburgh Sept 2005 Query.. Taxonomy Term(s) Grouping type Record Set (with inconsistent local synonyms only) Grouping Preferred Term(s) (for grouping) Taxonomy Preferred Term(s) Terms and synonyms Data Access Service Register Local synonyms

AUKEGGS workshop, Edinburgh Sept 2005 Response… Extract terms Taxonomy (Grouping) Term(s) If results to be presented according to grouping – e.g. Threatened, Vulnerable etc Groupings per term Taxonomy Service Term List (with preferred terms identified) Sort results Record Set (with synonyms) Presented Results

AUKEGGS workshop, Edinburgh Sept 2005 Over Hurdle 1….. Automate update of terms, from point of- truth services: Taxonomy Service Client Term List (preferred) Synonyms Used Groupings Records Grouping Taxonomy harvest update

AUKEGGS workshop, Edinburgh Sept 2005 Wrappers around “immutable” data sources: Wrapper Term(s) Grouping type Term List (preferred) Record Set (with synonyms, Groupings, Preferred terms) Synonyms Groupings Records Data Access Service Taxonomy Service Client Grouping Taxonomy Synonyms used A vocab from data Service – must match Synonyms in taxonomy High-bandwidth link

AUKEGGS workshop, Edinburgh Sept 2005 Solution success criteria Meets requirements can be extended to encompass more data services can be extended by new ways of looking at the data data is as simply re-usable as possible has clear and achievable governance requirements promises reasonable performance can be implemented in a partial solution initially provides mechanisms for improving data consistency over time