Communicate version of DFC Standard in API response header

[RaggedStaff]

We will soon release v2.0.0 of the Ontology & accompanying Taxonomies. This will mean that some platforms are using incompatible versions of the standard.

To ensure this is clearly communicated, I propose we require all API responses from platforms to communicate the version of the ontology they are using within the header.

We could require a field dfc-version in the format "v0.0.0"

This is particularly relevant for the Portal backend being developed for FDC, as we anticipate this having to deal with platforms supporting both v1.9 & v2.x of the ontology/standard.

What do you think @datafoodconsortium/standard_maintainers @datafoodconsortium/tech_discussions ?

[lecoqlibre]

Indeed it's needed. I am favorable to add a custom HTTP header named dfc-version containing a string in the format x.y.z (I would prefer not to prefix it with a "v" because the header is already telling it's a version).

I would add that this header should only be used during the transition to WebIds. Indeed I plan to add this version information directly into platform WebIds. When we would have platform WebIds this header should not be used anymore. The reason is for Solid compatibility: the header would be useless and would force to deploy a Solid agent next to a generic Solid server and we want to avoid this.

The fact that this header is transitional should be clearly notified in the appropriate section of the DFC standard.

[RaggedStaff]

@RaggedStaff to write up a proposal in gitbook.

[lecoqlibre]

During the tech meeting call today @simonLouvet said that the ontology version could be found in the JSON-LD context.

On my side, to be more precise concerning the version number I plan to add in platform WebId, this number would target the version of the DFC client-to-client protocol (which could implicitly refer to an ontology version).

[RaggedStaff]

During the tech meeting call today @simonLouvet said that the ontology version could be found in the JSON-LD context.

This is true, although in my experience most platforms reference the latest version (via https://datafoodconsortium.org/ ), so I don't consider this reliable.

On my side, to be more precise concerning the version number I plan to add in platform WebId, this number would target the version of the DFC client-to-client protocol (which could implicitly refer to an ontology version).

Do you.mean implicitly? I would hope it was more explicit. 😕

[lecoqlibre]

During the tech meeting call today @simonLouvet said that the ontology version could be found in the JSON-LD context.

This is true, although in my experience most platforms reference the latest version (via https://datafoodconsortium.org/ ), so I don't consider this reliable.

+1

On my side, to be more precise concerning the version number I plan to add in platform WebId, this number would target the version of the DFC client-to-client protocol (which could implicitly refer to an ontology version).

Do you.mean implicitly? I would hope it was more explicit. 😕

I was thinking that the client-client protocol version would implicitly include a certain ontology version. A client-client protocol will be based on a certain ontology version. For instance a client-client protocol would contain some SHACL shapes that refer to some properties of the ontology. When the ontology is changed the client-client protocol has to be updated. So it would always (implicitly) target a certain ontology version.

But I think we will have a better understanding when we will release our first client-client protocol. Maybe we will need to explicitly expose the ontology version next to the client-client protocol version.

[lecoqlibre]

I added the ontology version in the WebID proposal. So an enterprise WebID has now two version information: one for the client-client protocol and one for the ontology.

For me the ontology version should be temporary as developers only need to worry about client-client protocol version rather than an ontology. An ontology is just a vocabulary, it does not include any business logic required by platforms. So when a first complete client-client protocol will be finished I think we can remove the ontology version notice.