Utilise w3id.org http redirects for permanent DFC URI's

[RaggedStaff]

w3id.org offer a permanent redirect service to support linked data projects to stablise URI's.

We are proposing to utilise this to add CORS headers & redirection (currently to github release page, could be updated in the future)

[RaggedStaff]

I have a draft of this ready to go in my fork.

But I need to know where to point the redirects.

Can we agree if we are using github pages to publish to docs.datafoodconsortium.org or continuing to use the github releases functionality ?

[RachL]

ping @simonLouvet @lecoqlibre

[simonLouvet]

I don't think we need a variable (.*)$ to point to the latest.
It might be used if you want to get a version, but in that case I would have used these URLs

dfc/ontology/(.*)/context
dfc/ontology/(.*)
dfc/taxonomy/(.*)

[RachL]

@RaggedStaff NOT github pages

[RaggedStaff]

Update on this. I've updated to handle versioned file redirects & tested using a remote Apache deployment.

The CORS headers are not working... I think GitHub may have it's own headers set to force downloading. 😖

I think we need to revisit using GitHub pages to publish the files & w3id for permanent redirection.

[simonLouvet]

I'm thinking of developing a mini-server dedicated to publishing ontologies (owl, rdf), contexts and taxonomies based on github releases. Doing what we wanted to do with w3id.org, but ourselves.

We could add content negotiation (having a taxonomy in json-ld or xml for example)

depending on the degree of genericity and functionality (being able to configure the github / gitlab repo by interface; having connection and rights management, being able to reference several repos, etc. ), it could take me between 2 and 8 days. To be funded by DFC or another organisation. I think that the virtual assembly also needs this type of tool.

Translated with DeepL.com (free version)

[RachL]

We are proposing again the following strategy:

• 1 branch per version number
• through github pages

It's not as clear as releases and it has the downside of creating many branches / which can look messy. An Archiving strategy might be needed.

Action for @RaggedStaff : check with Maxime if there were any other downside, otherwise both Simon and Garethe agree they can live with this solution.

[simonLouvet]

other solution : https://cdn.jsdelivr.net/gh/datafoodconsortium/ontology@v1.13.0/context.json

[RaggedStaff]

Update: @simonLouvet has pointed out JSDelivr.net supports github release redirection, with CORS headers! 🎉

I've rewritten the redirects & will test today/tomorrow. 🤞

[simonLouvet]

@RaggedStaff why no use directly jsDeliver?

[RaggedStaff]

@RaggedStaff why no use directly jsDeliver?

@simonLouvet because when jsDelivr gets decomissioned, or functionality changes (on jsDeliver or GitHub) so we have to change the URI paths, or we decide to do something different 😉, (hopefully) w3id.org will still be around & we will be able to prevent any breaking changes to the ontology. 🤞

[simonLouvet]

in progress

• https://w3id.org/dfc/ontology/v1.13.0/context.json
• https://w3id.org/dfc/ontology/v1.13.0/src/DFC_BusinessOntology.rdf
• https://w3id.org/dfc/taxonomies/v1.2.0/measures.rdf

[simonLouvet]

jsdeliver use tag and not releases

[simonLouvet]

@garethe says in slack:
Options I can see are :

• Leave as is, specific src/ in the path for ontology files
• Move ontology files form src/ to root
• Create additional redirect rules to map ontology files from src/ to root