Just for the records I am in favour of using W3C URLs for these.

I am o.k. with the proposed changes in principle, but I do have a problem with the incarnation in #228 and w3c/audiobooks#85...

At the moment, we use the following URL-s in our specs (including the current proposal):

1. Publication context: https://www.w3.org/ns/pub-context
   • The URL redirects to https://www.w3.org/ns/pub-context.jsonld
   • The content is maintained in a separate github repo
2. Publication vocabulary: https://www.w3.org/ns/pub
   • There is a content negotiation to serve this url in html, json, rdf/xml, and turtle
   • The content is maintained in a separate github repo
   • Is used for the manifest specific vocabulary items in the context file, e.g., https://www.w3.org/ns/pub#LinkedResource to identify the manifest specific LinkedResource class
3. Publication manifest schemas directory: https://www.w3.org/ns/pub-manifest/schema/
   • The URL-s redirect to https://w3c.github.io/pub-manifest/schema/*
   • Contains an index file and a number of json schema files
4. Publication manifest schemas directory: https://www.w3.org/ns/audiobooks/schema/
   • The URL-s redirect to https://w3c.github.io/audiobooks/schema/*
   • Contains an index file and a number of json schema files

(I hope I do not forget anything.)

There does not seem to be any consistency in our URL schemes, and that bothers me. Looking at the list, I would consider the first entry above cast in concrete: all our examples, and indeed current implementations, rely on that URL. We should not change that. Changing (2) requires a change in the context file; taking into account that I do not think any of the current implementations are JSON-LD based, I do not think that changing that URL would invalidate any of them. Put it another way we can change that if we want. Finally, (3)/(4) are still open.

One alternative may be something like:

• Context file: https://www.w3.org/ns/pub-context
• Vocabulary: https://www.w3.org/ns/pub-vocab/manifest
• Schema: https://www.w3.org/ns/pub-schema/manifest/* and https://www.w3.org/ns/pub-schema/audiobooks/*

This seems to be o.k. for future profiles: if new vocabulary entries are added in a separate vocabulary, it can be https://www.w3.org/ns/pub-vocab/foo and, similarly, new schema files can be added as https://www.w3.org/ns/pub-schema/foo/*

I am not saying this should be the final option, I am just saying we should find something more future proof and consistent...

Ya, I guess that works. Would have been a bit nicer if the stem could have been https://www.w3.org/ns/pub/ but I guess in the interest of not changing the context at this stage /pub-*/ will do.

I think I am done, but better check on your side before updating the PR-s. Just to be on the safe side.

• https://www.w3.org/ns/pub-context leads to the context file with the pub vocabulary entries using the new URL for the vocabulary, e.g., https://www.w3.org/ns/pub-vocab/manifest#alternate
• https://www.w3.org/ns/pub-vocab/manifest goes, by default, to the HTML file of the vocabulary, and the relevant files (e.g., https://www.w3.org/ns/pub-vocab/manifest.ttl) gets to the right format.
• content negotiations works; calling, e.g., curl --header "Accept: text/turtle, application/ld+json, application/rdf+xml" https://www.w3.org/ns/pub-vocab/manifest returns the TTL file
• https://www.w3.org/ns/pub-schema/manifest/publication.schema.json returns the relevant file on the repository, so does, e.g., https://www.w3.org/ns/pub-schema/manifest/module/url.schema.json as well. Technically, a redirection is set up both in the manifest and the manifest/module directories that redirects any *.schema.json URL to its github.io equivalent (ie, if new modules are added, they should automatically work).
• The same structure has been set up for the audiobooks schemas (although, at present, there is no separate module subdirectory for audiobooks, we may want to add it later, better be prepared).

Anything I forgot?

SGTM. I'm not seeing anything in the four cases above not covered.

Pfew :-)

Will you take care of the updates for #228 and w3c/audiobooks#85?

Sure