New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lobid API 2.0 #1

Closed
acka47 opened this Issue May 20, 2014 · 13 comments

Comments

Projects
None yet
4 participants
@acka47
Contributor

acka47 commented May 20, 2014

In the past weeks we have discussed some additions to the lobid API that would result in incompatibilities with the existing API version 1.x.x and thus would mean a change to version 2.0.0.

This is the main issue to discuss the changes included in this version upgrade. Tickets for individual work packages will be linked to this issue.

@acka47

This comment has been minimized.

Show comment
Hide comment
@acka47

acka47 May 20, 2014

Contributor

Provide nested JSON-LD instead of flat @graph structure, see lodmill-449.

Contributor

acka47 commented May 20, 2014

Provide nested JSON-LD instead of flat @graph structure, see lodmill-449.

@acka47

This comment has been minimized.

Show comment
Hide comment
@acka47

acka47 May 20, 2014

Contributor

Add query as seperate JSON object with information on issued when, number of results etc., see comment lobid/lodmill#297 (comment) and following.

Contributor

acka47 commented May 20, 2014

Add query as seperate JSON object with information on issued when, number of results etc., see comment lobid/lodmill#297 (comment) and following.

@fsteeg

This comment has been minimized.

Show comment
Hide comment
@fsteeg

fsteeg May 23, 2014

Contributor

From our experience with the current API so far having different routes for different kinds of data (/person, /subject, etc.) is rather confusing. Instead, we could implement a single route (e.g. /data) and filter everything using the type query parameter.

This new route could simply be added without changing the existing routes, which we would deprecate.

Note: this does not affect our own URIs (/resource/ID, organisation/ID), which we would retain.

Contributor

fsteeg commented May 23, 2014

From our experience with the current API so far having different routes for different kinds of data (/person, /subject, etc.) is rather confusing. Instead, we could implement a single route (e.g. /data) and filter everything using the type query parameter.

This new route could simply be added without changing the existing routes, which we would deprecate.

Note: this does not affect our own URIs (/resource/ID, organisation/ID), which we would retain.

@fsteeg

This comment has been minimized.

Show comment
Hide comment
@fsteeg

fsteeg May 23, 2014

Contributor

Having different query parameters for different field sets (id=, name=, q=) introduces much complexity on the implementation level. For a 2.0 API I'd prefer a single q= parameter for all queries, with an optional (default would be all fields, as with current q=), additional parameter (e.g. q=Essen&domain=name).

Contributor

fsteeg commented May 23, 2014

Having different query parameters for different field sets (id=, name=, q=) introduces much complexity on the implementation level. For a 2.0 API I'd prefer a single q= parameter for all queries, with an optional (default would be all fields, as with current q=), additional parameter (e.g. q=Essen&domain=name).

@fsteeg

This comment has been minimized.

Show comment
Hide comment
@fsteeg

fsteeg Jul 22, 2014

Contributor

For details on the desired JSON-LD structure see:

http://manu.sporny.org/2014/json-ld-origins-2/#comment-4189

And especially lobid/lodmill#433 where the approach for lobid to get nested JSON-LD is described in detail.

Contributor

fsteeg commented Jul 22, 2014

For details on the desired JSON-LD structure see:

http://manu.sporny.org/2014/json-ld-origins-2/#comment-4189

And especially lobid/lodmill#433 where the approach for lobid to get nested JSON-LD is described in detail.

@fsteeg

This comment has been minimized.

Show comment
Hide comment
@fsteeg

fsteeg Jul 22, 2014

Contributor

To be able to seize what Elasticsearch provides out of the box in its query string syntax (see 1), we should index our data with compact keys. There is currently no way to generate a JSON-LD representation with compact keys and regular values (required for Elasticsearch) however (see 2).

Contributor

fsteeg commented Jul 22, 2014

To be able to seize what Elasticsearch provides out of the box in its query string syntax (see 1), we should index our data with compact keys. There is currently no way to generate a JSON-LD representation with compact keys and regular values (required for Elasticsearch) however (see 2).

