- From: David Booth <david@dbooth.org>
- Date: Thu, 3 Sep 2020 10:13:08 -0400
- To: semantic-web@w3.org
- Cc: "Abhyankar, Swapna" <sabhyank@regenstrief.org>
FYI, Swapna Abhyankar from Regenstrief (copied) is working on updating the UCUM license, and reached out to me to understand the concerns that have been raised on this list. I suggested that he join this discussion, to directly understand all concerns. David Booth On 9/3/20 5:43 AM, Antoine Zimmermann wrote: > Indeed, Dave. The datatype discussed in this thread is the one > colloquially identified as cdt:ucum, which stands for: > > http://w3id.org/lindt/custom_datatypes#ucum > > This URI dereferences to a documentation which is currently in > disagreement with the Copyright Notice and License of UCUM since it does > not include the said notice. > > The documentation is a draft, subject to evolve, and is not currently > officially endorsed by any organisation, although we know people other > than us who are using it in their projects. > > The URI contains the term "custom_datatype" because it is one of several > custom datatypes that we are defining for various purposes. It was not > initially planned to separate cdt:ucum from our other custom datatypes, > but if their is a community willing to push this work towards > standardisation, we should give a second thought to the namespace of the > URI. > > We should also, obviously, update the documentation to make the > Copyright Notice appear explicitly. > > However, I doubt that the copyright notice can legally enforce anyone to > include the notice if they are merely using the codes in data about > measurements or physical quantities. So, as far as I'm concerned, I will > continue to use these codes and the cdt:ucum datatype whenever relevant > in my projects or publications, as well as encourage others to do so. > > > --AZ > > > > Le 03/09/2020 � 10:14, Dave Reynolds a �crit�: >> On 03/09/2020 09:04, Cox, Simon (L&W, Clayton) wrote: >>> >>> � * That just allows exchange of any /measurements/ >>> >>> This is the RDF application that we were discussing in this thread, I >>> think � where the UCUM code only appears in the context of a >>> measurement instance (i.e. a quantity) either embedded in the literal >>> else appearing in a data-type. >>> >> >> If appearing as a data-type that would be a URI surely? And, if a URI, >> given this is on the semantic-web list, wouldn't that URI resolve to >> something? That something would be explicitly or implicitly >> communicating partial information from UCUM. It's whoever puts up >> those data type URIs that needs to find a way through the "prickly" >> license. >> >> Dave >> >>> I can see your point that QUDT may be violating the strict >>> interpretation, so will attempt to clear that up separately. But I >>> still content that the use-case canvassed in this thread is OK. >>> >>> *From:*Dave Reynolds <dave.reynolds@epimorphics.com> >>> *Sent:* Thursday, 3 September, 2020 17:49 >>> *To:* semantic-web@w3.org >>> *Subject:* Re: Blank nodes must DIE! [ was Re: Blank nodes semantics >>> - existential variables?] >>> >>> On 03/09/2020 03:43, Cox, Simon (L&W, Clayton) wrote: >>> >>> ��� Dan Brickley wrote (a while back): >>> >>> ��� �On Thu, 23 Jul 2020 at 19:50, Patrick J Hayes <phayes@ihmc.us >>> >>> <mailto:phayes@ihmc.us?Subject=Re%3A%20Blank%20nodes%20must%20DIE!%20%5B%20was%20Re%3A%20Blank%20nodes%20semantics%20-%20%20existential%20variables%3F%5D&In-Reply-To=%3CCAFfrAFqgq7JxxwzEhYoMV70haRznXkjLBiOwhQUjwGJ0S0vsug%40mail.gmail.com%3E&References=%3CCAFfrAFqgq7JxxwzEhYoMV70haRznXkjLBiOwhQUjwGJ0S0vsug%40mail.gmail.com%3E>> >>> >>> ��� wrote: >>> >>> ��� � >>> >>> ��� �> Excellent. I have thought for some time that this way of using >>> ��� datatyping >>> >>> ��� �> would be the right way to go. Congratulations on having >>> ��� actually done it :-) >>> >>> ��� �> >>> >>> ��� � >>> >>> ��� �This is really interesting. Every couple of years I stumble >>> ��� across UCUM ( >>> >>> ��� �http://unitsofmeasure.org/trac -> >>> >>> ��� �http://unitsofmeasure.org/trac/wiki/TermsOfUse) before being >>> ��� scared away by >>> >>> ��� �the prickly terms of use document. It is not a document that >>> seems to >>> >>> ��� �welcome re-use. >>> >>> ��� � >>> >>> ��� �Dan >>> >>> ��� I�ve attempted to clarify this with Gunther Schadow, but can�t get >>> ��� a response. >>> >>> ��� Meanwhile, I was pointed to this service which does quantity >>> ��� conversions based on UCUM codes: >>> >>> ����� * Form UI - https://ucum.nlm.nih.gov/ucum-lhc/demo.html >>> ����� * API - https://ucum.nlm.nih.gov/ucum-service.html >>> >>> ��� FWIW QUDT now has basic UCUM support as well - >>> >>> https://github.com/qudt/qudt-public-repo/blob/master/schema/SCHEMA_QUDT-v2.1.ttl#L2924 >>> >>> >>> >>> ��� I peered into the UCUM Terms of Use document and I believe this is >>> ��� the relevant clause: >>> >>> ����� * 5) UCUM codes and other information from the UCUM table may be >>> ������� used in electronic messages communicating measurements without >>> ������� the need to include this Copyright Notice and License or a >>> ������� reference thereto in the message (and without the need to >>> ������� include all fields required by Section 7 hereof). >>> >>> ��� So I think we are in the clear to use UCUM codes in the manner >>> ��� that has been discussed in this conversation. >>> >>> I disagree. >>> >>> That just allows exchange of any /measurements/, it doesn't allow use >>> of UCUM codes within metadata. Any service which, for example, >>> provided metadata on units of measures and included UCUM codes as >>> part of that metadata would be in violation. Assuming it including >>> non UCUM metadata then it would violate the "not add any new >>> contents" element of clause 2. If you kept the UCUM codes separate >>> and included /all/ the fields required then you might be able to >>> claim that as the "master term dictionary" use allowed under clause 7 >>> but then would have to show how you were satisfying the notice >>> requirement which has no such corresponding allowance for "electronic >>> messages". >>> >>> I am not a lawyer and so what I say here carries no value. Perhaps >>> the QUDT folks, if they are now using UCUM, have a documented legal >>> opinion that suggests more flexible reuse is possible. >>> >>> Dave >>> >>> ��� *Simon J D Cox * >>> >>> ��� Research Scientist - Environmental Informatics >>> ��� <https://research.csiro.au/ei> >>> >>> ��� Team Leader � Environmental Information Infrastructure >>> >>> ��� CSIRO Land and Water <http://www.csiro.au/Research/LWF> >>> >>> ��� ** >>> >>> ��� *E*simon.cox@csiro.au <mailto:simon.cox@csiro.au> *T*+61 3 9545 >>> ��� 2365 *M*+61 403 302 672 >>> >>> ��� /Mail:/ Private Bag 10, Clayton South, Vic�3169 >>> >>> ��� /Visit: /Central Reception,//Research Way, Clayton, Vic 3168 >>> ��� ///honey.zebra.chip <https://w3w.co/honey.zebra.chip> >>> >>> ��� /Workstation:/ Building 209 ///couple.page.roses >>> ��� <https://w3w.co/couple.page.roses> >>> >>> ��� /Deliver: /Gate 3, Normanby Road, Clayton, Vic 3168 >>> >>> ��� people.csiro.au/Simon-Cox <http://people.csiro.au/Simon-Cox> >>> >>> ��� orcid.org/0000-0002-3884-3420 <http://orcid.org/0000-0002-3884-3420> >>> >>> ��� github.com/dr-shorthair <https://github.com/dr-shorthair> >>> >>> ��� Twitter @dr_shorthair <https://twitter.com/dr_shorthair> >>> >>> ��� https://xkcd.com/1810/ >>> >>> ��� CSIRO acknowledges the Traditional Owners of the land, sea and >>> ��� waters, of the area that we live and work on across Australia. We >>> ��� acknowledge their continuing connection to their culture and we >>> ��� pay our respects to their Elders past and present. >>> >>> ��� The information contained in this email may be confidential or >>> ��� privileged. Any unauthorised use or disclosure is prohibited. If >>> ��� you have received this email in error, please delete it >>> ��� immediately and notify�the sender by return email. Thank you. To >>> ��� the extent permitted by law, CSIRO does not represent, warrant >>> ��� and/or guarantee that the integrity of this communication has been >>> ��� maintained or that the communication is free of errors, virus, >>> ��� interception or interference. >>> >>> ��� CSIRO Australia�sNational Science Agency��| csiro.au >>> ��� <https://www.csiro.au/> >>> >
Received on Thursday, 3 September 2020 14:13:21 UTC