Difference between revisions of "Semantic Web Ontology Portal Evaluation Approach"
From Earth Science Information Partners (ESIP)
(added reference to the current page on this topic) |
|||
| (4 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
= Introduction = | = Introduction = | ||
| + | |||
| + | <font color="red">This page is no longer the active planning document for evaluating possible ESIP ontoogy repository instances. The page you want for that is https://esipfed.github.io/stc/UseCases/STCUseCasesAndRequirements.html.</font> | ||
This wiki page supports ESIP's evaluation of semantic repository solutions in particular providing insight into; | This wiki page supports ESIP's evaluation of semantic repository solutions in particular providing insight into; | ||
| Line 8: | Line 10: | ||
All ESIP members (and anyone else with an account on this wiki) are encouraged to contribute towards this document. | All ESIP members (and anyone else with an account on this wiki) are encouraged to contribute towards this document. | ||
| − | = | + | = Semantic Repository Implementation Requirements = |
In general in this document: | In general in this document: | ||
| Line 25: | Line 27: | ||
=== Access capabilities === | === Access capabilities === | ||
| − | * Publicly accessible resources in the should be accessible via a Permanent Identifier (PID) (such as a DOI or equivalent) at both the resource and individual concept level which implies namespaces and redirect capabilities | + | * Publicly accessible resources in the should be accessible via a Permanent Identifier (PID) (such as a DOI or equivalent) at both the resource and individual concept level which implies namespaces, versioning, and redirect capabilities |
* When a Permanent Identifier technology dies (e.g., PURL's from OCLC) mechanisms to "fail over" to an alternate PID scheme relatively easily should be supported. This might be accomplished by supporting multiple PID technologies simultaneously and allowing resources to have multiple PID's at a variety of levels. | * When a Permanent Identifier technology dies (e.g., PURL's from OCLC) mechanisms to "fail over" to an alternate PID scheme relatively easily should be supported. This might be accomplished by supporting multiple PID technologies simultaneously and allowing resources to have multiple PID's at a variety of levels. | ||
| Line 37: | Line 39: | ||
==== General search and update capabilities ==== | ==== General search and update capabilities ==== | ||
| − | * Users should be able to specify a term (e.g., seaIce) and have the portal return all concepts that include that term. The ontology or resource that the concept comes with should be included in the result and the ability to further examine that resource (definitions of the terms, other metadata such as usage constraints, etc.). See [http://vocab.cc/v/search?query=publisher this set of results for a search for the term "publisher" in the site vocab.cc for examples.] | + | * Users should be able to specify a term (e.g., seaIce) and have the portal return all concepts that include that term. The ontology or resource that the concept comes with should be included in the result and the ability to further examine that resource (definitions of the terms, other metadata such as usage constraints, version history, etc.). See [http://vocab.cc/v/search?query=publisher this set of results for a search for the term "publisher" in the site vocab.cc for examples.] |
=== Browse capabilities === | === Browse capabilities === | ||
| Line 43: | Line 45: | ||
=== Display capabilities === | === Display capabilities === | ||
| − | + | * Display a list of semantic resources (e.g., ontologies) | |
| + | * Display the terms and relationships for a particular version of a semantic resource | ||
=== Download capabilities === | === Download capabilities === | ||
| Line 102: | Line 105: | ||
=== Maintenance === | === Maintenance === | ||
| + | |||
| + | = Comparative Evaluation of Portal Software = | ||
= Justifying Semantic Web Repository Business Costs = | = Justifying Semantic Web Repository Business Costs = | ||
Latest revision as of 21:30, February 9, 2017
Introduction
This page is no longer the active planning document for evaluating possible ESIP ontoogy repository instances. The page you want for that is https://esipfed.github.io/stc/UseCases/STCUseCasesAndRequirements.html.
This wiki page supports ESIP's evaluation of semantic repository solutions in particular providing insight into;
- what current and future ESIP Semantic Technologies Committee (STC) community requirements (CR) are,
- a comparative evaluation of different technology stacks/approaches; with the aim of assessing different solutions based upon how well they satisfy CR as defined within this document, and
- a business cost justification model that could be used to justify funding semantic web technology stacks.
All ESIP members (and anyone else with an account on this wiki) are encouraged to contribute towards this document.
Semantic Repository Implementation Requirements
In general in this document:
- 'ontology' refers to any semantic artifact, whether expressed in OWL/RDF, another OWL representation, or a simpler form like Excel or CSV that can be converted into a semantic artifact.
- URI is used to mean a unique web identifier, aka IRI; it usually but not always is a URL.
Features/Services
These are the functions we'd like to see offered by the repository:
Ingest capabilities
- It should be possible for a person with an ESIP account to upload their semantic resources to the repository
- It should be possible for a person with an ESIP account to upload new versions of their semantic resources to the repository.
Access capabilities
- Publicly accessible resources in the should be accessible via a Permanent Identifier (PID) (such as a DOI or equivalent) at both the resource and individual concept level which implies namespaces, versioning, and redirect capabilities
- When a Permanent Identifier technology dies (e.g., PURL's from OCLC) mechanisms to "fail over" to an alternate PID scheme relatively easily should be supported. This might be accomplished by supporting multiple PID technologies simultaneously and allowing resources to have multiple PID's at a variety of levels.
Search capabilities
User-specific search and update capabilities
- A logged in user (i.e., one with an ESIP account) should be able to query to obtain a list of their own resources in the repository
- A logged in user needs to be able to update their own information in the repository (i.e., profile including things like passwords, email addresses, etc.). Relevant updates need to proliferate to the resources that user has uploaded.
General search and update capabilities
- Users should be able to specify a term (e.g., seaIce) and have the portal return all concepts that include that term. The ontology or resource that the concept comes with should be included in the result and the ability to further examine that resource (definitions of the terms, other metadata such as usage constraints, version history, etc.). See this set of results for a search for the term "publisher" in the site vocab.cc for examples.
Browse capabilities
Display capabilities
- Display a list of semantic resources (e.g., ontologies)
- Display the terms and relationships for a particular version of a semantic resource
Download capabilities
Mapping capabilities
Inferencing capabilities
Query capabilities
Protocols
Protocols describe how the repository makes its information, submissions, and entries available: what syntax, semantics, and specifications are supported in the data and commands that go into the system, and come out of it?
Ontology download formats
Ontology upload formats
URI format for concepts and artifacts
API support
How many/which features are available to other applications via API calls? Are these calls REST-based?
How is the URI for each concept in the repository represented? How is the URI for each artifact represented? Are the offered URIs versioned, unversioned, or both?
Usability
Maintainability
- It must be possible to migrate the content and functionality of the repository to new technologies as they change over time. For example, migrating from google code to github seemlessly...
Ease of content submission
Ease of content updates
Documentation
Responsiveness
Reliability/Uptime
Authentication and Security
What types of login features are supported?
Support for Teams and Roles
Can teams be defined of multiple members? Can multiple members of a team edit the same ontology?
Cost
Costs are given in labor hours and funds required to start and operate the service.
Installation
Operations
Maintenance
Comparative Evaluation of Portal Software
Justifying Semantic Web Repository Business Costs
(see the [SW OPortal Discussion:Talk|Discussion] page for ideas.)
References
[1] ODM2 evaluation of MMI ORR: https://github.com/ODM2/ODM2/blob/07e4e30fc4d6763b8bcae771ffbb7228fc5a3f65/doc/ODM2Docs/concept_controlledvocabs.md