@fsteeg

This comment has been minimized.

Show comment
Hide comment
@fsteeg

fsteeg Jul 22, 2014

Contributor

Since we want a custom JSON-LD format in different ways (see previous two comments), I think we should manually create the JSON-LD representation and generate other representations from that, instead of manually creating a different representation and generating the (insufficient) JSON-LD representation from it (as we currently do).

Contributor

fsteeg commented Jul 22, 2014

Since we want a custom JSON-LD format in different ways (see previous two comments), I think we should manually create the JSON-LD representation and generate other representations from that, instead of manually creating a different representation and generating the (insufficient) JSON-LD representation from it (as we currently do).

@acka47

This comment has been minimized.

Show comment
Hide comment
@acka47

acka47 Sep 1, 2014

Contributor

We should take API 2.0 as an opportunity to also differentiate more betwen the linked data part where locally created data with links to other services (GND, GeoNames etc.) is provided and the API where the local data enriched with data from the linked this-party sources is offered. This might be achieved by pre-filtering the linked data served from /resource and /organisation URIs with a JSON-LD frame.

Contributor

acka47 commented Sep 1, 2014

We should take API 2.0 as an opportunity to also differentiate more betwen the linked data part where locally created data with links to other services (GND, GeoNames etc.) is provided and the API where the local data enriched with data from the linked this-party sources is offered. This might be achieved by pre-filtering the linked data served from /resource and /organisation URIs with a JSON-LD frame.

@acka47

This comment has been minimized.

Show comment
Hide comment
@acka47

acka47 Nov 21, 2014

Contributor
Contributor

acka47 commented Nov 21, 2014

@acka47

This comment has been minimized.

Show comment
Hide comment
@acka47

acka47 Mar 12, 2015

Contributor

We should consider switching to https with API 2.0.

Contributor

acka47 commented Mar 12, 2015

We should consider switching to https with API 2.0.

@jschnasse

This comment has been minimized.

Show comment
Hide comment
@jschnasse

jschnasse Sep 28, 2015

For Api 2.0 , I´d suggest another trick. It would be nice to always get a prefLabel as a side car to all occurrences of @id (in document AND in context) . The usage of prefLabel would give clients a simple, unified and intuitive way to access the index and to mock views on lobid data. It can also be useful for configuring the index (e.g. boosting prefLabel).
Some examples:

  • in case of gnd-ids the preferredName should be provided as prefLabel, same for gnd-subjects
  • for skos vocabs, a prefLabel comes together with the uris
  • for the @ids in the context you can use tools like etikett

jschnasse commented Sep 28, 2015

For Api 2.0 , I´d suggest another trick. It would be nice to always get a prefLabel as a side car to all occurrences of @id (in document AND in context) . The usage of prefLabel would give clients a simple, unified and intuitive way to access the index and to mock views on lobid data. It can also be useful for configuring the index (e.g. boosting prefLabel).
Some examples:

  • in case of gnd-ids the preferredName should be provided as prefLabel, same for gnd-subjects
  • for skos vocabs, a prefLabel comes together with the uris
  • for the @ids in the context you can use tools like etikett
@acka47

This comment has been minimized.

Show comment
Hide comment
@acka47

acka47 Oct 20, 2015

Contributor

It would be great to support Triple Fragment Patterns with API 2.0. This would enable people to run SPARQL queries against lobid. There already exists a Triple Pattern Fragments server for Java.

Contributor

acka47 commented Oct 20, 2015

It would be great to support Triple Fragment Patterns with API 2.0. This would enable people to run SPARQL queries against lobid. There already exists a Triple Pattern Fragments server for Java.

@acka47

This comment has been minimized.

Show comment
Hide comment
@acka47

acka47 Jul 12, 2017

Contributor

As API 2.0 has been officially launched, I am closing this issue.

Contributor

acka47 commented Jul 12, 2017

As API 2.0 has been officially launched, I am closing this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment