- From: Chris Mungall <cjmungall@lbl.gov>
- Date: Tue, 15 Sep 2020 21:26:23 -0700
- To: "Cox, Simon (L&W, Clayton)" <Simon.Cox@csiro.au>
- Cc: Antoine Zimmermann <antoine.zimmermann@emse.fr>, "Abhyankar, Swapna" <sabhyank@regenstrief.org>, David Booth <david@dbooth.org>, "semantic-web@w3.org" <semantic-web@w3.org>, "ClemMcDonald@mail.nih.gov" <ClemMcDonald@mail.nih.gov>, "gunther@pragmaticdata.com" <gunther@pragmaticdata.com>, "James A. Overton" <james@overton.ca>, Bjoern Peters <bpeters@lji.org>, Melissa Haendel <melissa@tislab.org>, Kai Blumberg <kblumberg@email.arizona.edu>
- Message-ID: <CAN9Aifv-vuY2COZjH2Kvs0OO-w2OKkAwmxQTbWu_cGaEJqmTFg@mail.gmail.com>
Within the Open Biomedical Ontologies (OBO) project we are converging on a
common measurement schema.
We favor a schema like:
ex:Simon rdf:type foaf:Person ;
ex:height "175.5"^^ucum:cm .
For the same reason Simon does - does not require any parsing. (we'd
actually turn the property into a class and instantiate it but that's less
relevant here)
We'd also like to reuse a standard vocabulary of units - however, joining
with the other part of this thread, OBO is based on CC-BY/CC-0 licensing
and we wouldn't want to get locked into a system with restrictive or
unclear licensing. It would be great if the semantic web community could
converge on a model based on open licenses.
On Tue, Sep 8, 2020 at 5:20 PM Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>
wrote:
> Antoine -
>
> I was reflecting on the earlier correspondence on this list, where two
> alternative patterns for use of UCUM were canvassed:
>
> ex:Simon rdf:type foaf:Person ;
> ex:height "175.5 cm"^^cdt:ucum .
>
> ex:Simon rdf:type foaf:Person ;
> ex:height "175.5"^^ucum:cm .
>
> I had a leaning towards the latter, because it does not require parsing a
> compound literal. That's why I hedged my argument quoted below with "**one
> of** the patterns that is being considered"
>
> Dave Reynolds had pointed out that there was a conventional implication
> that the ucum:XX identifier would need to resolve to something, and that
> potentially runs into UCUM license issues. Yes I was eliding all sorts of
> issues around namespaces etc, and when all is said and done both 'ucum' and
> 'cm' are just text strings. But it is best to play nice, so I was trying
> to honestly head off a potential risk or offense.
>
> Simon
>
> > -----Original Message-----
> > From: Antoine Zimmermann <antoine.zimmermann@emse.fr>
> > Sent: Wednesday, 9 September, 2020 09:55
> > To: 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; gunther@pragmaticdata.com
> > Subject: Re: [External] RE: UCUM licensing [was Re: Blank nodes must
> DIE! ]
> >
> > 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/VOCAB_QUDT-UNITS-ALL-v2.1.ttl For
> > example https://github.com/qudt/qudt-public-
> > repo/blob/master/vocab/unit/VOCAB_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:anyURI ;
> > > 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 04:26:53 UTC