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

Thanks Gunther - that is a useful clarification of your intentions. - Simon 

> -----Original Message-----
> From: Gunther Schadow <gunther@pragmaticdata.com>
> Sent: Wednesday, 16 September, 2020 02:07
> To: Graham Klyne <Graham.Klyne@oerc.ox.ac.uk>; Antoine Zimmermann
> <antoine.zimmermann@emse.fr>; Cox, Simon (L&W, Clayton)
> <Simon.Cox@csiro.au>; Abhyankar, Swapna <sabhyank@regenstrief.org>;
> David Booth <david@dbooth.org>; semantic-web@w3.org
> Cc: ClemMcDonald@mail.nih.gov
> Subject: Re: [External] RE: UCUM licensing [was Re: Blank nodes must DIE! ]
> 
> Hi, there is no license issue. There are no restrictions for use of UCUM, nor is
> there even an "appearance of possible restrictions". What are you even
> talking about?
> 
> The only restriction is that you don't redistribute modifications of UCUM.
> 
> regards,
> -Gunther
> 
> 
> On 9/10/2020 5:45 AM, Graham Klyne wrote:
> > Without consideration of specific points raised, I recall from my
> > discussions with researchers about re-using open data, a key concern
> > is that even the appearance of possible restrictions, or uncertainty
> > about licensing terms, can be an inhibiting factor when it comes to
> > reuse.
> >
> > The very fact that this discussion is happening suggests to me that
> > clearer licensing terms, in particular being explicit about what is
> > permitted to be done without permission, would probably promote wider
> > re-use of this UCUM work.
> >
> > (I understand that considerations like this were a factor behind the
> > introduction CC0 public domain dedication for sharable data.)
> >
> > >> 2. QUDT does not 'incorporate the UCUM specification'. QUDT defines
> > a model
> > >> (ontology) for describing units-of-measure. The QUDT definitions
> > >> are functionally the same as the UCUM definitions, but the
> > representation is
> > >> different.
> >
> > Would it be practical to release the QUDT ontology/model as CC0, even
> > if copyright restrictions are retained for the UCUM specification
> > document?  Would that address the concerns raised?
> >
> > #g
> > --
> >
> >
> > On 09/09/2020 00:54, Antoine Zimmermann wrote:
> >> Simon,
> >>
> >>
> >> Le 08/09/2020 à 08:52, Cox, Simon (L&W, Clayton) a écrit :
> >>> Thanks Swapna -
> >>>
> >>> I believe that there are problems with Clause 1. and Clause 2.
> >>>
> >>> I'm not sure how familiar you are with RDF model and syntax so I
> >>> will try to spell it out reasonably fully.
> >>>
> >>> 1. with respect to links - one of the patterns that is being
> >>> considered for RDF quantities would see them encoded something like
> >>>
> >>> ex:Simon rdf:type foaf:Person ;
> >>>     ex:height "175.5"^^ucum:cm ;
> >>> .
> >>
> >> This is probably not a good example since it is not using UCUM codes
> >> at all (except perhaps the fact that "cm" is present in a URI, but so
> >> is "m" in ex:Simon, "a" in foaf:Person, "t" in rdf:type, "u" in
> >> ucum:cm, "P" in foaf:Person, but no copyright laws can prevent anyone
> >> to use one or two letters in URIs).
> >>
> >>> This is the compact 'Turtle' syntax. It is nice because it leaves
> >>> the numeric part alone as a decimal, so the standard RDF parsers
> >>> would work. But also shows the unit of measure right next to it in a
> >>> form which fits with the RDF model. If we assume that the prefixes
> >>> are defined as follows -
> >>>
> >>> @prefix     ex:     <https://example.org/test/> .
> >>> @prefix     foaf:    <http://xmlns.com/foaf/0.1/> .
> >>> @prefix        rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
> >>> @prefix        ucum:    <https://example.com/ucum/> .
> >>>
> >>> Then expanding that data into triples and URIs it looks like this:
> >>>
> >>> <https://example.org/test/Simon>
> >>> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
> >>> <http://xmlns.com/foaf/0.1/Person> .
> >>> <https://example.org/test/Simon> <https://example.org/test/height>
> >>> "175.5"^^<https://example.com/ucum/cm>  .
> >>>
> >>> In the RDF and Linked Data world the expectation is that every http
> >>> URI should de-reference, with the result being a representation or
> >>> description of the thing denoted, preferably in a variety of
> >>> formats.  So the question is: what should
> >>> <https://example.com/ucum/cm> de-reference to? The user would
> expect
> >>> just a description of 'centimetre', preferably with an RDF
> >>> representation available.
> >>
> >> This is not a problem for "cm" because "cm" is an SI unit. Everyone
> >> can use "cm" in any way without copyright reference.
> >>
> >>> The UCUM site and the UCUM table do not meet this expectation.
> >>
> >> What expectation? There is no need or obligation for any
> >> specification to say that anyone must follow linked data principles.
> >>
> >>> The definition for 'cm' does not appear explicitly in the UCUM
> >>> table, because it is implied by the UCUM production rules. But
> >>> clause 1. Of the UCUM Terms of Use
> >>> https://ucum.org/trac/wiki/TermsOfUse appears to prohibit pointing
> >>> to anything except the UCUM specification and table:
> >>>
> >>>     "users shall not use any of the Licensed Materials for the
> >>> purpose of developing or promulgating a different standard for
> >>> identifying units of measure, regardless of whether the intended use
> >>> is in the field of medicine, or any other field of science or trade."
> >>
> >> Using "cm" (or any of the UCUM codes) does not constitute a breach of
> >> this rule. It only breaks the rule if there is a specification that
> >> contradicts the specification in UCUM. Which is not the case in your
> >> example.
> >>
> >>> 2. QUDT does not 'incorporate the UCUM specification'. QUDT defines
> >>> a model (ontology) for describing units-of-measure. The QUDT
> >>> definitions are functionally the same as the UCUM definitions, but
> >>> the representation is different. Each gives the conversion factors
> >>> to the SI unit for the same dimension quantity definition, and is
> >>> also annotated with a variety of symbols used conventionally in
> >>> different contexts, including the UCUM code. The master dataset is
> >>> here:
> >>> https://github.com/qudt/qudt-public-

> repo/blob/master/vocab/unit/VOCA
> >>> B_QUDT-UNITS-ALL-v2.1.ttl
> >>> For example
> >>> https://github.com/qudt/qudt-public-

> repo/blob/master/vocab/unit/VOCA
> >>> B_QUDT-UNITS-ALL-v2.1.ttl#L2769 shows the definition of 'Centimeter'
> >>>
> >>> unit:CentiM
> >>>    a qudt:DerivedUnit ;
> >>>    a qudt:Unit ;
> >>>    dcterms:description "A centimetre is a unit of length in the
> >>> metric system, equal to one hundredth of a metre, which is the SI
> >>> base unit of length. Centi is the SI prefix for a factor of 10.  The
> >>> centimetre is the base unit of length in the now deprecated
> >>> centimetre-gram-second (CGS) system of units."^^rdf:HTML ;
> >>>    qudt:conversionMultiplier "0.01"^^xsd:double ;
> >>>    qudt:conversionOffset "0.0"^^xsd:double ;
> >>>    qudt:dbpediaMatch
> >>> "http://dbpedia.org/resource/Centimetre"^^xsd:anyURI ;
> >>>    qudt:hasQuantityKind quantitykind:Length ;
> >>>    qudt:iec61360Code "0112/2///62720#UAA375" ;
> >>>    qudt:informativeReference
> >>>
> "http://en.wikipedia.org/wiki/Centimetre?oldid=494931891"^^xsd:anyUR
> >>> I ;
> >>>    qudt:isScalingOf unit:M ;
> >>>    qudt:prefix <http://qudt.org/2.1/vocab/prefix/Centi> ;
> >>>    qudt:symbol "cm" ;
> >>>    qudt:ucumCode "cm" ;
> >>>    qudt:uneceCommonCode "CMT" ;
> >>>    qudt:unitOfSystem <http://qudt.org/vocab/sou/SOU_CGS> ;
> >>>    qudt:unitOfSystem <http://qudt.org/vocab/sou/SOU_SI> ;
> >>>    rdfs:isDefinedBy <http://qudt.org/2.1/vocab/unit> ;
> >>>    rdfs:label "Centimeter" ;
> >>> .
> >>
> >> Centimeter is an SI unit, so you can use it, define it, do whatever
> >> you like, however you like with it. There is no reason to even
> >> consider UCUM copyright notice.
> >>
> >>> One of the annotations is the UCUM Code - cm. However, showing the
> >>> UCUM code in the context of a representation of this unit-of-measure
> >>> that is different to the UCM specification appears to violate Clause
> >>> 1. of the UCUM Terms of Use, quoted above, even though it is
> >>> functionally equivalent, and probably also Clause 2:
> >>>
> >>>     "Users shall not modify the Licensed Materials and may not
> >>> distribute modified versions of the UCUM table (regardless of
> >>> format) or UCUM Specification. Users shall not modify any existing
> >>> contents, fields, description, or comments of the Licensed
> >>> Materials, and may not add any new contents to it."
> >>> .
> >>>
> >>> since the QUDT representation includes additional information that
> >>> is not from the UCUM specification.
> >>
> >> UCUM and its copyright notice is not preventing anyone from using
> >> other ways of representing, exchanging, defining units of measures.
> >>
> >>> The UCUM Terms of Use appear to reflect some assumptions from an
> >>> earlier time, when most software was self-contained and designed to
> >>> run locally. The web and cloud give us the opportunity to compose
> >>> software systems in a more distributed manner, with small elements
> >>> disaggregated and transferred as-needed, often with a variety of
> >>> representations available. UCUM is an excellent resource, but the
> >>> license inhibits its impact in the more modern environment.
> >>
> >> 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.
> >>
> >> 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/>
> >>>>      > >>>
> >>>>      > >
> >>>>
> >>>>
> >>>
> >>
> >

Received on Wednesday, 16 September 2020 02:59:28 UTC