- 1. Making Inter-operability Visible Visualising
Interoperability: ARH, Aggregation, Rationalisation and
Harmonisation Michael Currie, Meigan Geileskey, Liddy Nevile,
Richard Woodman A Projectin the Victorian Department of Premier
& Cabinet
2. Summary
3. Disclaimer
- Using info mment to teach maths
- Not a scientific paper ...
- Information scientists, systems architects, administrators, DC
worshippers, ..
4. Context
- Dept PC developing Intranet
- Dept SD developing VOG (brochure-net)
- Most depts developing doc. mment systems
- departmental agencies have (sometimes) implemented, more or
less, DC-based Australian Government Locator Standard
- the Government needs discovery for all resources and
information interoperability
5. Context (2)
- a visualisation of interoperability to assist real-world
deployment of metadata
- a few metadata records, but the future of the
Whole-of-Government Intranet and all departments of government
6. Purpose of Project
- With minimal interference
- To accommodate work on extranet
- Influence new document management systems to prepare for
intranet
- To maintain local specificity and global discovery
- To increase interest and effort.
7. Previous Process
- Departmental mandate to manage information
- Monthly meetings of those interested in metadata from various
departments
- Only collaboration, cooperation,
8. Case Study Process
-
- what is inter-operability
-
- Aggregation, rationalisation, harmonisation
- Registry, repository, WOG search...
9. Interoperating
- - an action when one tries to mix and match across domains
-
- Agencies use many different strategies to make this
happen.
10. Interoperability
- - a state where there is interchange and exchange without
difficulty
-
- Government agencies needcompleteorabsoluteinteroperability -
every documentmustbe discoverable
11. Mapping for interoperation 12. What is good enough?
- Moderate inter-operability is good enough for information
re-use
-
- Departments like to maintain independence, operate in
silos
- Only perfect is good enough for Parliament
-
- public accountability is forcing the issue
13. Aggregation
-
- who has metadata, for what
- List all elements currently used
-
- is there a significant difference
14. Record review Live record 15. List review 16. Spreadsheet
review Live spreadsheet 17. Aggregation - review
- Looking at the list, are there problems?
-
- Too many things in the list
-
-
- Variations in application profiles, errors, and variation in
use of elements, formats, etc...
-
- Not all metadata is useful for discovery
-
-
- eg. random use of DPCvsDepartment of Premier and Cabinet
-
-
- searchers may miss some documents.
18. Emergent goals - 1
-
- Illuminate limitations in inter-operability resulting from
existing metadata practices
-
-
- Articulate the cause of the problems
-
-
- Develop a shared strategy for improving the
inter-operability
19. Emergent goals - 2
- Encourage data managers to develop a single, comprehensive
metadata application profile
-
- derived from the current requirements and foci of all
users
-
- with high local specificity and deep interoperability.
20. Analysis
- Look at the list of elements and decide which
havematerialdifferences
- **Remembering that each agency valuesallits metadata
content
21. Material differences
- Mis-use of available elements,qualifiers etc
- Different expression of the same type of information
- Different element name for thesameinformation,
22. Element Name Variants
-
- eg. DC.Title/TITLE/title EDNA.Userlevel/UserLevel
- Non-standard nameseg. DC.Keywords
-
- eg. DC.Description.Abstract
- Non-standard abbreviations
23. Field Selection
- Standard and non-standard element names
-
- eg. 'description' and DC.Description
- Locally created element names
24. Value string Variants
- Despite DCMES recommendations
-
- other id numbers without qualifiers.
-
- also used yyyy, yyyy/m/d, yyyy-dd-mm
-
- Non-standard terms eg. VHS (PAL)
-
- Incorrect case eg. text/HTML
25.
- DC.Language: also used en, en-au, en-AU
- Qualifiers embedded in values:
-
- DC.Publisher CONTENT="corporateName=State..."
- Non-standard proper names
-
- DPC for Department of Premier and Cabinet
- ->Generally inconsistent use of capitalisation and
punctuation
26. Observation
- Most element variants due to non-standard use of capitals,
punctuation, spelling
- Users seem to act independently of Application Profiles
- Little use of collection specific qualifiers to enhance
specificity
27. Rationalise!
- Add qualifiers to each type of element?
-
-
- no less elements but significantly increases semantic
interoperability
- Dumb-down for interoperation?
-
-
- Loss of precision, too many documents from search but not
everything is found
- Cross-map ontologies, one to another
- Map everything to a new ontology
28. Rationalise (a process?)
- Decide what is disposable/worth saving given chosen
strategy
- Delete disposable elements
- -> The list gets shorter, semantic inter-operability is
improved.
29. Harmonisation
- Work together to choose appropriate formats and definitions for
elements and qualifiers
- **Remembering that, locally, departments will want more and
less precision
30. Harmonisation (process?)
- in DC.date - maybe just a different format so its obvious what
to do
- in DC.subject - some use AGIFT, some use SCIS,some use NREs
geo-spatial thesaurus, etc. - consensus work to be done
31. Results from ARH - HA?
- DPC Project is working on towards an Intranet, harmonising the
application profiles
32. Supporting granularity -technologies
- Registries - leads to the well-defined full WOG ontology
supporting evolving granularity
- Federated Metadata repositories preserve local control and
remote interoperability
33. Key service providers - VOG VOG DoJ DoI DNRE 34. Key service
providers - WOG WOG AP VOG AP 35. The grammar of DC metadata
http://www.dlib.org/dlib/october00/baker/10baker.html 36.
- Resource has property (subject):
-
- about Victorian rural land
-
- about Victorian rural land in section 43
-
- about Victorian rural land in section 43 in January 2002
The grammar of DC metadata 37. Does your resource speak Dublin
Core (AGLS)?
- Pidgins are inherently limited in what they can express, but
they are easy to learn and enormously useful. In real life, we talk
one way to our professional colleagues and another way to visitors
from other cultures. Our digital library applications need to do
this as well. Simplicity and complexity are both appropriate,
depending on context. If Dublin Core is too simple or generic to
use as the native idiom of a particular application, pidgin
statements may be extracted or translated from richer idioms that
exist for specialized domains. This output should also be filtered
to keep the fifteen buckets clear of encoding debris and semantic
silt. One should treat digital tourists with courtesy and hide from
them the complexities of a local application vocabulary or grammar.
However sophisticated its local idiom may be, an application might
also speak a pidgin that general users and generic search engines
will understand. Simple, semantically clean, computationally
obvious values will help us negotiate our way through a splendidly
diverse and heterogeneous Internet. (Tom Baker,
http://www.dlib.org/dlib/october00/baker/10baker.html)
38. Pidgin vs Symbolic Languages
- Pidgin languages serve for good enough communication
- Symbolic languages serve for complete communication in
abbreviated form