P-Rec. 5: Semantic repositories should offer a common API to access Semantic Artefacts and their content in various serializations for both use/reuse and indexation by any search engines #5
Semantic artefacts are distributed across the web in a variety of locations and formats. Semantic repositories act as aggregators of semantic artefact publishing both the metadata and the content of the semantic artefacts and providing a search engine and an API to search and access the content through dedicated services. However, the APIs to search and access content is specific to each repository which hampers the possibility to access content from multiple sources for use and reuse but also for indexing by search engine. Part of the API heterogeneity is linked with the diverse metadata schemata used by repositories to describe semantic artefacts.
To enable federated searches across repositories, it is necessary to harmonize the API landscape by defining a common set of API features based on a common minimum set of metadata for describing semantic artefacts (see P-Rec. 3).
Enabling automated indexing across repositories will require agents to access a machine readable description of the API and the description of information that can be accessed. Therefore, repositories should consider publishing at least the description of their API using OpenAPI specifications which will provide first a human readable API documentation in a machine readable format. A recent extension of the OpenAPI specification, called smartAPI[26], has been proposed to provide semantically annotated API description to make API FAIR. Such semantically enriched description could enable automated workflows for indexing semantic repositories.
Several other possible solutions exist i.e. publishing directly the content as Linked Data and to be compliant with the LD standards (Linked Data Platform, …), use a common inter-exchange metadata format such as RIF-CS or publish metadata and content using the FAIR Data Point service.
This recommendation does not aim to support any particular solution but rather emphasize the need for the community of semantic repositories to agree on a common solution.
The short answer here is YES and NO
We currently offer REST API publishing Linked Data (RDF) currently only in XML and a SPARQL endpoint.
We do not have an API spec describing our APIs though
Content negotiation by profile (https://www.w3.org/TR/dx-prof-conneg/) provides a Linked Data compatible API for flexible and transparent access to resources - it can co-exist with other functional APIs
Part of the API heterogeneity has evolved over time as an extremely lengthy list of options and capabilities has been built into a rich collection of REST interfaces. I did not see in earlier versions of OpenAPI/SmartAPI the ability to describe such rich REST resources.
Nor for that matter do those tools have the ability to describe a SPARQL endpoint, which is the most standardized way to access the semantic content of repositories, if it is offered. Of course the underlying triples model is not so standard from one repo to the next…
Description
Semantic artefacts are distributed across the web in a variety of locations and formats. Semantic repositories act as aggregators of semantic artefact publishing both the metadata and the content of the semantic artefacts and providing a search engine and an API to search and access the content through dedicated services. However, the APIs to search and access content is specific to each repository which hampers the possibility to access content from multiple sources for use and reuse but also for indexing by search engine. Part of the API heterogeneity is linked with the diverse metadata schemata used by repositories to describe semantic artefacts.
To enable federated searches across repositories, it is necessary to harmonize the API landscape by defining a common set of API features based on a common minimum set of metadata for describing semantic artefacts (see P-Rec. 3).
Enabling automated indexing across repositories will require agents to access a machine readable description of the API and the description of information that can be accessed. Therefore, repositories should consider publishing at least the description of their API using OpenAPI specifications which will provide first a human readable API documentation in a machine readable format. A recent extension of the OpenAPI specification, called smartAPI[26], has been proposed to provide semantically annotated API description to make API FAIR. Such semantically enriched description could enable automated workflows for indexing semantic repositories.
Several other possible solutions exist i.e. publishing directly the content as Linked Data and to be compliant with the LD standards (Linked Data Platform, …), use a common inter-exchange metadata format such as RIF-CS or publish metadata and content using the FAIR Data Point service.
This recommendation does not aim to support any particular solution but rather emphasize the need for the community of semantic repositories to agree on a common solution.
Existing recommendations:
● The FAIR Data point specification[27]
● Registry Interchange Format - Collections and Services (RIF-CS) (ISO 2146)[28].
● Linked Data Platform[29]
● OpenAPI[30]
● smartAPI[31]
Stakeholder: Repository
The short answer here is YES and NO We currently offer REST API publishing Linked Data (RDF) currently only in XML and a SPARQL endpoint. We do not have an API spec describing our APIs though
Content negotiation by profile (https://www.w3.org/TR/dx-prof-conneg/) provides a Linked Data compatible API for flexible and transparent access to resources - it can co-exist with other functional APIs
Part of the API heterogeneity has evolved over time as an extremely lengthy list of options and capabilities has been built into a rich collection of REST interfaces. I did not see in earlier versions of OpenAPI/SmartAPI the ability to describe such rich REST resources.
Nor for that matter do those tools have the ability to describe a SPARQL endpoint, which is the most standardized way to access the semantic content of repositories, if it is offered. Of course the underlying triples model is not so standard from one repo to the next…