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

I think BY-ND is very appropriate.
this is an excellent initiative, thank you Simon !

Best regards,
Maxime Lefrançois

Le mer. 24 févr. 2021 à 11:56, Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>
a écrit :

> I have suggested that UCUM replace the non-standard license with CC BY-ND,
> also with explicit clarification on the BY obligation and ND prohibition –
> see https://ucum.org/trac/ticket/5778 .
>
> If anyone on this thread thinks that would still be problematic, then
> please speak up urgently!
>
>
>
> *From:* Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>
> *Sent:* Thursday, 28 January, 2021 18:43
> *To:* phayes@ihmc.us
> *Cc:* Abhyankar, Swapna <sabhyank@regenstrief.org>; "“semantic-web@w3.org”"
> <semantic-web@w3.org>; David Booth <david@dbooth.org>; Maxime Lefrançois <
> maxime.lefrancois@emse.fr>
> *Subject:* [ExternalEmail] RE: [External] Re: UCUM licensing [was Re:
> Blank nodes must DIE! ]
>
>
>
> Indeed Pat, I agree, and actually the people behind UCUM do as well (I’ve
> asked them). But plenty of people in our community have found the wording
> in the ‘Terms of Use’ sufficiently fierce, and non-standard that they
> prefer to just walk away. Which is bad for UCUM and bad for the rest of us.
>
>
>
> I’ve put this high up on the agenda in the UCUM advisory board.
>
>
>
> *From:* phayes@ihmc.us <phayes@ihmc.us>
> *Sent:* Friday, 15 January, 2021 10:56
> *To:* Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>
> *Cc:* Abhyankar, Swapna <sabhyank@regenstrief.org>; "“semantic-web@w3.org”"
> <semantic-web@w3.org>; David Booth <david@dbooth.org>; Maxime Lefrançois <
> maxime.lefrancois@emse.fr>
> *Subject:* Re: [External] Re: UCUM licensing [was Re: Blank nodes must
> DIE! ]
>
>
>
>
>
>
>
> On Jan 14, 2021, at 1:10 PM, Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>
> wrote:
>
>
>
> Just found this draft that I should have sent 4 months ago.
>
> -----------
>
>
>
> Thanks Swapna –
>
>
>
> Looking at https://ucum.org/trac/wiki/TermsOfUse I see the following
> issues:
>
>
>
> Clause 1)
>
> “… users shall not use any of the Licensed Materials for the purpose of
> developing or promulgating a different standard for identifying units of
> measure …”
>
>
>
> It has been proposed to use UCUM codes in the context of RDF data to
> indicate the scale for quantity data. The exact arrangement has not been
> decided. But it is expected that it will be necessary to use web-links for
> individual units-of-measure, which will include the UCUM code as an element
> or an argument. Dereferencing these should get a , and that these should
>
>
>
> QUDT (http://qudt.org/) is a different standard, designed with an
> RDF/OWL/SHACL representation. Every unit-of-measure in the QUDT vocabulary
> is ‘identified’ using a URI. There is an (optional) field in QUDT to add
> the UCUM code as an ‘annotation’ on an individual description, to support
> cross-matching or to enable discovery using the UCUM code. But the use of
> UCUM codes in the context of QUDT appears to violate this provision.
>
>
>
> Surely that turns on what constitutes "use" of the licensed materials. I
> could argue a case in court that placing a hyperlink in an annotation, for
> the sole purpose of facilitating access to the licenced materials, does not
> constitute use. In fact I believe this very matter recently came before a
> European court and was decided in the rational way. Sorry I do not have the
> links handy.
>
>
>
> Pat Hayes
>
>
>
>
>
>
>
> Simon
>
>
>
>
>
>
>
> *From:* Abhyankar, Swapna <sabhyank@regenstrief.org>
> *Sent:* Friday, 4 September, 2020 01:15
> *To:* “semantic-web@w3.org” <semantic-web@w3.org>
> *Cc:* David Booth <david@dbooth.org>; Maxime Lefrançois <
> maxime.lefrancois@emse.fr>
> *Subject:* Re: [External] Re: UCUM licensing [was Re: Blank nodes must
> DIE! ]
>
>
>
> Hi everyone,
>
>
>
> Can someone please summarize the issues related to the UCUM terms of use?
> We are in the process of updating the terms, so your timing is perfect, but
> the bottom line is that when the codes are used in conjunction with
> clinical data, no copyright notice will be required.
>
>
>
> Thank you!
>
> -Swapna
>
>
>
> ----------------------------------------------------
>
> *Swapna Abhyankar, MD*
>
> Interim Director
>
> LOINC and Health Data Standards
>
> <image001.png>
>
> 1101 West Tenth Street
>
> Indianapolis, IN  46202
>
>
>
> Confidentiality Notice: The contents of this message and any files
> transmitted with it may contain confidential and/or privileged information
> and are intended solely for the use of the named addressee(s).
> Additionally, the information contained herein may have been disclosed to
> you from medical records with confidentiality protected by federal and
> state laws. Federal regulations and State laws prohibit you from making
> further disclosure of such information without the specific written consent
> of the person to whom the information pertains or as otherwise permitted by
> such regulations. A general authorization for the release of medical or
> other information is not sufficient for this purpose.
>
>
>
> If you have received this message in error, please notify the sender by
> return e-mail and delete the original message. Any retention, disclosure,
> copying, distribution or use of this information by anyone other than the
> intended recipient is strictly prohibited.
>
>
>
>
>
> *From: *Maxime Lefrançois <maxime.lefrancois@emse.fr>
> *Date: *Thursday, September 3, 2020 at 10:22 AM
> *To: *David Booth <david@dbooth.org>
> *Cc: *"“semantic-web@w3.org”" <semantic-web@w3.org>, "Abhyankar, Swapna" <
> sabhyank@regenstrief.org>
> *Subject: *[External] Re: UCUM licensing [was Re: Blank nodes must DIE! ]
>
>
>
> This message was sent from a non-IU address. Please exercise caution when
> clicking links or opening attachments from external sources.
>
>
>
> 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/>
> >>>
> >
>
>
>