Making Inter-operability VisiblePresentation Transcript
Making Inter-operability Visible Visualising Interoperability: ARH, Aggregation, Rationalisation and Harmonisation Michael Currie, Meigan Geileskey, Liddy Nevile, Richard Woodman A Project in the Victorian Department of Premier & Cabinet
The Case Study
Just what it is …
Using info m’ment to teach maths
Not a scientific paper ...
Information scientists, systems architects, administrators, DC worshippers, …..
->Generally inconsistent use of capitalisation and punctuation
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
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
Blanchi, ‘Harmony’, etc.
Rationalise (a process?)
Decide what is disposable/worth saving given chosen strategy
Delete disposable elements
-> The list gets shorter, semantic inter-operability is improved.
Work together to choose appropriate formats and definitions for elements and qualifiers
**Remembering that, locally, departments will want more and less precision
in DC.date - maybe just a different format so it’s obvious what to do
in DC.subject - some use AGIFT, some use SCIS, some use NRE’s geo-spatial thesaurus, etc. - consensus work to be done
Results from ARH - HA?
DPC Project is working on towards an Intranet, harmonising the application profiles
Supporting granularity - technologies
Registries - leads to the well-defined full WOG ontology supporting evolving granularity
Federated Metadata repositories preserve local control and remote interoperability
Key service providers - VOG VOG DoJ DoI DNRE
Key service providers - WOG WOG AP VOG AP
The grammar of DC metadata http://www.dlib.org/dlib/october00/baker/10baker.html
Resource has property (subject):
‘about rural land’
‘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
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)
Pidgin vs Symbolic Languages
Pidgin languages serve for good enough communication
Symbolic languages serve for complete communication in abbreviated form