Re: \ODRL February 2024 Meeting Notes

Throwing some more options into the mix:

  1.  We can get a w3id<https://w3id.org/> and have something like https://w3id.org/odrl-community (that would point to the option below)
  2.
We can add a new folder in the CG GitHub repo and use the GitHub pages generated URL, e.g. https://w3c.github.io/odrl/community-vocab

If the idea is working towards having an ODRL 3.0, I wouldn't introduce a w3id, I would just use the second option as a placeholder for the new terms until they are merged with the terms already in the ODRL 2.2 vocab for the new version.
If having a version 3.0 is out of the table I would go for option 1.
Regards,
Beatriz
________________________________
From: Arthit Suriyawongkul <arthit@gmail.com>
Sent: 05 February 2024 15:26
To: Renato Iannella <r@iannel.la>
Cc: public-odrl@w3.org Group <public-odrl@w3.org>
Subject: Re: \ODRL February 2024 Meeting Notes

Thank you. Happy to see you all.

On ODRL Community Vocabulary namespace (based on my comment in the Zoom chat):

For community vocabulary namespace idea, we may learn from namespaces of these projects:

- tf.experimental - Tensorflow uses "experimental" to "indicates that the said class/method is in early development, incomplete, or less commonly, not up-to-standards. It's a collection of user contributions which weren't yet integrated w/ main TensorFlow, but are still available as a part of open-source for users to test and give feedback." [1] (*not an official explanation)

- skimage.future - scikit-image uses "future" for something that might be included in the package in the future at some point. "Although you can count on the functions in this package being around in the future, the API may change with any version update and will not follow the skimage two-version deprecation path. Therefore, use the functions herein with care, and do not use them in production code that will depend on updated skimage versions." [2]

- clojure.contrib - Clojure uses "contrib" for open-source libraries hosted by but not owned by the Clojure project. Historically, these libs use "clojure.contrib" namespace but no longer. "They vary widely in development activity and quality and may or may not be the best alternative for their functionality in the overall ecosystem. You should evaluate them before use as you would any open source library you intend to use as a dependency." [3]

Basically, these separated namespaces are/were use to signal the use of the API that the API can be changed in an unplanned way or will not eventually graduate to the official API.

Build upon those examples, we could have some candidates like
- odrl.community or
- odrl-community or
- something shorter (if OBO namespace policy [4] is being considered)

[1] https://stackoverflow.com/questions/58333491/what-does-experimental-in-tensorflow-mean

[2] https://scikit-image.org/docs/stable/api/skimage.future.html

[3] https://clojure.org/dev/contrib_libs

[4] http://obofoundry.org/principles/fp-003-uris.html

Regards,
Art


--
The job of a citizen is to keep his mouth open.
-- Günter Grass