[GeoSciML] HY_Features OWL

Grellet Sylvain S.Grellet at brgm.fr
Wed Jan 31 15:52:52 EST 2018


Thanks Terry.

I'll be a little late (~ 5/10 minutes)

Could you share the link via e-mail ?

Sylvain


________________________________
De : ELFIE <elfie-bounces at lists.opengeospatial.org> de la part de Terry Idol via ELFIE <elfie at lists.opengeospatial.org>
Envoyé : mercredi 31 janvier 2018 18:13:25
À : David Blodgett
Cc : geosciml at lists.opengeospatial.org; elfie; Simon Cox
Objet : Re: [ELFIE] [GeoSciML] FW: HY_Features OWL

There will be a call...I'll start it. All who can join, please do!

Terry Idol, Ph.D.
Innovation Program
Open Geospatial Consortium

Office: 703 407 2643

The OGC: Making Location Count...
www.opengeospatial.org

________________________________
From: "elfie" <elfie at lists.opengeospatial.org>
To: "rob" <rob at metalinkage.com.au>
Cc: geosciml at lists.opengeospatial.org, "elfie" <elfie at lists.opengeospatial.org>, "Simon Cox" <Simon.Cox at csiro.au>
Sent: Wednesday, January 31, 2018 10:43:30 AM
Subject: Re: [ELFIE] [GeoSciML] FW: HY_Features OWL

If there's an ELFIE call, today, please use it to write an outline of the engineering report section based on this discussion. I've not been able to keep up with this but I don't want to lose this thread to email.

- Dave

On Jan 30, 2018, at 2:26 PM, Rob Atkinson via ELFIE <elfie at lists.opengeospatial.org<mailto:elfie at lists.opengeospatial.org>> wrote:

Thanks Sylvain for the document - this is fantastic to have all the concerns laid out systematically,

I note there are a range of different types of issues we should probably separate out from each other:
1) weaknesses in ISO rules
2) choices of options
3) additional constraints in UML and or OCL or tags
4) implementation choices for specific communities
5) meta-model issues.
6) bugs and limitations in software (or things too hard to configure)

The key meta-model issue i see here is the use of a character string (UML option) to hold an IRI in a particular implementation profile - and the trickiness of modelling this as an objectPRoperty or not. Maybe we should just model it as an rdfs:Property, and allow implementation profiles to constrain it to an owl:ObjectProperty ?

I thought that with the revision to ISO19109, properties would be scoped to the application schema by default. This should be controllable in shapechange rules from (vague) memory.

NB the W3C Data Exchange Working Group is looking at the concept of "profiles" - of which a key part is a mechanism to bind external vocabularies to schemas.

The way i look at it:  Profiles are necessary for interoperable data, schemas and APIs are necessary for interoperable software.

RDF-QB is a fairly good way of binding such information to a scheme where the target property has an IRI - so its useful.

It looks like some level of post-processing is necessary to address some issues - which of these can be done with rules vs which require manual inspection and editing? Can the updates be codified as a post-processing data transformation in RDF - so they can be repeated, and used as a template/exemplar for other AppSchema conversions?

Post-processing to extract minimal OWL, RDFS and SKOS models can be automated - but profiling is a matter of recording implementation choice of a community of practice, happy to help with mechanisms for both of these processes.

Rob


On Wed, 31 Jan 2018 at 03:08 Grellet Sylvain via ELFIE <elfie at lists.opengeospatial.org<mailto:elfie at lists.opengeospatial.org>> wrote:

FYI

There is now an OGC repo for GeoSciML. We considered with Eric that what was under the link I pasted below was a relevant starting point.

It is now available under https://github.com/opengeospatial/GeoSciML<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopengeospatial%2FGeoSciML&data=02%7C01%7Cs.grellet%40brgm.fr%7C26de06eac850445407e808d568cdf9b2%7C9610f79254fa49639560a8a822cba6d7%7C1%7C0%7C636530156265873411&sdata=L5MLZKaFHSm4bNzlb%2FaQThu1FpcRWzqM16wQHopBd24%3D&reserved=0>



Sylvain



De : ELFIE [mailto:elfie-bounces at lists.opengeospatial.org<mailto:elfie-bounces at lists.opengeospatial.org>] De la part de Grellet Sylvain via ELFIE
Envoyé : mardi 30 janvier 2018 13:42
À : Boisvert2, Eric (NRCan/RNCan) <eric.boisvert2 at canada.ca<mailto:eric.boisvert2 at canada.ca>>; 'Simon.Cox at csiro.au<mailto:Simon.Cox at csiro.au>' <Simon.Cox at csiro.au<mailto:Simon.Cox at csiro.au>>; jlieberman at tumblingwalls.com<mailto:jlieberman at tumblingwalls.com>

Cc : geosciml at lists.opengeospatial.org<mailto:geosciml at lists.opengeospatial.org>; elfie at lists.opengeospatial.org<mailto:elfie at lists.opengeospatial.org>
Objet : Re: [ELFIE] [GeoSciML] FW: HY_Features OWL



>  “… of the ‘conceptual agreement’ … See Josh’s comments.”

Important discussion we’re having with Eric.

We all know the effort necessary to generate the consensus and ‘reflect’ it in the relevant notation.

Effort often done by a small group of people. Pragmatically/funding speaking I don’t see how we could maintain both UML and OWL when we push or update a standard.



>   “we can probably cope with a sub-optimal automated chain.”

We acknowledge the consistency of the rules defined in ISO-19150-2 and based our conversion exercise on these rules.

But since UML is less expressive than OWL, we believe that a post-prossessing is still necessary to give the resulting ontology some additional flavor, especially by binding them to existing ontologies and taxonomies.

