Dear Till & Ken, (01)
This is great! Thank you for putting in all the work. (02)
I made one change to the routing ... This is probably low level
details that should fit better in the [ontolog-dev] mailing list,
rather than the [ontology-summit] mailing list (of course, we
definitely still want this routed and archived in [oor-dev] too.) (03)
Thanks & regards. =ppy
-- (04)
On Wed, Mar 13, 2013 at 8:12 AM, Till Mossakowski
<Till.Mossakowski@xxxxxxx> wrote:
> Dear Ken,
>
> many thanks! (05)
> Am 13.03.2013 15:11, schrieb kenb:
>
>> The API is currently a REST API and is the same as BioPortal, see:
>>
>> http://www.bioontology.org/wiki/index.php/NCBO_REST_services
>
>
> OK. I have taken a quick look.
> Note that Ontohub needs a much richer and sometimes also different API. This
> is because Ontohub not only supports OWL ontologies, but also ontologies
> written in other languages, e.g. Common Logic. (If I recall right, OOR
> shares this goal.) (06)
> Let me be more specific, commenting on Bioportal's API methods:
>
> * List all the latest version of ontologies
> * Get a specific ontology based on a version id
> * Download an ontology file
> * Download the latest ontology file
> * Get all versions of an ontology from a virtual ontology id
> * Get latest version of an ontology id
> * Get Metrics for an ontology version
> * Get all the namespace prefixes for an ontology version
>
> These should be fine for Ontohub. However, since Ontohub will support
> multiple ontology languages (and these are first class citizens), we need
> more services, for listing ontology languages, their translations etc. (07)
> * List all ontology categories
> * List all ontology groups
>
> These are missing in Ontohub - we should add them! (08)
> * Download a specific ontology view based on the ontology view version id
> * Get all view versions of a virtual view
> * List the latest version of all Views
> * Get all versions of views from a virtual ontology id
>
> It seems that views assume that the ontology contains a class hierarchy.
> This is not (per se) the case for e.g. Common Logic ontologies. Hence, these
> services will apply only to specific ontologies. Moreover, for Common Logic,
> there will be other services, specific to Common Logic. This raises the
> issue of ontology language-specific services and their handling. (09)
> * Search BioPortal
>
> This also partly is specific to OWL and needs to be generalized. (010)
> * Get term, including its properties, subclasses, and superclasses
> * Get all root terms for an ontology version id
> * Get a path between a term and the root
> * Get all terms using the specific ontology version id
> * Get all terms using the virtual ontology id
>
> Again, this is OWL-specific. We have generalized the term "term" to
> "symbol". A symbol can be a class of a property in OWL, a name or a sequence
> marker in Common Logic, and a function or predicate symbol in first-order
> logic. (011)
> * Get all available ontology properties using the specific ontology version
> id
>
> Again, this is OWL-specific. Properties are certain symbols, in Ontohub
> parlance.
>
> We need the following services: get all kinds of symbols (for a given
> ontology language), give all symbols of a given kind, etc. (012)
> * Get all direct instances for a given term
> * Get an instance and its property/value pairs
> * Get paths to root/leaves from a concept in the latest version of a given
> ontology
> * Hierarchy Services
>
> Again, these are OWL-specific. (013)
> * Bio2RDF Dump Service
> * RDF Term Service
> * RDF Download Service
>
> In Ontohub, you will have several serializations per ontology language. So
> will will have services: list all serializations of a given ontology
> language, dump a given ontology using a given serialization. (014)
> * Annotator Service
>
> This service it specific to bio ontologies. How to generalise it to other
> domains? It seems that some (more static) list of service types and (more
> dynamically growing) list of actual services (conforming to these service
> types) would be useful. This of course also includes services like OOPS! (015)
> * Ontology Recommender
>
> Interesting challenge to generalise this to ontologies written in arbitrary
> languages... (016)
> * Resource Index Service
>
> could be adapted for Ontohub, if "concept" is replaced by "symbol" (017)
> * Notes Service (Term Proposals and Comments)
>
> fine for Ontohub (018)
> * Mapping Services
> * Get a single mapping
> * Get a list of mappings filtered by parameters
> * Get a list of mappings for a term
> * Get a list of mappings between two terms
> * Get a list of mappings for an ontology
> * Get a list of mappings between two ontologies
> * Create a new mapping
> * Update a Mapping
> * Delete a Mapping
> * Mapping Statistics
> * Get Recent Mappings
> * Get Number of Mappings To/From Given Ontology
> * Get Number of Mappings to Terms in Given Ontology
> * Get Number of Mappings by Users for a Given Ontology
>
> fine as well, if "concept" and "term" are replaced by "symbol". (019)
>> As you noted, the plan is to specify the repository content using an
>> ontology. To this end, BioPortal has been developing a SPARQL endpoint
>> that is still being tested. It is documented at:
>>
>> http://www.bioontology.org/wiki/index.php/SPARQL_BioPortal
>>
>> When that is completed, it could form the basis for an OOR SPARQL
>> endpoint. This should take care of expressing the query method of the
>> API in terms of an ontology. However, the rest of the API is in REST
>> (no pun intended) which is far from being ontology-based.
>>
>> To base the rest of the API on an ontology, I analyzed the API and
>> expressed it in terms of SOAP. Here is the proposed WSDL for OOR:
>>
>> http://www.ccs.neu.edu/home/kenb/oor/OORService.wsdl
>>
>> I also expressed it in terms of Java:
>>
>> http://www.ccs.neu.edu/home/kenb/oor/OORI.java
>>
>> One can support both SOAP and REST simultaneously with the same server
>> using my soaprest package, but this has not yet been done for OOR.
>>
>> Moreover, the WSDL is based on an earlier version of BioPortal, so it is
>> no longer fully compatible with the OOR instances. However, the WSDL is
>> reasonably close.
>
>
> Our plan for Ontohub is to start with RESTful services, like Bioportal does,
> also because this is simpler in Ruby on Rails. But I agree that a WSDL
> version is ontologically cleaner... (020)
>> I hope this helps clarify the situation. Let me know if you have any
>> other questions.
>
>
>
> All the best,
> Till
>
>
> (021)
> --
> Prof. Dr. Till Mossakowski Cartesium, room 2.51 Phone +49-421-218-64226
> DFKI GmbH Bremen Fax +49-421-218-9864226
> Cyber-Physical Systems Till.Mossakowski@xxxxxxx
> Enrique-Schmidt-Str. 5, D-28359 Bremen
> http://www.informatik.uni-bremen.de/~till/
>
> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
> principal office, *not* the address for mail etc.!!!:
> Trippstadter Str. 122, D-67663 Kaiserslautern
> management board: Prof. Wolfgang Wahlster (chair), Dr. Walter Olthoff
> supervisory board: Prof. Hans A. Aukes (chair)
> Amtsgericht Kaiserslautern, HRB 2313
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-dev/
Subscribe/Unsubscribe/Config:
http://ontolog.cim3.net/mailman/listinfo/ontolog-dev/
Shared Files: http://ontolog.cim3.net/file/work/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-dev@xxxxxxxxxxxxxxxx (022)
|