This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Ecoterm"
Jump to navigation
Jump to search
| Line 19: | Line 19: | ||
# Be clear about what a URI identifies | # Be clear about what a URI identifies | ||
#* Concepts? Classes? Something else? | #* Concepts? Classes? Something else? | ||
| − | # Publish RDF descriptions of the things you are identifying | + | # Publish [http://www.w3.org/RDF/ RDF] descriptions of the things you are identifying |
# Use ‘well-established’ RDF vocabularies as far as possible, extend as appropriate | # Use ‘well-established’ RDF vocabularies as far as possible, extend as appropriate | ||
# make commitments to maintaining RDF descriptions, and publish maintenance policies and procedures | # make commitments to maintaining RDF descriptions, and publish maintenance policies and procedures | ||
| Line 34: | Line 34: | ||
# Analyse and publish functional requirements for service types (I.e. what do I want a service to do?) | # 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) | # 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) | + | # Take a look at [http://www.w3.org/TR/2004/WD-rdf-sparql-query-20041012/ 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 | ** 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:20, 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
