Repo structure and publishing

[tpluscode]

The Hydra Core vocabulary has the namespace http://www.w3.org/ns/hydra/core#

I would propose to have analogous structure for each extensions, so that the core segments is replaced with a specific name:

Extension	Namespace
SHACL (#2)	http://www.w3.org/ns/hydra/shacl#
Profiles (#3)	http://www.w3.org/ns/hydra/profile#
Collections (#4)	http://www.w3.org/ns/hydra/collection#
Non-RDF Payloads (#5)	http://www.w3.org/ns/hydra/payloads#
OWL (#6)	http://www.w3.org/ns/hydra/owl#

The repository would thus follow this analogous structure, with each extension at least having a readme (until we decide to adopt respec/bikeshed/other for publishing) and a turtle with actual vocabulary

extensions/
├── collection/
│   ├── index.ttl
│   └── readme.md
├── owl/
│   ├── index.ttl
│   └── readme.md
├── payloads/
│   ├── index.ttl
│   └── readme.md
├── profile/
│   ├── index.ttl
│   └── readme.md
└── shacl/
    ├── index.ttl
    └── readme.md

@lanthaler would it be possible to set up publishing the URLs above from this repo, so that we get content negotiation of the RDF. How is that done for the core?

[tpluscode]

Hey @lanthaler. Have you had a chance to look at the above?

[lanthaler]

I can set it up but would advice against it and instead just create a single namespace for extensions. It quickly becomes very hard to remember which term is in which namespace and would be overly confusing if the same term is used in different namespaces with different meanings... yes, I do regret having created a separate core namespace ;-)

[tpluscode]

I am also looking at w3id.org which may be better suited so that we don't have to rely on w3.org setup which is out of our control.

About you suggestion to have a single NS, that would in fact be similar to how DASH (datashapes.org) which is spread over multiple specs but all of the vocabulary is a single RDF document

https://w3id.org/hydra-ex# perhaps for the vocab? And https://w3id.org/hydra-ex/shacl for the documents

@alien-mcl @pietercolpaert

[pietercolpaert]

I’m ok with that!

[alien-mcl]

I think w3id is OK for extensions

[alien-mcl]

As for the Url, I'd like to have it readable in the url, i.e. https://w3id.org/hydra/extension/in-owl or https://w3id.org/hydra/extension/in-shacl or https://w3id.org/hydra/extension/shacl (making it readable as hydra extension in owl, hydra extension in shacl or hydra extension shacl).

Alternatively with hash notation, i.e. https://w3id.org/hydra#in-owl

[tpluscode]

Ok, I think we're getting somewhere.

To wrap up, I propose as follows:

1. https://w3id.org/hydra/extension/shacl as a canonical link (redirect) to the SHACL extension spec
2. https://w3id.org/hydra/extension negotiated redirect to either
   • an RDF combining any terms extending Hydra Core
   • a Landing Page (Landing page  #18) from HTML requests
3. Have additional entries for other, independent RDF documents, such as possibly /hydra/in-owl or /hydra/is-shacl which may not make sense to combine with the "Extension Vocabulary" itself.

I noticed that https://w3id.org/hydra/ is already a thing. @lanthaler would you like to keep it redirecting to your page or maybe rewire it to redirect to the core spec?