We pushed the summary of our decisions here https://github.com/BRGM/GeoSciMLontology/blob/master/documents/ISO191xx_2_OWL_NoteBRGM.docx<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FBRGM%2FGeoSciMLontology%2Fblob%2Fmaster%2Fdocuments%2FISO191xx_2_OWL_NoteBRGM.docx&data=02%7C01%7Cs.grellet%40brgm.fr%7C927e5713204a4abd9c9708d567dedf84%7C9610f79254fa49639560a8a822cba6d7%7C1%7C1%7C636529129310919981&sdata=SSQPwwlA%2Ft%2BqVExGdU8ee0VCLPR7tfo0jbLHQVFsTqY%3D&reserved=0>

If we could come to an agreement on this, we could reuse it for other OGC domain models.



>  “significant parts of the software development world have moved on to lighter-weight processes”.

Light-weight as in JSON-LD or just JSON with JSON schema ?

jsonld.js lib processor (for example) when dereferencing the URI of a context just expects that it resolves regardless of what type of schema it is using .

I hoped this would help choose the canonical notation. Apparently not :(



Sylvain



De : ELFIE [mailto:elfie-bounces+s.grellet=brgm.fr at lists.opengeospatial.org] De la part de Boisvert2, Eric (NRCan/RNCan) via ELFIE
Envoyé : mardi 30 janvier 2018 02:34
À : 'Simon.Cox at csiro.au<mailto:Simon.Cox at csiro.au>' <Simon.Cox at csiro.au<mailto:Simon.Cox at csiro.au>>; jlieberman at tumblingwalls.com<mailto:jlieberman at tumblingwalls.com>
Cc : geosciml at lists.opengeospatial.org<mailto:geosciml at lists.opengeospatial.org>; elfie at lists.opengeospatial.org<mailto:elfie at lists.opengeospatial.org>
Objet : Re: [ELFIE] [GeoSciML] FW: HY_Features OWL



thanks



From: Simon.Cox at csiro.au<mailto:Simon.Cox at csiro.au> [mailto:Simon.Cox at csiro.au]
Sent: Monday, January 29, 2018 7:24 PM
To: Boisvert2, Eric (NRCan/RNCan); jlieberman at tumblingwalls.com<mailto:jlieberman at tumblingwalls.com>
Cc: rob at metalinkage.com.au<mailto:rob at metalinkage.com.au>; geosciml at lists.opengeospatial.org<mailto:geosciml at lists.opengeospatial.org>; elfie at lists.opengeospatial.org<mailto:elfie at lists.opengeospatial.org>
Subject: RE: [ELFIE] [GeoSciML] FW: HY_Features OWL



… of the ‘conceptual agreement’ … See Josh’s comments.



From: Boisvert2, Eric (NRCan/RNCan) [mailto:eric.boisvert2 at canada.ca]
Sent: Tuesday, 30 January, 2018 09:47
To: 'Joshua Lieberman' <jlieberman at tumblingwalls.com<mailto:jlieberman at tumblingwalls.com>>; Cox, Simon (L&W, Clayton) <Simon.Cox at csiro.au<mailto:Simon.Cox at csiro.au>>
Cc: rob at metalinkage.com.au<mailto:rob at metalinkage.com.au>; geosciml at lists.opengeospatial.org<mailto:geosciml at lists.opengeospatial.org>; elfie at lists.opengeospatial.org<mailto:elfie at lists.opengeospatial.org>
Subject: RE: [ELFIE] [GeoSciML] FW: HY_Features OWL



> The premise here is that UML is canonical (per ISO 19103).



Canonical of what ?  the XML encoding ? (serious question)



From: Joshua Lieberman [mailto:jlieberman at tumblingwalls.com]
Sent: Monday, January 29, 2018 5:38 PM
To: Simon.Cox at csiro.au<mailto:Simon.Cox at csiro.au>
Cc: Boisvert2, Eric (NRCan/RNCan); rob at metalinkage.com.au<mailto:rob at metalinkage.com.au>; geosciml at lists.opengeospatial.org<mailto:geosciml at lists.opengeospatial.org>; elfie at lists.opengeospatial.org<mailto:elfie at lists.opengeospatial.org>
Subject: Re: [ELFIE] [GeoSciML] FW: HY_Features OWL



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<mailto:Simon.Cox at csiro.au>> <Simon.Cox at csiro.au<mailto: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<mailto:eric.boisvert2 at canada.ca>>
Cc: Rob Atkinson <rob at metalinkage.com.au<mailto:rob at metalinkage.com.au>>; Public: A mailing list for GeoSciML <geosciml at lists.opengeospatial.org<mailto:geosciml at lists.opengeospatial.org>>; elfie at lists.opengeospatial.org<mailto:elfie at lists.opengeospatial.org>; Cox, Simon (L&W, Clayton) <Simon.Cox at csiro.au<mailto: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]
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]
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 :)).

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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdenevers%2Fgeoscimlrdf&data=02%7C01%7Cs.grellet%40brgm.fr%7C4db8e41994bb4c725e5508d56781a645%7C9610f79254fa49639560a8a822cba6d7%7C1%7C0%7C636528728933955526&sdata=9mG%2B0ydH18%2FN0eTio1u3jv6YU8ha00D87JnFzSOnhyU%3D&reserved=0>) 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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FBRGM%2FGeoSciMLontology&data=02%7C01%7Cs.grellet%40brgm.fr%7C4db8e41994bb4c725e5508d56781a645%7C9610f79254fa49639560a8a822cba6d7%7C1%7C0%7C636528728933955526&sdata=bab4NSzGdl8tVkks%2BS3YSHyc0ACXiP%2BYr%2BkceBdj21A%3D&reserved=0>)

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 Atkinso


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20180131/1f057ea4/attachment-0001.html>


More information about the GeoSciML mailing list