Closed mattgarrish closed 4 years ago
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 https://github.com/w3c/pub-manifest/pull/228 and https://github.com/w3c/audiobooks/pull/85...
At the moment, we use the following URL-s in our specs (including the current proposal):
https://www.w3.org/ns/pub-context
https://www.w3.org/ns/pub-context.jsonld
https://www.w3.org/ns/pub
https://www.w3.org/ns/pub#LinkedResource
to identify the manifest specific LinkedResource classhttps://www.w3.org/ns/pub-manifest/schema/
https://w3c.github.io/pub-manifest/schema/*
https://www.w3.org/ns/audiobooks/schema/
https://w3c.github.io/audiobooks/schema/*
(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:
https://www.w3.org/ns/pub-context
https://www.w3.org/ns/pub-vocab/manifest
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-vocab/manifest#alternate
curl --header "Accept: text/turtle, application/ld+json, application/rdf+xml" https://www.w3.org/ns/pub-vocab/manifest
returns the TTL filemanifest
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).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
We've been using relative paths in the schemas to date as it made local development a little easier, but due to recent differences in how some validators work, we need to switch back to absolute URLs now that we're winding down the work. The problem is we never resolved on formal URLs for these.
For now, I've used the github pages address for the schemas: https://w3c.github.io/pub-manifest/schema/
While this seems to work fine, we should figure out if we want to put a W3C redirect on top of it, something like: https://www.w3.org/ns/pub-manifest/schema/*
Aside from not having github in the formal URL, it also gives us flexibility should we need to change locations in the future. (We'll also need a similar URL for the audiobooks schema, too.)
@iherman @marisademeglio and I have been discussing this privately while trying to iron out the validation problems the relative URLs caused, but what actual solution to use needs group approval.