W3C home > Mailing lists > Public > semantic-web@w3.org > September 2020

UCUM licensing [was Re: Blank nodes must DIE! ]

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>
Message-ID: <d1250691-31b1-54af-42f5-52722f1f0cf4@dbooth.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

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 08:46:05 UTC