Skip to end of metadata
Go to start of metadata

This follows on the plea I made to think about services on top of Semantic Web / Linked Data resources. Carole called them 'top-middleware' services I think.

Would this make sense?

dLibra

  -> exposes content via Generic Semantic Web interface (Sesame API?, - we have Web Service available for that.) [Note from Juande: Sesame is a web service for giving back information on astronomical object names, what's this Sesame?]
  -> RO-services expose RO specific interface for (web) applications (SOAP service, Ruby gem, etcetera?)
  -> Various web applications can perform RO-specific I/O through an application-specific user interface (typically not made by us)

Notes

  • The RO model is independently exposed (hence, RO semantics available for any tool to use)
  • Combination of exposed RO-model (RDF) and generic RDF interface would do the trick already; RO-services make it convenient and allow us to control access.
  • RO-box would be one of the applications; Taverna, myExperiment, etcetera could be others, use for annotation?
  • The RO-services hide (SPARQL) details and are RO-specific.
  • No labels

2 Comments

  1. Unknown User (mroos) AUTHOR

    Juan: Sesame is a web service for giving back information on astronomical object names, what's this Sesame?]

    Sesame is also an RDF database. Its API has become the de facto standard for RDF database APIs. Many RDF databases support it. In my previous project a Web Service was made on top of it; it allows one to interact with any RDF resource (SPARQL endpoints) on the web that complies with the Sesame API (and a few others).

  2. Unknown User (soiland-reyes)

    I like this approach - it's layered so that the most general layer is just general access and basically future-proof (although the SPARQL query writer would need to know the particular bits of the ontology he's querying over), and a second RO-layer where you would need richer knowledge about the research object model - with the advantage that you can access recommendation models, write back changes, etc.

    REST-like it's of course desirable that the second layer are still just HTTP resources which you could follow links between anyway (as in the current RO SRS API), so that an URI returned from the Sparql endpoint can be stored, shared and followed.