any additional mechanisms for format/serialization resolution?

[carueda]

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.

[dr-shorthair]

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]

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]

COR instance just upgraded to v3.6.7. See https://github.com/ESIPFed/sweet/issues/51

[carueda]

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.