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

any additional mechanisms for format/serialization resolution? #55

Closed
carueda opened this Issue Oct 3, 2017 · 4 comments

Comments

Projects
None yet
2 participants
@carueda
Member

carueda commented Oct 3, 2017

The ORR supports two mechanisms to resolve ontology and term requests in a desired format or serialization: i) content negotiation as the main mechanism for programmatic access; and ii) via format parameter as a convenience mainly for users when entering the request in a browser.

The resolution of desired format via 'file-type extension' in previous major version 2 has not been implemented in v3. This entry is to expand a bit on the rationale for having postponed a similar "feature" in v3, and to get reactions toward determining whether there's an actual need for such file-type extension mechanism.

  • The format parameter makes very explicit the desired effect of the request. On the other hand, a request with file extension, although it might look explicit about the format, can actually be at least a bit confusing when there's actually an entry with such file extension as part of the original IRI, while at the same time the request is to resolve the contents in a serialization different from the original submission. For example, http://mmisw.org/ont/ANZRC/ANZRC_Codes.owl.n3. Contrast this with the use of the format parameter: eg., http://mmisw.org/ont/ANZRC/ANZRC_Codes.owl?format=n3.

  • As a non-functional aspect, when processing an IRI request that includes some file extension, but that does not exist in the system, the backend would have to perform extra logic for possibly finding the requested IRI without that file extension. Perhaps not a very expensive operation but with an impact on performance anyway.

@carueda carueda changed the title from format resolution via file extension mechanism to any additional mechanisms for format/serialization resolution? Oct 4, 2017

@dr-shorthair

This comment has been minimized.

Show comment
Hide comment
@dr-shorthair

dr-shorthair Oct 11, 2017

Suggest also supporting _format which is the key built-in to the Linked Data API
see https://github.com/UKGovLD/linked-data-api/blob/wiki/API_Query_Parameters.md

dr-shorthair commented Oct 11, 2017

Suggest also supporting _format which is the key built-in to the Linked Data API
see https://github.com/UKGovLD/linked-data-api/blob/wiki/API_Query_Parameters.md

carueda added a commit that referenced this issue Oct 12, 2017

@carueda carueda closed this in 1c51633 Oct 12, 2017

carueda added a commit that referenced this issue Oct 12, 2017

Merge pull request #56 from mmisw/55_file_ext
resolve #55 - file-type extension resolution
@carueda

This comment has been minimized.

Show comment
Hide comment
@carueda

carueda Oct 12, 2017

Member

I have implemented this "file-type extension" resolution.
Also, included check for _format parameter in case format is not given.

All of this available as of v.3.6.7 of the system.

Member

carueda commented Oct 12, 2017

I have implemented this "file-type extension" resolution.
Also, included check for _format parameter in case format is not given.

All of this available as of v.3.6.7 of the system.

@carueda

This comment has been minimized.

Show comment
Hide comment
@carueda

carueda Oct 12, 2017

Member

COR instance just upgraded to v3.6.7.
See ESIPFed/sweet#51

Member

carueda commented Oct 12, 2017

COR instance just upgraded to v3.6.7.
See ESIPFed/sweet#51

@carueda

This comment has been minimized.

Show comment
Hide comment
@carueda

carueda Oct 12, 2017

Member

The recognized formats via file extension (or format or _format parameter) are:

  • For ontology requests:

    File ext Mime type
    rdf application/rdf+xml
    owl application/rdf+xml
    owx application/owl+xml
    jsonld application/json+ld
    n3 text/n3
    ttl text/turtle
    nt text/plain
    nq application/n-quads
    trig application/trig
    rj application/rdf+json
  • For term requests:
    (Note, possible formats are as supported by AllegroGraph)

    File ext Mime type
    rdf application/rdf+xml
    owl application/rdf+xml
    xml application/rdf+xml
    nquads text/x-nquads
    trix application/trix
    ttl text/turtle
    n3 text/rdf+n3
    quints application/x-quints+json
    integer text/integer
    json application/json
    csv application/processed-csv
    tab text/tab-separated-values
    tsv text/tab-separated-values

Note:

  • Ontology requests are directly resolved against the backend database with format translation performed via Apache Jena. (BTW resulting formats are computed only once, then cached).

  • Term requests are resolved via SPARQL queries against the triple store. The possible formats are as supported by AllegroGraph.

Member

carueda commented Oct 12, 2017

The recognized formats via file extension (or format or _format parameter) are:

  • For ontology requests:

    File ext Mime type
    rdf application/rdf+xml
    owl application/rdf+xml
    owx application/owl+xml
    jsonld application/json+ld
    n3 text/n3
    ttl text/turtle
    nt text/plain
    nq application/n-quads
    trig application/trig
    rj application/rdf+json
  • For term requests:
    (Note, possible formats are as supported by AllegroGraph)

    File ext Mime type
    rdf application/rdf+xml
    owl application/rdf+xml
    xml application/rdf+xml
    nquads text/x-nquads
    trix application/trix
    ttl text/turtle
    n3 text/rdf+n3
    quints application/x-quints+json
    integer text/integer
    json application/json
    csv application/processed-csv
    tab text/tab-separated-values
    tsv text/tab-separated-values

Note:

  • Ontology requests are directly resolved against the backend database with format translation performed via Apache Jena. (BTW resulting formats are computed only once, then cached).

  • Term requests are resolved via SPARQL queries against the triple store. The possible formats are as supported by AllegroGraph.

carueda added a commit that referenced this issue Oct 12, 2017

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