We got a centralized Repository for extensions. Every OntoWiki can browse the available extensions and provides a install mechanism: in the [Extension-Configurator] or directly at http://your-ontowiki/exconf/explorerepo

The Repository is quite unique. It is basically a SPARQL-endpoint, which contains a repo model which imports multiple extension-models. A extension model contains DOAP data. The client within the Extension Configurator queries this model for all doap:Projects (which are extensions in our case).

This is what the list of available extenions looks like: repoclient

You can register new extensions here. reposerver

Registering a new or updated extension with our repo is basically just a import of its DOAP description into the repo model. As the short documentation says there are four steps to register a new extension, which we will explain a bit deeper here.

Develop your OntoWiki extension and release it somewhere

Develop the source files (HowTo), test your extensions locally, package into a zip archive, put it on a accessable webserver. We recommend GitHub (you will have the autogenerated zip of the current state there).

Create an RDF document which describes your extension

“eat your semantic dogfood” - create a DOAP file (as Turtle, NTriple or RDF/XML). Have a look here for an example on what properties are required. For example:

  • name (doap:name - the internal id of the extension. e.g. the folder name),
  • title (rdfs:label - the human readable name,
  • author (doap:maintainer - a URI for the author),
  • description (doap:description - a short abstract of what the extension does),
  • link to the zip - either from the versions (property: doap:file-release) or from the project (property: http://ns.ontowiki.net/SysOnt/ExtensionConfig/latestZip) (protip: if you use GitHub, this link can be omitted and the autogenerated zip of the master branch will be used), optional:
  • versions (older versions with each a zip),
  • extensions-internal config (look at the example - we came up with a rather complex way to encode multidimensional config arrays) optional: if you already have a default.ini file you can convert it with the file application/scripts/extensions-ini2n3.php (which takes a extension folder as an argument) (the script is currently only in the feature/semantic-extensions branch). This script is especially usefull when you have many config options.

Publish that description document as Linked Data on the web

protip: if you use GitHub, and you use the URL of the DOAP file as the URI of your extension (use that URI within the DOAP file), you will get pseudo-linked-data for free. for example the URI of the “site” extensions is https://github.com/AKSW/site.ontowiki/raw/master/doap.n3#site (notice the “raw”, which delivers the file and not a html view on it)

Ping this registry to integrate your extension meta data here

Either you enter this URI in the form on http://extensions.ontowiki.net and hit submit

or (much more awesome) you “ping” the repository with a semantic pingback. The pingback should go to the pingback service at http://extensions.ontowiki.net/pingback/ping/ and should contain following data:

  • source: yourExtensionURI (e.g. https://github.com/AKSW/site.ontowiki/raw/master/doap.n3#site)
  • target: https://github.com/AKSW/site.ontowiki/raw/master/doap.n3#site
  • comment: is ignored

Your DOAP file should contain a triple which connects your extension with our repository e.g.: <yourExtensionURI> <http://ns.ontowiki.net/SysOnt/ExtensionConfig/registeredAt> <http://extensions.ontowiki.net/repository>

The Repository listens to this event and will then retrieve your DOAP file and update its index. Your extensions becomes visible to millions of OntoWiki instances within seconds.

Tags: ontowiki