- 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>
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