- From: Maxime Lefrançois <maxime.lefrancois@emse.fr>
- Date: Thu, 3 Sep 2020 16:21:55 +0200
- To: David Booth <david@dbooth.org>
- Cc: “semantic-web@w3.org” <semantic-web@w3.org>, "Abhyankar, Swapna" <sabhyank@regenstrief.org>
- Message-ID: <CALsPASWfPn_BuKccNWokGj-kJ-5BNs7OkbXi8kC05ALkpnY6oQ@mail.gmail.com>
Dear all, I am very happy to see that things are moving in the right direction with UCUM! Thanks a lot! I am looking forward to resuming the work on cdt:ucum, and would be excited to see it usable in triplestores. Best regards, Maxime Lefrançois MINES Saint-Étienne http://maxime-lefrancois.info/ Le jeu. 3 sept. 2020 à 16:15, David Booth <david@dbooth.org> a écrit : > 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:22:24 UTC