- From: Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>
- Date: Wed, 16 Sep 2020 02:59:00 +0000
- To: 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>, "gunther@pragmaticdata.com" <gunther@pragmaticdata.com>
> > (I understand that considerations like this were a factor behind the introduction CC0 public domain dedication for sharable data.) Indeed. I had conversations with Wikidata people around this. The story I got was that, as a volunteer initiative, it does not have the resources to evaluate the licenses for everything that they would like to use, so they use a simple criterion: CC0 OK, anything else, they will build their own ontology instead. > > 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? I think QUDT's license is a separate issue. However, I had already raised this with the maintainers and I will use this conversation to revive that proposal. QUDT has just formed a Technical Advisory Committee so I can raise it there. It is a small thing that I was concerned about (triggered by Dave Reynolds observation): if a request is made for the definition of a unit-of-measure, in which the query key is a UCUM code, then is it OK to get a QUDT-encoded resource? QUDT is equivalent to, but not the same as, the UCUM XML table, so this could be seen as violating the UCUM license (though probably only if you are looking to pick a fight, which I don't think any of us are). Simon > -----Original Message----- > From: Graham Klyne <Graham.Klyne@oerc.ox.ac.uk> > Sent: Thursday, 10 September, 2020 19:45 > To: 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; gunther@pragmaticdata.com > Subject: Re: [External] RE: UCUM licensing [was Re: Blank nodes must DIE! ] > > 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/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/> > >>> > >>> > >>> > > > >>> > >>> > >> > > > > -- > Graham Klyne > mailto:graham.klyne@oerc.ox.ac.uk > Skype/Twitter: @gklyne
Received on Wednesday, 16 September 2020 02:59:29 UTC