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

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

From: Antoine Zimmermann <antoine.zimmermann@emse.fr>
Date: Thu, 10 Sep 2020 15:52:21 +0200
To: semantic-web@w3.org, "Cox, Simon (L&W, Clayton)" <Simon.Cox@csiro.au>
Message-ID: <03eef3a3-b649-9a11-6dbd-d6cd78d6a857@emse.fr>
Simon,

I would like to clarify one thing:

Le 09/09/2020 à 01:54, Antoine Zimmermann a écrit :
> Simon,
> 
> [...]
> 
> I don't agree. The UCUM terms should be updated because they are not 
> sufficiently clear about how UCUM can be used, but they are not 
> preventing any of the things you are pretending.

I've been careless about my poor choice of word here. I did not mean 
this as an attack and merely wanted to say "things you are describing".
Apologise for the harsh-sounded sentence. This is what happens when one 
sends emails late at night (it was 1:30 am in my place).

--AZ


> 
> The following may be a better example:
> 
>   @prefix cdt: <http://w3id.org/lindt/custom_datatypes#>
>   ex:glass ex:contains "1 [pt_us]"^^cdt:ucum .
> 
> In this case, the data is using the code [pt_us], which is clearly a 
> UCUM code, and the datatype IRI is dereferencing to a specification of 
> the datatype that mentions UCUM. This specification should mention the 
> copyright notice, but it does not. As far as I understand Swapna's 
> email, the use of [pt_us] in the data is not a problem, but the failure 
> to reproduce the copyright notice in the specification of cdt:ucum 
> (http://w3id.org/lindt/custom_datatypes#ucum) is.
> 
> --AZ
> 
>>
>> Simon
>>
>>> -----Original Message-----
>>> From: Abhyankar, Swapna <sabhyank@regenstrief.org>
>>> Sent: Tuesday, 8 September, 2020 12:09
>>> To: Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>; David Booth
>>> <david@dbooth.org>; semantic-web@w3.org
>>> Cc: ClemMcDonald@mail.nih.gov; gunther@pragmaticdata.com
>>> Subject: Re: [External] RE: UCUM licensing [was Re: Blank nodes must 
>>> DIE! ]
>>>
>>> Hi everyone,
>>>
>>> (I don't know what the protocol is on these messages - should I remove
>>> individual recipients who are also on the list)?
>>>
>>> What we intend is that if UCUM units are used in conjunction with 
>>> data, no
>>> copyright notice is needed. It’s only if the specification itself is 
>>> incorporated
>>> into a product or service for distribution, then the notice will be 
>>> needed. This
>>> is the same for LOINC – if LOINC codes are used in conjunction with 
>>> patient
>>> data, no notices are required.
>>>
>>> I'm not sure I entirely understand your statement - "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."
>>> Would it be possible for you to send some examples? If the UCUM codes 
>>> are
>>> simply being used in conjunction with quantitative data, then I don't 
>>> think
>>> there's a problem, but I'm not sure where linking to a definition for 
>>> the code
>>> comes in to play.
>>>
>>> Also, I am not familiar with QUDT, but if QUDT incorporates the UCUM
>>> specification, we would simply require inclusion of the copyright 
>>> notice in the
>>> QUDT license or terms of use or webpage(s) that include UCUM content to
>>> acknowledge Regenstrief as the copyright holder of UCUM.
>>>
>>> I would be happy to have a call to discuss these issues so that I may
>>> understand them better and determine how to proceed as we discuss
>>> updating the UCUM terms of use with Regenstrief  legal counsel.
>>>
>>> Thanks,
>>> Swapna
>>>
>>> ----------------------------------------------------
>>> Swapna Abhyankar, MD
>>> Interim Director
>>> LOINC and Health Data Standards
>>> 1101 West Tenth Street
>>> Indianapolis, IN  46202
>>>
>>>
>>> On 9/3/20, 7:33 PM, "Cox, Simon (L&W, Clayton)" <Simon.Cox@csiro.au>
>>> wrote:
>>>
>>>      This message was sent from a non-IU address. Please exercise 
>>> caution
>>> when clicking links or opening attachments from external sources.
>>>      -------
>>>
>>>      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/>
>>>      > >>>
>>>      > >
>>>
>>>
>>
> 
> 

-- 
Antoine Zimmermann
Institut Henri Fayol
École des Mines de Saint-Étienne
158 cours Fauriel
CS 62362
42023 Saint-Étienne Cedex 2
France
Tél:+33(0)4 77 42 66 03
Fax:+33(0)4 77 42 66 66
http://www.emse.fr/~zimmermann/
Member of team Connected Intelligence, Laboratoire Hubert Curien
Received on Thursday, 10 September 2020 13:52:37 UTC

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