W3C home > Mailing lists > Public > semantic-web@w3.org > September 2020

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

From: Chris Mungall <cjmungall@lbl.gov>
Date: Tue, 15 Sep 2020 21:26:23 -0700
Message-ID: <CAN9Aifv-vuY2COZjH2Kvs0OO-w2OKkAwmxQTbWu_cGaEJqmTFg@mail.gmail.com>
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>
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

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 08:46:05 UTC