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

Excellent - I had just been fossicking around the LHNCBC site trying to track down someone who might be able to help, since they host some nice UCUM tools. I found than Clem McDonald, who was one of the originators of UCUM (along with Gunther Schadow) is now based there. I've cc'ed them both here, though I haven't had any recent response from attempts to contact Gunther. 

AFAICT there are two primary concerns: 

1. the proposals for use of UCUM for qualifying quantity values in RDF are fine as long as it is just the UCUM code that is used, but as soon as there is an expectation of a link to a definition for the code, then we may fall foul of the original Terms of Use if we link to anything other than the UCUM spec itself. 

2. closely related (though not previously on this list), QUDT does provide individual definitions of units of measure, following their own ontology. These are functionally equivalent to the definitions implied in the UCUM spec (of course) but UCUM does not provide a way to transport individual definitions, so the QUDT representations are "different". Furthermore, many of the individual units in the QUDT library are annotated with UCUM codes (alongside other symbols and codes). Does this violate the UCUM license? Probably yes. 

Everyone's intentions are honourable, and in particular the interest from RDF and QUDT recognizes the excellent job that UCUM does in providing readable, unique codes, which nicely solves an important problem - all credit to UCUM. ... except for the issue around the license. It would be to everyone's benefit to get this resolved. 

Simon Cox

> -----Original Message-----
> From: David Booth <david@dbooth.org>
> Sent: Friday, 4 September, 2020 00:13
> To: semantic-web@w3.org
> Cc: Abhyankar, Swapna <sabhyank@regenstrief.org>
> Subject: UCUM licensing [was Re: Blank nodes must DIE! ]
> 
> 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%20D
> IE!%2
> >>> 0%5B%20was%20Re%3A%20Blank%20nodes%20semantics%20-
> %20%20existential%
> >>> 20variables%3F%5D&In-Reply-
> To=%3CCAFfrAFqgq7JxxwzEhYoMV70haRznXkjLBi
> >>>
> OwhQUjwGJ0S0vsug%40mail.gmail.com%3E&References=%3CCAFfrAFqgq7J
> xxwzE
> >>> hYoMV70haRznXkjLBiOwhQUjwGJ0S0vsug%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_Q
> >>> UDT-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 Friday, 4 September 2020 00:38:24 UTC