-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
w3.org/ns/ development and management policy #2
Comments
(adding @pchampin @dontcallmedom in this thread) We haven't looked at ns policy lately. I would expect something as follows for new namespaces under w3.org/ns:
For the first case, we have enough of a process in place already to check things. For the second case, it will depend on the namespace being requested, the rules governing that namespace (such as being documented in the W3C technical report), and the rational for W3C to host that namespace. The Team verification is meant to avoid having /ns polluted or mis-represented since we don't verify nor endorse the work of the W3C Community Groups. The tricky case is always that it's hard to change the namespace once implementations are deployed. The intention is that this Github repository will become the place to update w3.org/ns but it's waiting on the systeam folks to be available to set the complex set of redirects we currently have in place. My hope is that we can do the switch in 2024. |
(adding @ianbjacobs and @iherman who were involved in a recent related discussion for a CG) for reference, I believe the current policy under which |
That is correct, but I believe there were several cases in the past when /ns URI-s were set up for CG-s as well. The policy outlined by @plehegar in #2 (comment) sounds like describing current practices, and sounds good to me. |
What is the current policy to create and update namespaces?
Some thoughts:
The closest document that I'm aware of describing a policy on updating namespaces under w3.org/ns/ is the drafted: https://www.w3.org/2016/08/namespaces/ . This policy was discussed at TPAC 2016: https://www.w3.org/wiki/TPAC2016/SessionIdeas#Vocabulary_development_.26_management_at_W3C , which was partly based on https://www.w3.org/TR/ldn/ spec's need (at the time) to add
http://www.w3.org/ns/ldp#inbox
under the LDP ns (because it wasn't clear what we had to do to make it happen). Participants of the session loosely agreed given that our case was adding a term and not doing a more complicated change. W3C Team member (sandhawke) helped us to tick the boxes so that we can get this property added without stepping on anyone's toes.The Solid CG Contributing Guidelines refers to https://www.w3.org/2016/08/namespaces/ as a way to orient the community on how new namespaces can be created - although as I understand it now the process for CG/BGs is simple.. just ask [citation needed] - and how adding or updating names on existing namespaces can be achieved.
The Solid CG also uses https://github.com/solid/vocab to manage vocabularies that are both about Solid as well as those that are being used in the Solid ecosystem with the exception that they were not published alongside some W3C TR. In other words, if it wasn't already under the purview of a Group or referenced by a TR, this was a place to work on them. I've created that repository back in 2015 because prior to it, folks were nudging W3C Team members in private to get stuff up on w3.org/ns. We (anyone) needed to have an open/transparent way to work on stuff, and also get them published on W3C - something we did with the help of W3C Team member (e.g., TimBL).
There may be other cases that escapes me now but I can update this comment. I would just like to get a better understanding on how this repository will be used going forward, and whether there is any intention that it will act as the source of all material published under w3c/ns.
The text was updated successfully, but these errors were encountered: