[GeoSciML] [ELFIE] FW: HY_Features OWL

Joshua Lieberman jlieberman at tumblingwalls.com
Mon Jan 29 17:38:01 EST 2018


Hey, we have a formal test for UML conformance. It’s called “inspection” ;>)

I agree that normative conceptualization has always been a somewhat peculiar idea, but not sure that any more recent means of establishing broad agreements has been any more successful. We may just have more narrow agreements now.

—Josh

> On Jan 29, 2018, at 5:17 PM, <Simon.Cox at csiro.au> <Simon.Cox at csiro.au> wrote:
> 
> The premise here is that UML is canonical (per ISO 19103).
> I’m sceptical.
>  
> In practice modelling paradigms and tools evolve, for both good and bad reasons.
> UML was a noble attempt to merge CASE and ‘KR’ but in the end is arguably weighed down by the CASE side.
> I understand ShapeChange has been used to generate ISO 19150 conformant OWL from UML, but to what end?
> No-one really uses the resulting OWL for anything practical.
>  
> Meanwhile, significant parts of the software development world have moved on to lighter-weight processes.
> We can rail against this all we like, but I fear it’s a losing proposition.
> Probably both UML and OWL are just convenient notations for conceptualization.
> In practice they serve mostly as formalized check-lists usually applied manually.
>  
> Simon
>  
> From: Joshua Lieberman [mailto:jlieberman at tumblingwalls.com] 
> Sent: Tuesday, 30 January, 2018 08:57
> To: Boisvert2, Eric (NRCan/RNCan) <eric.boisvert2 at canada.ca>
> Cc: Rob Atkinson <rob at metalinkage.com.au>; Public: A mailing list for GeoSciML <geosciml at lists.opengeospatial.org>; elfie at lists.opengeospatial.org; Cox, Simon (L&W, Clayton) <Simon.Cox at csiro.au>
> Subject: Re: [ELFIE] [GeoSciML] FW: HY_Features OWL
>  
> It does seem feasible to “store” in UML what is needed to generate a usable ontology, but it seems necessary to put effort into creating the ontology and then reflecting that back on the UML encoding. Eventually there can be a set of rules and practices to draw from, but I’m not sure we really know yet all of what constitutes ontology usability.
>  
> —Josh
>  
> 
> 
> On Jan 29, 2018, at 4:35 PM, Boisvert2, Eric (NRCan/RNCan) via ELFIE <elfie at lists.opengeospatial.org <mailto:elfie at lists.opengeospatial.org>> wrote:
>  
> > but many environments have hacked up special tags and OCL conventions to add to the UML.
>  
> Speaking of which, Enterprise Architect support OWL modelling (can only read/write OWL/RDF in XML)
>  
> <image001.png>
>  
> From: Rob Atkinson [mailto:rob at metalinkage.com.au <mailto:rob at metalinkage.com.au>] 
> Sent: Monday, January 29, 2018 3:51 PM
> To: Boisvert2, Eric (NRCan/RNCan)
> Cc: Simon.Cox at csiro.au <mailto:Simon.Cox at csiro.au>; Public: A mailing list for GeoSciML; elfie at lists.opengeospatial.org <mailto:elfie at lists.opengeospatial.org>; rob at metalinkage.com.au <mailto:rob at metalinkage.com.au>
> Subject: Re: [GeoSciML] FW: HY_Features OWL
>  
>  
> We all know that OWL can potentially express more - except for diagramming viewpoints, which isnt to be discounted lightly. Though probably anything can be smuggled in tags - including full OWL models of every class and property :-)  The problem is having a canonical expression of the missing bits, but AFAIK no one has articulated these adequately, but many environments have hacked up special tags and OCL conventions to add to the UML.
>  
> Lets get some experience with OWL representations and identify what else actually needs to be captured we could do in a formal way.
>  
> The problem is not UML->OWL   - its the OWL representation of ISO HM which may not add any extra value. 
>  
> IMHO
>  
>  UML (normative) -> (rules and tools) ->  OWL (ISO flavour) -> (entailment rules) ->  Plain OLD OWL
>  
> is better than
>  
> UML -> hack (with some patterns that may or may not be documented or repeatable) -> OWL -> edit -> edit -edit ->edit...
>  
> when we have more that one UML model ....
>  
>  
>  
>  
> On Mon, 29 Jan 2018 at 23:22 Boisvert2, Eric (NRCan/RNCan) <eric.boisvert2 at canada.ca <mailto:eric.boisvert2 at canada.ca>> wrote:
> Right.   I’m questioning the UML->OWL route as UML is less expressive than OWL and our UML has a lot of XSD artefacts
>  
> From: GeoSciML [mailto:geosciml-bounces+eric.boisvert2 <mailto:geosciml-bounces%2Beric.boisvert2>=canada.ca at lists.opengeospatial.org <mailto:canada.ca at lists.opengeospatial.org>] On Behalf Of Simon.Cox--- via GeoSciML
> Sent: January 28, 2018 03:23
> To: geosciml at lists.opengeospatial.org <mailto:geosciml at lists.opengeospatial.org>; geosciml at lists.opengeospatial.org <mailto:geosciml at lists.opengeospatial.org>; elfie at lists.opengeospatial.org <mailto:elfie at lists.opengeospatial.org>
> Cc: rob at metalinkage.com.au <mailto:rob at metalinkage.com.au>
> Subject: Re: [GeoSciML] FW: HY_Features OWL
>  
> The rules for codeLists in ISO 19150-2 are pretty good (I wrote them).
> 
> The rest of the 19150-2 rules lead to an UML-in-OWL encoding rather than OWL as an ontologist would have done it. They have the benefit of consistency though.
> 
> From: GeoSciML <geosciml-bounces at lists.opengeospatial.org <mailto:geosciml-bounces at lists.opengeospatial.org>> on behalf of Boisvert2, Eric (NRCan/RNCan) via GeoSciML <geosciml at lists.opengeospatial.org <mailto:geosciml at lists.opengeospatial.org>>
> Sent: Friday, 26 January 2018 1:09:39 PM
> To: GeoSciml OGC mainling list; 'elfie at lists.opengeospatial.org <mailto:elfie at lists.opengeospatial.org>'
> Subject: [GeoSciML] FW: HY_Features OWL
>  
> Discussion about OWL encoding of interest for GeoSciML and ELFIE.
>  
> From: Rob Atkinson [mailto:rob at metalinkage.com.au <mailto:rob at metalinkage.com.au>] 
> Sent: January 25, 2018 05:41
> To: Feliachi Abdel <A.Feliachi at ext.brgm.fr <mailto:A.Feliachi at ext.brgm.fr>>
> Cc: Rob Atkinson <rob at metalinkage.com.au <mailto:rob at metalinkage.com.au>>; Boisvert2, Eric (NRCan/RNCan) <eric.boisvert2 at canada.ca <mailto:eric.boisvert2 at canada.ca>>; Grellet Sylvain <S.Grellet at brgm.fr <mailto:S.Grellet at brgm.fr>>; Sen, Marcus A <mase at bgs.ac.uk <mailto:mase at bgs.ac.uk>>
> Subject: Re: HY_Features OWL
>  
> Nice to meet you Abdel!
>  
> I think one aspect is how CodeLists are encoded - as they are technically extensible in use (unlike Enumerations) they logically get mapped to ConceptSchemes - so we need to generate these from the UML at some point.
>  
> Anyway, as i sadly am not in a position currently to drive a deep analysis of options and a consensus approach I'm hoping to at least understand where and why others make choices, and follow. That said happy to debate such choices as and when you want to throw cases into the discussion
>  
> Rob
>  
>  
>  
> On Thu, 25 Jan 2018 at 20:28 Feliachi Abdel <A.Feliachi at ext.brgm.fr <mailto:A.Feliachi at ext.brgm.fr>> wrote:
> Hello everyone. Abdel here.
> Very glad to be able discuss this topic with you (directly J).
> I’ll try to go right to the point. Please correct me when wrong or misunderstanding your goals.
>  
> > the OWL restrictions on vocabulary is pretty ugly - and i wonder where the information in the UML exists? nothing in HY_Features - unless this is also used for every CodeList? 
>  
>  If this is a binding to the schema done later,  then it would easier to use a simple vocabulary to make the assertion, then entail the OWL syntax if required. (RDF-QB allows neater and more finer grained binding to a ConceptScheme for example)
>  
> Absolutely Rob. This must be done for every CodeList after the transformation.  It is a way to bind the property to a specific CodeList. 
>  
> What is proposed in RDF-QB (through the qb:codeList I believe) allows referring to a specific conceptScheme, but it doesn’t provide in anyway a restriction on the possible values of the class qb:CodedProperty.
> àIf we would like to restrict the user of the ontology to a specific CodeList (conceptScheme, collection or others) we should go through an  owl:hasValue restriction.
> àIf we don’t want it to be a real restriction (in a ontological sense) and want to provide a simple indication to the users about the CodeList,  we could use a similar approach to RDF-QB
>  
> This having been said, we haven’t applied this type of restriction with GSML ontologies yet, but it could be done after defining or choosing a specific controlled vocabulary for every CodeList.
>  
> Abdel.
>  
> De : Rob Atkinson [mailto:rob at metalinkage.com.au <mailto:rob at metalinkage.com.au>] 
> Envoyé : mercredi 24 janvier 2018 22:08
> À : Boisvert2, Eric (NRCan/RNCan) <eric.boisvert2 at canada.ca <mailto:eric.boisvert2 at canada.ca>>
> Cc : Grellet Sylvain <S.Grellet at brgm.fr <mailto:S.Grellet at brgm.fr>>; Rob Atkinson <rob at metalinkage.com.au <mailto:rob at metalinkage.com.au>>; Sen, Marcus A <mase at bgs.ac.uk <mailto:mase at bgs.ac.uk>>; Feliachi Abdel <A.Feliachi at ext.brgm.fr <mailto:A.Feliachi at ext.brgm.fr>>
> Objet : Re: HY_Features OWL
>  
> OK - I think i'm happy with the proposals/directions - so the question is - can anyone use these rules for  process HY_Features as well as your favourite target ?
>  
> comments:
>  
> - the OWL restrictions on vocabulary is pretty ugly - and i wonder where the information in the UML exists? nothing in HY_Features - unless this is also used for every CodeList? 
>  
>  If this is a binding to the schema done later,  then it would easier to use a simple vocabulary to make the assertion, then entail the OWL syntax if required. (RDF-QB allows neater and more finer grained binding to a ConceptScheme for example)
>  
> regardless, happy just to have a canonical encoding using a common strategy.
>  
> Rob
>  
>  
>  
> On Thu, 25 Jan 2018 at 04:01 Boisvert2, Eric (NRCan/RNCan) <eric.boisvert2 at canada.ca <mailto:eric.boisvert2 at canada.ca>> wrote:
> 1: And I have one too. (https://github.com/denevers/geoscimlrdf <https://github.com/denevers/geoscimlrdf>) maybe we should use OGC’s ?
>  
> > Using restrictions on property values for a given class can be a way for specifying the skos:ConceptScheme that a skos:Concept must belong to.
>  
> I like this.
>  
> > We agree. In the case of GSML ontologies, we followed the best practice of leaving the range of the properties open.
>  
> That’s what’s I ended up doing.  So I’m good.
>  
> > not used to make assertions
>  
> I think this is Boyan’s point.
>  
> Side question.  Does this works requires a formal IE ?  still in limbo here ..
>  
>  
> From: Grellet Sylvain [mailto:S.Grellet at brgm.fr <mailto:S.Grellet at brgm.fr>] 
> Sent: January 24, 2018 11:51
> To: Boisvert2, Eric (NRCan/RNCan) <eric.boisvert2 at canada.ca <mailto:eric.boisvert2 at canada.ca>>; 'Rob Atkinson' <rob at metalinkage.com.au <mailto:rob at metalinkage.com.au>>
> Cc: Sen, Marcus A <mase at bgs.ac.uk <mailto:mase at bgs.ac.uk>>; Feliachi Abdel <A.Feliachi at ext.brgm.fr <mailto:A.Feliachi at ext.brgm.fr>>
> Subject: RE: HY_Features OWL
>  
> Guys,
>  
> At first I was willing to
> 1st share under GitHub the work on a GeoSciML ontology primer we’ve done (https://github.com/BRGM/GeoSciMLontology <https://github.com/BRGM/GeoSciMLontology>)
> 2nd reply to this thread, introducing Abdel (the ‘ontologist’  I pick the brain from) and let him contribute. But I have an issue interacting with GitHub from within BRGM network so I’ll do it the other way around and try to commit from home
> Find below the result of our internal discussions with Abdel and attached the quick note we produced when generated the ontologies incl. ShapeChange conf choices (will be on GitHub).
>  
> >> You could define rdfs:range to be a skos:Concept
> > Yeah, well let’s not bring Boyan in the discussion then.  The problem with SKOS, it’s for terms, not concepts.
> > I can’t completely defend this statement - yet. 
>  
> Using restrictions on property values for a given class can be a way for specifying the skos:ConceptScheme that a skos:Concept must belong to.
> So, instead of adding a restriction a so
>  
> MyOnto:MyClass
>                               a                owl:Class ;
>                               rdfs:subClassOf  [ a                  owl:Restriction ;
>                            owl:allValuesFrom  skos:Concept;                                                                                                                                                                              
>                            owl:onProperty     MyOnto:myProperty
>                          ] ;
>                                                                                         
>  
> We can express it as so                              
>                                                                                           
> MyOnto:MyClass
>                               a                owl:Class ;
>                               rdfs:subClassOf  [ a                  owl:Restriction ;
>                            owl:allValuesFrom  [ 
>                                                                                                                                                                                  rdfs:subClassOf                skos:Concept; 
>                                                                                                                                                                                  rdfs:subClassOf  [            a                  owl:Restriction;
>                                                                                                                                                                                                                                                            owl:hasValue   MyVocab:MyConceptScheme;
>                                                                                                                                                                                                                                                            owl:onProperty     skos:inScheme                                                                                                                                                                                                                                          
>                                                                                                                                                                                                                                                            ] ;
>                                                                                                                                                     ];
>                            owl:onProperty     MyOnto:myProperty
>                          ] ;
>                                                                                         
> Note that using owl:hasValue makes the OWL ontology not OWL Lite.
>  
> >GW_UnitVoidProperty is modelled as  [GW_HydrogeoUnit]  ----gwUnitVoid---- > [GW_UnitVoidProperty] ---- gwUnitVoid --- > [GW_HydrogeoVoid]
>  
> While creating GSML ontologies we decided to model association properties as when we go from a conceptual to a logical representation (looks as  a reification but we prefer use the term carefully) as so:
> [GW_HydrogeoUnit]  <----gwUnit----  [GW_UnitVoidProperty] ---- gwVoid --- > [GW_HydrogeoVoid]
>  
> >> the default position would be to either leave the range open or create a union.  Best practices seem to be leave domains open (and use schema:domainIncludes annotation properties - thus allowing related models to reuse properties if needing the same semantics.
>  
> >I’ll have to look this up.
> We agree. In the case of GSML ontologies, we followed the best practice of leaving the range of the properties open. We used value restriction of properties in the classes definitions (using owl:allValuesFrom).
>  
> >> AFAICT the main issue to narrow down is around property naming and scoping. I think HY_Features is simpler - all property names shoudl be scoped to Application Schema. 
> >Isn’t what the namespace does ?.   In our case, we duplicate property names in the same package (role) and Association class pattern that generates the same property name at both end of the class
> When working on GSML ontologies we used scoped properties names (using the pattern "class"."property" as suggested in ISO 19150-2) only in the case of homonym properties. We checked the definition of these properties afterward to see if they are synonyms or not in order to decide whether to unify their names or to keep them scoped to their classes.
>  
> >> RDFS only implements the "any ancestor including myself" transitive model if you perform any OWL or RDFS based reasoning.
>  
> >Ok, you need a distinction between immediate parent and any parent. Got it.
> On some engines (I know Sesame does, or whatever backend it talks to), you can turn inference off. So subClassOf is just “immediate”.
> Probably not helpful.
>  
> As explained in the SKOS ontology, the properties skos:broaderTransitive and skos:narrowerTransitive are, by convention, not used to make assertions. They are defined so they used to "to draw inferences about the transitive closure of the hierarchical relation".  They are defined because SKOS lack of formality unlike RDFS or OWL where the subClassOf property is transitive by (logical) definition.
>  
> >> these are the sort of shapechange configuration (or post processing rules) i was hoping to find and apply consistently - certainly sounds as if you need a replicable approach for your different sub-domains - lets agree on a single way !
> >Agree. I’m still exploring what the UML does not say but should.  ShapeChange can’t guess the intent.
> cf. our note about using ISO 19150-2 and ShapeChange for defining GSML ontologies
>  
> >> Happy to convene a telconference to discuss/explore
> +1
>  
> Sylvain & Abdel
>  
>  
> From: Rob Atkinson [mailto:rob at metalinkage.com.au <mailto:rob at metalinkage.com.au>] 
> Sent: Tuesday, January 23, 2018 6:33 PM
> To: Boisvert2, Eric (NRCan/RNCan)
> Cc: Rob Atkinson; Grellet Sylvain; Sen, Marcus A
> Subject: Re: HY_Features OWL
>  
> As always Eric, to the point ...
>  
> really good to be thinking it through from an implementation perspective.
>  
> Couple of thoughts:
>  
> Further description of semantics of properties defined in one way may need to be done at the model level, or at the dataset level.  Look at RDF-QB - it basically provides a way to handle binding to vocabularies, (using SKOS), narrowed ranges and specify quantities and index dimensions.  You could define rdfs:range to be a skos:Concept , but there is no way in OWL I think to specify an external vocabulary.
>  
> The hierarchy is the difference between skos:broader and skos:broaderTransitive  - skos:broader is the immediate parent. RDFS only implements the "any ancestor including myself" transitive model if you perform any OWL or RDFS based reasoning.
>  
> the gwUnitVoid example comes down to semantics: are they the same thing?
>  
> first step is scoping the property to the application schema (= namespace), not to specific classes.
>  
> the default position would be to either leave the range open or create a union.  Best practices seem to be leave domains open (and use schema:domainIncludes annotation properties - thus allowing related models to reuse properties if needing the same semantics.
>  
> these are the sort of shapechange configuration (or post processing rules) i was hoping to find and apply consistently - certainly sounds as if you need a replicable approach for your different sub-domains - lets agree on a single way !
>  
> Rob
>  
>  
>  
>  
>  
>  
> On Tue, 23 Jan 2018 at 23:45 Boisvert2, Eric (NRCan/RNCan) <eric.boisvert2 at canada.ca <mailto:eric.boisvert2 at canada.ca>> wrote:
> I’m actually doing more of a skeleton because I have coverging need
> -One internal Linked Open Data projet
> - A OGC IE (ELFIE)
> - One USGS-Canada project
> - potentially one GeoSciML IE (I need GeoSciML for GWML)
>  
> I’m doing it manually right now – not looking into the automation at this point, but looking into discussion point about how to deal with some famillies of properties and then pick the brain of “ontologist”.  I think I’d like to see what you call “POO” (there is no way we are officially calling it this way) as the canonical representation
>  
> Eg:
>  
> - properties that are vocabularies , which essentially means that they may be refereeing to other ontologies
> - properties that are quantities
> - properties that are “soft typing” (ie, geologicUnitType), which somehow announce that this class might be subclasses – and this is what IGS did (for RockMaterial, they turned our lithology vocabularies as sub types of RockMaterial).
>  
> > but also it supports explicit hierarchies that are lost in RDFS/OWL inferencing - what is the actual superclass ? 
>  
> Not sure I’m following you because I immediately though of rdf:subClassOf (but it’s the inverse relationship).  So what you mean is there is no explicit way (no inverse of rdfs:subClassOf) to point to the superclass (that might not be in the same document). ?
>  
> > All this is easy to contemplate - however when I started to look at the ShapeChange implementation, there is no off-the-shelf set of encoding rules - they have a wide range of inputs and experiments and a grab bag of options. 
>  
> I think the real issue is the expressiveness of UML (of the way we use UML anyway).  Certain RDFS/OWL idosyncraties are not covered (such as properties as first class citizens).
> In fact, I thin OWL should be canonical representation and UML one possible encoding, not the reverse
>  
> > AFAICT the main issue to narrow down is around property naming and scoping. I think HY_Features is simpler - all property names shoudl be scoped to Application Schema.
>  
> Isn’t what the namespace does ?.   In our case, we duplicate property names in the same package (role) and Association class pattern that generates the same property name at both end of the class
>  
> Ie:  this guy
>  
>  
> GW_UnitVoidProperty is modelled as
>  
> [GW_HydrogeoUnit]  ----gwUnitVoid---- > [GW_UnitVoidProperty] ---- gwUnitVoid --- > [GW_HydrogeoVoid]
>  
> So, gwUnitVoid twice with different domain and ranges,  There are ways (I think) to use restriction to express this.  Or maybe use reification OR singleton pattern instead.
>  
> Thing I eventually want to discuss with you and other Ontology savvy people.
>  
> But now, I’m still in discovery mode
>  
>  
> From: Rob Atkinson [mailto:rob at metalinkage.com.au <mailto:rob at metalinkage.com.au>] 
> Sent: January 22, 2018 20:00
> To: Boisvert2, Eric (NRCan/RNCan) <eric.boisvert2 at canada.ca <mailto:eric.boisvert2 at canada.ca>>; Grellet Sylvain <S.Grellet at brgm.fr <mailto:S.Grellet at brgm.fr>>
> Subject: HY_Features OWL
>  
> Hi
>  
> I hear that GWML folk are planning to do an OWL encoding of GWML
>  
> I have intended to do this for HY_Features using the following process
>  
> UML -> Shapechange -> ISO 19150 flavour UML -> SPIN rules -> Plain Old OWL (POO) -> SPIN rules -> SKOS equivalence
>  
>  
> URI identifiers would be preserved, giving us three OWL/model profiles (ISO, POO and SKOS).
>  
> (Possibly other profiles could be created OWL-DL, OWL-RL etc, RDFS if needed)
>  
> I want POO as the canonical form because I have seen no evidence that ISO1950 libraries are self-consistent and provide useful computability, and no OWL folks are realsitically going to want to work with it.
>  
> There are various reasons to use SKOS equivalence - and I see others doing the same, but as a basic Linked Data interface allowing terms to be resolved it avoids me building a separate one for OWL elements, but also it supports explicit hierarchies that are lost in RDFS/OWL inferencing - what is the actual superclass ?  Anyway I think that is easy and could be just an infrastructure choice.
>  
> All this is easy to contemplate - however when I started to look at the ShapeChange implementation, there is no off-the-shelf set of encoding rules - they have a wide range of inputs and experiments and a grab bag of options. 
>  
> I have a desire/expectation to come up with a fairly standard OGC encoding pattern, based on ISO 19109 application schema and equivalent to ISO19136 GML encoding rules. At the very least i think GWML and HY_Features should have a common pattern.
>  
> I had hoped to switch to this as a task having established a basic Linked data infrastructure at OGC, but my budgetted time has been largely used up and I'm still worrying about cleaning up procesess and structuring data to make things sustainable. 
>  
> AFAICT the main issue to narrow down is around property naming and scoping. I think HY_Features is simpler - all property names shoudl be scoped to Application Schema.
>  
>  
> Finally, I will be looking to use identifiers of the form 
> https://def.opengis.net/def/ <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdef.opengis.net%2Fdef%2F%253cauthority%253e%2F%253capplication&data=02%7C01%7CS.Grellet%40brgm.fr%7C0b16ee03470d47d8186c08d562bc5f9a%7C9610f79254fa49639560a8a822cba6d7%7C1%7C0%7C636523483586756646&sdata=LGjfLxVQNSLD7J%2Fj2x8HNzir2D%2FloVTFOrksTA979fs%3D&reserved=0> <some path>
>  
> where path is consistent with (at least some of) OGC -NA
> /<authority>/<register>[/<sub-register>]*/item
>  
> so perhaps 
> /waterml/hy_hydrofeature/class/HY_Catchment
>  
> so all the issues around naming, case, etc get messy - and we should use the same patterns.
>  
> So, FINALLY, a request if you are looking at GWML, can you include HY_Features in the shapechange processing, and I will do the rules to extract POO and SKOS. 
>  
> I already have a facility in final testing to load RDF file containing rules to an inferencing repository, then load the source file (ISO19150) into the inferencer then put the inferenced result graph into the target repository (OGC knowledge base) where a LD UI will emerge.
>  
> Happy to convene a telconference to discuss/explore 
>  
> Rob
>  
>  
> P Pensez à l'environnement avant d'imprimer ce message
>        Think Environment before printing
>  
> Le contenu de ce mél et de ses pièces jointes est destiné à l'usage exclusif du (des) destinataire(s) désigné(s) comme tel(s). 
> En cas de réception par erreur, le signaler à son expéditeur et ne pas en divulguer le contenu. 
> L'absence de virus a été vérifiée à l'émission, il convient néanmoins de s'assurer de l'absence de contamination à sa réception.
>  
> The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. 
> If you have received this email in error please notify the system manager or  the sender immediately and do not disclose the contents to 
> anyone or make copies. 
> This email was scanned for viruses, vandals and malicious content.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20180129/87b61925/attachment-0001.html>


More information about the GeoSciML mailing list