up to all Development Components for VIVO 1.5

Component Description

This component involves developing a common API to write, read, and update any rdf data in VIVO, both from the application and from the Harvester. Will allow data added by the Harvester to trigger index updates, and will enable optional logging and/or auditing. Could be wrapped in an HTTP service

Anything that is doing an update to one of the graphs goes through one place to do it, to in part support e.g. effective logging and permissions, and would allow model listeners to be attached in one place.

Reads would also, but there would be other flavors applied on top of that.

This API will be used to achieve triple store independence and may or not be merged into that component in JIRA.

BrianL: envisioning this as the lowest level of access.
BrianL: get away from special pre-defined graph uris

Can we imagine this api being useful to parties other than the VIVO application, e.g. harvester and Miles (Drupal)

Long term goal would be to get rid of the ontology entity beans (which were triple store independence attempt) and that may be part of either this or the triple store independence. DAOs are convenience (from the point of view of application needs) wrappers around the model and they implement filtering.

In Jira this has been merged with Triple Store Independence and the component is now called "RDF API and Triple Store independence".

Scope of the component for v1.5

List things that are not in scope that people might assume are in scope

• ability for an application such as the harvester to make changes to a VIVO DB through this api.

Reduce and clearly define the ways that the model is accessed by the application.

--> listening to discrete model vs. listen to any change?

Design work needed for the component.h1. * decide whether we need to fully define our own api or use one that exists such as Jena, or Sesame repository

• strategy to move away from pre-defined uris for graphs used by the application
  • would be nice to have ability to discover uris that meet certain criteria. e.g. when writing sparql query that queries over whole dataset.

• implement the API and not use it.

• could implement a connector/bridge.

• convert the whole application to natively use the APIDependency on any other componenth1. this is either tightly coupled with or the same as triple store independence.A suggested incremental plan==