ontohub / ontohub

A web-based repository for distributed ontologies.

Ontohub

A web-based repository for distributed ontologies, models and specifications.

An ontology is a formal, logic-based description of the concepts and relationships that are of interest to an agent (user or service) or to a community of agents. The conceptual model of an ontology reflects a consensus, and the implementation of an ontology is often used to support a variety of applications such as web services, expert systems, or search engines. Therefore, ontologies are typically developed in teams. Ontohub wants to make this step as convenient as possible. Besides ontologies, Ontohub also supports formal models and specifications, or more generally, logical theories.

Ontohub aims at satisfying a subset of the requirements for an Open Ontology Repository (OOR) and is being developed in close donnection with the Distributed Ontology, Modeling and Specification Language (DOL), which is part of the emerging Ontology, Model and Specification Integration and Interoperability standard (OntoIOp) at OMG. For more information from this perspective, see the Ontohub home page.

This application started at the compact course agile web development given by Carsten Bormann at the University of Bremen in March, 2012. The concept and assignment came from Till Mossakowski, now in Magdeburg and Christoph Lange.

Initial developers are Julian Kornberger and Henning Müller.

Developer- and deployment-centric documentation can be found in the doc/ directory and in our Wiki pages.

Installation

A guide to set up your own instance of ontohub you can find in the deployment guide.

Also a guide for development environment for Mac OS X and Ubuntu in the Wiki.

License

Copyright © 2012 Universität Bremen and Universität Magdeburg, released under the GNU AGPL 3.0 license.

ontohub's Issues

Improve search

Use Solr to find axioms and ontologies by their names. It should also be possible search for name parts.

Support DOL import

Hets will soon support DOL as a language. Ontohub should be able to import DOL ontologies. The individual components of a DOL ontology (basic ontologies and links between them) should be extracted into the existing Ontohub database schema. Additionally, the DOL ontology as a whole should remain accessible.

Shorter display of URIs in most places

