Allow to fetch taxonomies using content negotiation

[lecoqlibre]

Currently our taxonomies like productTypes are both published in a .rdf and a .json format. But the two files are referencing the .rdf URI which is bad because when using the .json file we are forced to use in addition an XML parser as no content negotiation is possible.

Instead the .rdf URI should accept content negotiation so a client can ask to obtain a particular representation of the data, let's say in JSONLD:

GET /datafoodconsortium/taxonomies/releases/latest/download/productTypes.rdf HTTP/1.1
Host: github.com
Accept: application/ld+json

Note: we could also remove the .rdf extension at the end of the URI.

That means we should set up a server or maybe it can work with GitHub pages. Also we need to check the W3 permanent redirections.

@datafoodconsortium/standard_maintainers

[lecoqlibre]

@simonLouvet was talking about content negotiation in the W3 issue #18 (comment). Do we have something working?

[simonLouvet]

I'm not sure I understood

I prepared this documentation which provides all the urls following the implementation of jsdeliver and w3id. I don't understand why w3id urls aren't used.
https://pad.lescommuns.org/4kDq3-KbQWeH2VeVRAVgAQ

The case mentioned is not available on https://w3id.org/dfc/taxonomies/productTypes.json

this file actually refers to https://github.com/datafoodconsortium/taxonomies/releases/latest/download/productTypes.rdf when it should refer to https://w3id.org/dfc/taxonomies/productTypes.json

We have chosen to manage ontology, taxonomy and context using git repo, github release and jsdeliver and w3id gateway (see documentation above) which do not allow content negotiation.

I think that this choice is still relevant for questions of performance and maintenance. The effort should rather be made on the file generation process rather than the type negotiation server.

Translated with DeepL.com (free version)

[lecoqlibre]

this file actually refers to https://github.com/datafoodconsortium/taxonomies/releases/latest/download/productTypes.rdf when it should refer to https://w3id.org/dfc/taxonomies/productTypes.json.

I think we have an issue here because one actor could refer to the JSON tomato https://github.com/datafoodconsortium/taxonomies/releases/latest/download/productTypes.json#tomato while an other actor could refer to the XML+RDF tomato https://github.com/datafoodconsortium/taxonomies/releases/latest/download/productTypes.rdf#tomato. In the context of the web these tomatoes are different since their URI is different (.rdf vs .json).

Instead, in all serializations, the URI of the tomato should be the same and could be either https://github.com/datafoodconsortium/taxonomies/releases/latest/download/productTypes.rdf (.rdf does not target a serialization but refer to the RDF model) or just https://github.com/datafoodconsortium/taxonomies/releases/latest/download/productTypes (without any extension).

It seems we are forced to set up content negotiation.

Resources are not the same thing as their representations. For more details, see the Representations section from the HTTP protocol.

Any thoughts @RaggedStaff?

The effort should rather be made on the file generation process rather than the type negotiation server.

It seems that even if we wanted to have different URIs we won't be able to do it with VocBench as it does not allow to have a different URI per serialization:

And also in the export windows we can only export named graph(s):

[RaggedStaff]

this file actually refers to https://github.com/datafoodconsortium/taxonomies/releases/latest/download/productTypes.rdf when it should refer to https://w3id.org/dfc/taxonomies/productTypes.json.

I think the reason for that may be the issue you've noted next.

Any thoughts @RaggedStaff?

I agree we have an issue (*.rdf#tomato cannot have a different URI to *.json#tomato).

I think we can solve it with .htaccess rewrite rules in the w3id.org redirections.

I would favour doing that without an extension on the URI (that is .../productType#tomato) and the encoding is specified in the request header.

Do we have funding for this work?

[RaggedStaff]

I have made changes to the .htaccess file used by dfc as part of the w3id.org project in my fork.

I will submit a PR to get it merged asap.

The issue was raised that once this is live (v2.0.0) we will need an Apache testing environment to test/verify changes to the redirect file (or perhaps a CI GH action to do so 🤔 - ping @imbrou )