Re: \ODRL February 2024 Meeting Notes

We currently use a lot of SKOS Collections:  https://www.w3.org/ns/odrl/2/ODRL22.ttl

I think the “Community Vocab” should be seen as a supplement to the “Common Vocab”: https://www.w3.org/TR/odrl-vocab/#vocab-common
(this will also allow the wider community to feel more part of the ODRL experience)

R


> On 6 Feb 2024, at 19:22, Penny Labropoulou <penny@athenarc.gr> wrote:
> 
> The idea of having a separate SKOS collection such as "community vocabulary" makes sense, yet it means these terms will always be treated as a separate collection. Is this what we want? If at any time they are to become officially part of the core vocabulary, I would hesitate using this option. 
> 
> If they are to be treated as "candidate" terms, why not simply a v2.x version treated as "work in progress"? In this case, the ODRL page should always show to the official version, while v2.x would be the draft one, until it is officially adopted. We could also have these terms discussed as github issues, so that we keep track also of cases that we discussed but rejected at some point.
> 
> Best,
> Penny
> 
> 
> From: Renato Iannella <r@iannel.la <mailto:r@iannel.la>>
> Sent: Tuesday, February 6, 2024 11:08
> To: public-odrl@w3.org <mailto:public-odrl@w3.org> Group <public-odrl@w3.org <mailto:public-odrl@w3.org>>
> Subject: Re: \ODRL February 2024 Meeting Notes
>  
> You don't often get email from r@iannel.la <mailto:r@iannel.la>. Learn why this is important <https://aka.ms/LearnAboutSenderIdentification> 
> I think that ODRL V3 is still on our Roadmap…
> 
> The default (option 0) is to use the current namespace <http://www.w3.org/ns/odrl/2/>
> 
> We can add them to the current ttl as a new SKOS Collection, such as:
> 
> <http://www.w3.org/ns/odrl/2/#communityVocabualry>
>     a skos:Collection ;
>     skos:prefLabel “Community Vocabulary Terms"@en ;
>     skos:scopeNote “Community curated terms for ODRL Policies"@en ;
>     skos:member odrl:create ;
>     ….
> 
> Keep the ideas flowing...
> 
> Keep the ideas flowing…
> 
> R
> 
> 
> 
> On 6 Feb 2024, at 17:00, Beatriz Gonçalves Crisóstomo Esteves (UGent-imec) <Beatriz.Esteves@UGent.be> wrote:
> 
> Throwing some more options into the mix:
> We can get a w3id <https://w3id.org/> and have something like https://w3id.org/odrl-community (that would point to the option below)
> 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 <mailto:arthit@gmail.com>>
> Sent: 05 February 2024 15:26
> To: Renato Iannella <r@iannel.la <mailto:r@iannel.la>>
> Cc: public-odrl@w3.org <mailto:public-odrl@w3.org> Group <public-odrl@w3.org <mailto: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