E.g. in the list of entities, URIs should be abbreviated to the fragment ID or to the last path component (i.e. the substring after the last # or /).

Full URI should be shown on hover.

Mapping ontology version content

Should the following URL map to the list of entities of the current version of the ontology?

http://localhost:3000/ontologies/1/entities

If so, how?

CRUD interface for maintaining logic mappings

In addition to the existing interface (which also needs to be extended) for maintainin​g logics, we need an interface for maintainin​g translatio​ns between logics. The right management should be them same as for ontologies.

For a mapping, the following is displayed:

• iri
• source logic
• target logic
• kind # not sure whether we really need this field...
• standardization_status # see class Logic, STAND_STATUS
• defined_by # see class Logic, DEFINED_BY
• default # for a pair of logics, there may be at most one default mapping
• projection # or translation
• faithfulness # possible values: see class LogicMapping, FAITHFULNESSES
• theoroidalness # possible values: seeclass LogicMapping, THEOROIDALNESSES

Also, the list of adjoint mappings should be displayed (see join table logic_adjoints).

Complex links with entity maps

As soon as simple links (#17) work, we need the variant with an additional entity map. The latter is a set of "entity URI → entity URI" pairs, where the left entity is from the link's source ontology, and the right entity from the link's target ontology.

This relation is functional, i.e. one source ontology entity maps to at most one target ontology entity.

Each map entry should have a confidence value of 0, 1 (default), or anything in between. This is a floating point number, datatype double.

Propose a database table for correspondences, with IRI, source entity, target entity, the link it belongs to, confidence value, type of correspondence. In this way, each link is associated with a set of correspondences.

Metadata should be editable

List failed ontologies only if requested

By default the list of ontologies (and the corresponding view on the entry page) should not list ontologies on which Hets failed.

But there should be a checkbox to enable listing them. Both on the "list of ontologies" page, and in the user profile configuration.

Migration to Bootstrap by Twitter

Migrate to this fancy CSS Framework:
http://twitter.github.com/bootstrap/

Using this Gem:
https://rubygems.org/gems/bootstrap-sass

Some misleading information in bulk upload interface

First of all, the bulk upload interface (which I didn't use so far) is excellent!

Just some minor things that could be improved:

• I think that, here, success (the green "created" message) merely means that an ontology was successfully retrieved from its URL. Maybe not even that, as it happened to me that I quickly switched to the "ontologies" view, and the status was still "downloading". In any case one might get the false impression that Hets succeeded on the ontology, which need not be the case.
• Here and elsewhere I would use a consistent terminology. The "create ontology" interface speaks of "URL to import the ontology from", whereas it is "bulk upload". I tend to favor "import" – but you might object, as it might be confused with one ontology importing another ontology, i.e. with the link type "import" between two ontologies.
• It would be nice if the successfully retrieved ontologies in the "progress bar list" could directly be linked to their ontology pages, as I think the user would often like to go there in the next step. Same for some errors such as "URI has already been taken" (BTW "URI" should be in uppercase!)

Update tests to new database model

Display notifications on login

Notifications of a user (e.g. #20 or #21) should not only be e-mailed, but also be displayed to the user upon login, and removed when the user ticks them off.

Once this works, (additional) e-mail notification should be made customizable in the user profile (default: do notify by e-mail).

Setting URI on import is actually wrong

"Create ontology" makes a URI mandatory. I know I requested this behavior, but actually I understood that it's wrong.

Many ontologies have their own URI declared inside; at least in OWL it's common practice, but it's even possible in Common Logic. When ontologies are published in linked data style (something on which we can't rely though, and which we don't know before having downloaded and processed the ontology), URL and URI coincide.

However, we will only find out the URI of an ontology by running Hets on it. Hets does not yet tell us the URI though.

As we need to prepared for Hets to fail, or for an ontology not declaring its own URI (which is often the case in Common Logic, RDF, and most other logics), we should assign a reasonable default: the Ontohub URL. (This is reasonable in any case; see #24.)

This whole business requires the URI field to be removed from the "create ontology" dialog. Still we should be prepared for the user wanting to override the Ontohub-/Hets-assigned URI of an ontology; the current "edit ontology" dialog is sufficient for this.
#24

Allow custom URIs below the Ontohub site URL for ontologies and other things

In accordance with #24, ontologies should not only be able to have URIs=URLs like http://domain.tld/ontohub-installation/ontologies/NUMBER, but instead of NUMBER it should be possible to provide a custom name or path.

Depending on how this can be implemented, named ontologies may redirect to numbered URIs.

If the custom path includes a fragment (http://domain.tld/ontohub-installation/ontologies/name#the-ontology), note that clients will only request http://domain.tld/ontohub-installation/ontologies/name from Ontohub (and has to find the fragment on its own, in the data downloaded). Therefore, the URI part before the fragment needs to be unique already.

This approach should be implemented in a generic way, so that we can have the same functionality for links, logics, entities, etc.

Warn before deleting an ontology that has metadata or comments

Before deleting an ontology that has metadata or comments, Ontohub should warn the user who requested the deletion. The warning message should not just be "really delete?", but:

This ontology has NNN metadata entries and NNN comments created within Ontohub. Deleting this ontology will also delete its metadata and comments. Do you really want to delete the ontology?

"Another file with same checksum already exists" should point out the culprit ontology

It can be annoying to get this error message when you don't remember the ontology to which the "other", existing file belongs. In my testing I gave the ontologies random names and URIs and had to try quite some searches to track down the "other files". It might help if Ontohub pointed me to the ontologies (or their versions) to which these files belong.

Propose database change for versioned ontologies

such that all versions are in the database along with their metadata, axioms and entities. There should be a flag indicating the current versions.

Update rails models to new database structure

OntoHub as BioPortal tab

BioPortal "tab" implementation details - see: http://palexander.posterous.com/extending-bioportals-rails-ui

Autocomplete kinds by searching with "kind:…"

Ontohub knows all entity kinds used so far. Therefore it should be easy to offer autocompletion of kinds when searching via "search-phrase kind:…".

List axioms containing matching entities in entity search

When narrowing the entity search to one ontology (#1), axioms containing at least one matching entities should be listed as well.

E-mail notification on changes to teams managed by me

When someone removed himself from a team of which I am an admin, or was removed by a co-admin, I should be notified.

http://omdoc.org/ontology# fails to import (404 not found)

I have an ontology at http://omdoc.org/ontology#. When I import it into Ontohub using this URI=URL, it says "404 not found", whereas it can be downloaded from http://omdoc.org/ontology and then fails for a different reason (#28).

Even though the URL fragment is irrelevant for retrieval, it makes a difference wrt. linked data deployment (303 vs. no 303), so the right way to import this ontology is to use the hash.

Using or not using the hash should not make a difference to downloading. I tried it with wget and in both cases the result was the same: successful download of the ontology.

Narrow search to a particular ontology

When matches for a search by entity name are found in an ontology, the search result listing only shows the first 10 hits. It should be possible to narrow the search to a particular​ ontology, and to explore all hits in this ontology.

Related: #8

Textarea for editing ontologies

An ontology should be editable online in a big text area.

When the ontology is too big for editing inside the browser (whatever this means exactly), it's good enough for now to say "editing not possible" and point the user to the possibility of downloading and re-uploading.

Display change-affected links and distributed ontologies with propagate checkbox

Upon a change to an ontology or to a link, display the affected links and distributed ontologies and display a propagate checkbox for those to which the user has writing access.

Invite persons who do not yet have a user account

In the UI for assigning permissions it should be possible to assign permissions to persons not yet registered. The latter should then receive an invitation e-mail, which starts their registration process.

Store distributed ontologies in the database (to be discussed)

Christoph and Daniel have come up with three ways to store distributed ontologies in Ontohub's database.

1. Create Distributed Ontologies Table
   If we consider a distributed ontology (or library) something different than an ontology, we can store them separately in their own table "distributed_ontologies" and "distributed_ontology_versions" and bind them to the contained ontologies and links with the tables "contains_ontology_version" and "contains_link_version".

2. Reuse Ontologies Table with distinct relational tables
   If we consider a distributed ontology (or library) a special kind of ontology, we can store them in the "ontologies" table with the flag "distributed" set to true. The contained ontologies and links would be bound to them with the tables "contains_ontology_version" and "contains_link_version". When an ontology is not distributed, we would allow it to contain exclusively entities and sentences in the controllers and views, whereas if it is distributed, we would allow it to contain exclusively non-distributed ontologies and links.

3. Reuse Ontologies Table with the same relational tables
   If a distributed ontology (or library) is considered a special kind of ontology and its ontologies and links are considered its entities and sentences, we can store the distributed ontologies in the "ontologies" table with the flag "distributed" set to true and create the relations "entity_is_ontology" and "sentence_is_link" to bind the contained ontologies and links to the contained entities and sentences.

GUI
Option 1 makes sense if we have one listing for distributed ontologies and another for non-distributed ones.

Controllers
Option 1 – create controller with "list", "new", "create", "edit", "update", "delete"
Option 2 – create controller with "new", "create", "edit", "update" and change "new", "create", "edit" and "update" of another controller
Option 3 – create controller with "new", "create", "edit", "update"

Number of Tables
Option 1 – 5 tables
Option 2 – 2 tables
Option 3 – 2 tables

Search in this ontology

As an alternative to #7, it should be possible to "search in this ontology" from the ontology browser view.

Add sort criteria for ontology results

The list of ontologies should also show the date of last change or upload (same as the list on the main page).

Additionally, the list should be sortable by

• ontology URI
• ontology name
• date
• logic
• number of entities
• number of axioms

Simple links between ontologies

From any ontology in the repository allow to create a link to any other ontology. (@tillmo, including the original ontology itself? TM: no)

Propose a database change: the existing table "link" should be prepard for versioned links between versioned ontologies. Each link should have an IRI, metadata, a source and target ontology, version, the type of link, and the conservativity status. As for ontologies, there should be a flag indicating current versions.

Link types:

• alignments
• logical links, which are in turn divided into:
  ** imports
  ** interpretations, with proof status: proved, disproved, open

Conservativity status:

• ccons
• mcons
• mono
• def
  with proof status: proved, disproved, open

Provide a means for refering to external ontologies and entities

The tables for ontologies and entities should get an "external" flag. When it is set, the information about the ontology resp. entity needs to be retrieved from the web instead of from the database.

Select owner team on import

On import (including bulk upload) it should be possible to select a team, which becomes the owner of the ontology.

Versions tab no longer allows to download

@corny, @nning: I recall that the "versions" tab offered to download all previous versions of an ontology. Now this is no longer available.

E-mail notification on team deletion

A user should receive an e-mail notification when a team has been deleted of which he was a member.

Content negotiation between HTML, RDF/XML, plus optionally JSON and XML

First of all, which formats do we need, why do we need them, and what MIME types do they have?

• HTML (for the UI): text/html or application/xhtml+xml
• RDF/XML (we do not yet have this, but an RDF vocabulary for DOL is under development, and should be used by Ontohub): application/rdf+xml
• JSON (we get it for free from Rails, so let's serve it): application/json
• XML (we get it for free from Rails, so let's serve it): application/xml or text/xml.

Content negotiation works as follows: The client lists the requested MIME type in the Accept header of its HTTP request. If we have the format, we serve it. If we don't have it, we return "406 Unacceptable".

The serving should take place directly (unless linked data compliance requires a 303 redirect; see #33). Rails does support URLs with extensions such as ".json" (if I understood @corny correctly), but when some MIME type is requested from a URL without such an extension (e.g. /ontologies/MyOntology), we should serve it directly from this URL.

This applies to all relevant things (ontologies, entities, links, etc.) in Ontohub – whether their URIs are URLs within the Ontohub site (e.g. an ontology identified by the URI http://ontohub.informatik.uni-bremen.de/ontologies/Pizza), or whether we imported ontologies with external URIs into Ontohub.

Note that hardly any client will mention no MIME type explicitly. All modern browsers explicitly request HTML. Still, for clients such as wget, we should decide which format to serve by default.

Update database migrations

Create a new git branch and update the existing migrations to the new database scheme. Also, for the new database tables, create new migrations, using "rails generate migration ..." or "rails generate scaffold ...".

Please attache the picture here.

We also need a table for ontology language translations, and possibly also for logic translations (btw - Christoph, do we distinguish these in the WD?).

Write a test server that sends requests to the Hets RESTful service

Simon implements the RESTful interface, see http://trac.informatik.uni-bremen.de:8080/hets/wiki/RESTfulInterface

He needs some testing facility. Since OntoHub needs to communicate with Hets' RESTful interface anyway, I suggest to write some OntoHub test server that sends at least one request for each request type to Hets.

As test IRI, you can use:
http://colore.googlecode.com/svn/trunk/ontologies/core/graphs/simple_graph.clif
Note that this generally must be escaped, e.g. / becomes %2F

Hets error when importing an OWL ontology from a *.rdf file

When importing an RDF ontology (such as http://xmlns.com/foaf/spec/index.rdf, which is actually OWL that happens to be encoded as RDF), Ontohub reports that Hets failed with Logic.sym_name not implemented for: RDF. But according to http://trac.informatik.uni-bremen.de:8080/hets/ticket/1014 it is not Hets's fault.

BTW I can't reproduce this error right now, as the demo installation is broken. So maybe the bug has been fixed already.

Import distributed ontologies from DOL files

Provide link to github homepage

The Ontohub GUI should link to https://github.com/ontohub/ontohub, so that users know where to report bugs (and where do download the software, and where to get further help).

Some ontologies listed with file:// URIs

For some/all ontologies (need to investigate further, can't reproduce right now) Ontohub's search and/or ontologies views (not sure right now) display internal file:// URIs.

They should instead display

• the name of the ontology (if given)
• or the URI of the ontology

update the description for installing a development environment

Comments on symbols and axioms

Any user should be able to comment on symbols and axioms (same as supported for ontologies already).

An easier way: comments apply only to ontologies, but if a comment mentions a symbol or an axiom name, it will be displayed (or linked) at the symbol or axiom.

Give admin rights to first user account that is created and confirmed

Not sure if this is implemented already, so let me write this ticket to make sure.

The first user account that is created in a new installation should receive admin permissions – but only after confirming the e-mail address. Otherwise I think we might have a problem, if the first user who registers mistypes his e-mail address.

Encourage users to give URIs within Ontohub's site URL to ontologies

If users give their ontologies URIs that are within Ontohub's site URL (realistically: the "ontologies" path), these ontologies can be served as linked data (see milestone for explanation).

Users should be made aware of this possibility on assigning a URI to an ontology.

Note: If the ontology is in a language that itself allows for assigning URIs to ontologies (e.g. OWL), and if in the source of the ontology no description of the Ontohub-assigned URI can be found, this is practically useless. A linked data client would be able to download something, but only to find out that this data packet is not "the ontology" sought for.

add proof status information for proof goals

proof goals are sentences with is_axiom=false.

In Hets, we have the following proof status information:

-- | data type representing the proof status for a goal
data ProofStatus proof_tree = ProofStatus
    { goalName :: String
    , goalStatus :: GoalStatus
    , usedAxioms :: [String] -- ^ used axioms
    , usedProver :: String -- ^ name of prover
    , proofTree :: proof_tree
    , usedTime :: TimeOfDay
    , tacticScript :: TacticScript }
    deriving (Show, Eq, Ord)

This should go into a new database table

Linked data compliant 303 redirects for things that do not have a URI fragment

When serving data in a semantic-web/linked-data compliant way (for details see http://www.w3.org/TR/cooluris/ – but I will try to explain all relevant basics here), the client must be able to distinguish between "the web page" = "the HTML document" and "the immaterial thing described by the web page" (e.g. "the ontology").

In short (details below):

• When something is requested from a URL of which we know that all things (e.g. ontologies) retrievable from this URL have URIs with a fragment ("hash URIs"), we perform content negotiation (#32) and, if available, return the thing with "200 OK".
• Otherwise, we make a "303 See other" redirect to some other URL, from which the actual thing can be retrieved.

This should work for all relevant entities in Ontohub: ontologies, entities, links, logics, translations, etc. Note that entities are tricky and may require further discussion. One entity ''may'' occur in different ontologies, e.g. most OWL ontologies redeclare some Dublin Core entities even though they are not within the namespace of the ontology. There might be contradictions: dc:description is usually declared as AnnotationProperty (for DL compliance), but an OWL Full ontology may declare it as DatatypeProperty. We need to discuss how to serve an entity when it occurs more than once in the Ontohub database.

You can test the implementation with wget --header='Accept: application/rdf+xml' -O /dev/null -S http://ontohub..., or with http://validator.linkeddata.org/vapour. Here are two examples of URIs where the correct behavior is implemented:

• 303: http://dbpedia.org/resource/Bremen
• 200: http://omdoc.org/ontology#Definition

An example, which you can skip once you are familiar with the topic: Suppose we have a URI "/entities/Harry_Potter". This may host two different things:

1. an entity in an ontology, or in the HTML rendering of the ontology (called "information resource"), which describes the book "Harry Potter". The author of the ontology is Christoph Lange.
2. the book "Harry Potter", written by J. K. Rowling.

For URIs that contain a fragment (which may be empty, as in /entities/Harry_Potter#), and which are therefore also called "hash URIs", the convention is: If the URI contains a fragment, it represents a real-world thing (also called "non-information resource"), such as "the book Harry Potter".

If we know that the book is identified by /entities/Harry_Potter# or by /ontologies/books#Harry_Potter, and if a client requests /entities/Harry_Potter or /ontologies/books (the fragment is not part of the request; the client has to find the fragment on its own in the data it downloaded) – then we return the thing with 200 OK. Then, the client knows that /entities/Harry_Potter or /ontologies/books is an "information resource" (ontology or HTML source code), and that, if this information resource contains a fragment # or #Harry_Potter, the latter is the real-world thing.

If we know that the book is identified by, e.g., /ontologies/books/Harry_Potter, and if we get a request for this URL, we can't serve it with 200 OK, as otherwise the client would think that /ontologies/books/Harry_Potter is an "information resource" – but it is not. It is a real-world thing. So we have to 303-redirect to a URL that hosts the information resource. If the path "/data" is still available, I would use it, e.g. to redirect from /ontologies/books/Harry_Potter to /data/books/Harry_Potter. This URL doesn't have to look nice; it's a purely technical thing. The client will then request some MIME type from this URL, and we will perform content negotiation (#32) and deliver the content if available. See http://www.w3.org/TR/cooluris/#r303gendocument for an explanation.

I know that …

• not all semantic web sites implement this behavior properly, but for us it matters, as the real-world things described in our ontologies may have different metadata (e.g. authors) than our ontologies.
• this redirection is inefficient, but it is an agreed-upon standard, and the community is already discussing alternatives.

Implement iOS gui actions (to be discussed)

1. view mode

• add menu
• edit button
• items

2. edit mode

• done button
• selectable items
• remove button (active when items are selected)
  export menu (active when items are selected)

3. add menu

• copy [an ontology] from
• * [this] computer
• * [a] webserver
• link [an ontology] in
• * [a] webserver
• "create a new ontology"

5. export menu

• copy [the selected ontologies] to
• * [this] computer
• share [the selected ontologies] via:
• * e-mail

No filename extension appended to extension-less ontology files?

Importing http://omdoc.org/ontology fails with Hets expecting CASL.

BTW note that the right URL is actually http://omdoc.org/ontology#, but this doesn't work at the moment; see #27.

I suspect the cause is that the downloaded file is named "ontology", without a filename extension.

But I thought we had said earlier that, for now, extension-less downloaded files should be renamed to *.owl, as in most cases what you get from such "cool URI" URLs is OWL (or RDF, which Hets does not yet support completely).