- From: Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>
- Date: Wed, 16 Sep 2020 02:59:01 +0000
- To: Gunther Schadow <gunther@pragmaticdata.com>, Graham Klyne <Graham.Klyne@oerc.ox.ac.uk>, Antoine Zimmermann <antoine.zimmermann@emse.fr>, "Abhyankar, Swapna" <sabhyank@regenstrief.org>, David Booth <david@dbooth.org>, "semantic-web@w3.org" <semantic-web@w3.org>
- CC: "ClemMcDonald@mail.nih.gov" <ClemMcDonald@mail.nih.gov>
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