This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Ecoterm"
Jump to navigation
Jump to search
Line 10: | Line 10: | ||
=== [[Ecoterm:Services|Services]] === | === [[Ecoterm:Services|Services]] === | ||
+ | ---- | ||
+ | === Steps toward interoperability === | ||
+ | |||
+ | # Use URIs | ||
+ | # Use URIs well (consistency, persistence, articulated management & maintenance policies etc.) | ||
+ | # Be clear about what a URI identifies | ||
+ | #* Concepts? Classes? Something else? | ||
+ | # Publish RDF descriptions of the things you are identifying | ||
+ | # Use ‘well-established’ RDF vocabularies as far as possible, extend as appropriate | ||
+ | # make commitments to maintaining RDF descriptions, and publish maintenance policies and procedures | ||
+ | |||
+ | ** establish a semantic web of terminological / conceptual / ontological data relating to the environment | ||
+ | |||
+ | * Services? | ||
+ | |||
+ | ** With a web of data in place, the role of services becomes extremely clear: to provide efficient, convenient, programmatic Interaction with subsets of that web of data. | ||
+ | ** Build a service-oriented architecture on top of a web of data | ||
+ | |||
+ | * Steps to achieving this: | ||
+ | |||
+ | # Analyse and publish functional requirements for service types (I.e. what do I want a service to do?) | ||
+ | # Study functional requirements within this community, identify and publish sets of common requirements (basis for standardisation work) | ||
+ | # Take a look at SPARQL services & protocol (v. cheap) | ||
+ | |||
+ | ** N.B. true standardisation of a service interface requires a (lightweight, informal, open) community-driven process for developing a web-service specification and building consensus |
Revision as of 20:11, 22 April 2005
Contents
Action Points for the Following Year
The following points are based on a presentation by Alistair Miles at the 2005 Berlin Ecoinformatics meeting.
Identity
Construction
Data Model
Publication
Services
Steps toward interoperability
- Use URIs
- Use URIs well (consistency, persistence, articulated management & maintenance policies etc.)
- Be clear about what a URI identifies
- Concepts? Classes? Something else?
- Publish RDF descriptions of the things you are identifying
- Use ‘well-established’ RDF vocabularies as far as possible, extend as appropriate
- make commitments to maintaining RDF descriptions, and publish maintenance policies and procedures
- establish a semantic web of terminological / conceptual / ontological data relating to the environment
- Services?
- With a web of data in place, the role of services becomes extremely clear: to provide efficient, convenient, programmatic Interaction with subsets of that web of data.
- Build a service-oriented architecture on top of a web of data
- Steps to achieving this:
- Analyse and publish functional requirements for service types (I.e. what do I want a service to do?)
- Study functional requirements within this community, identify and publish sets of common requirements (basis for standardisation work)
- Take a look at SPARQL services & protocol (v. cheap)
- N.B. true standardisation of a service interface requires a (lightweight, informal, open) community-driven process for developing a web-service specification and building consensus