Re: Exposure of the modularized SSN ontology as different files: Rob's approach

Dear Rob, all,

I might be a bit tired, I'd like to have more explanations about your use
cases and requirements there.

If you question me about the semantics of the owl:imports axiom, maybe one
good place to look at is https://www.w3.org/TR/owl2-syntax/#Imports
The SEAS modularized ontology I mentioned use this approach extensively:

If you attempt to load https://w3id.org/seas/EvaluationOntology in Protégé,
you will notice that this ontology module imports
https://w3id.org/seas/FeatureOfInterest ,

Protégé also automatically loads the imported ontologies, and their
imported ontologies, ...

This is a OWL feature. not RDF. Only OWL processors will process the
owl:imports axiom. If I use a RDF tool such as Jena to load the Evaluation
ontology, it will by default not load the imported ontologies.

In any case, could you please exemplify what you want to do ?
 is it the case that you want to generate automatically ontology modules
that define qb components according to some dynamically defined ISO Feature
Types ?  I don't really get it.
Could you define a bit more what you mean by "inheritance", and
"specialization may be added at any time" ?

Kind regards,
Maxime

I am currently exploring an approach whereby / based URI references are
> used to access ontologies derived from inheritance relationships of the URI
> term - so that a registry oriented approach can be used for specialised RDF
> Datacube components (and other definitions such as ISO Feature Types) where
> inheritance is required, specialisations may be added at any time as needed
> and no single ontology artefact could be maintained.
>
> I am trying to make sense of the discussions at
> https://www.w3.org/2007/OWL/wiki/Imports
>
> and wondering what is the actual minimal requirement for a response
> document to be imported.
>
> my (probably naive) understanding is that RDF does not directly support or
> impose any import mechanism - therefore we just need all the statements to
> be consistent with a domain of use - which being global simply means any
> two documents generated by such a mechanism cannot contain statements
> inconsistent with each other.
>
> AFAICT the same holds true for owl - but do we actually need something
> specific for owl:imports to be supported?
>
> Cheers
> Rob Atkinson
>
> On Sat, 24 Sep 2016 at 02:04 Maxime Lefrançois <
> maxime.lefrancois.86@gmail.com> wrote:
>
>> Dear Armin, all,
>>
>> This mail is to confirm that I would be glad to show a demo about how one
>> may expose modularized ontologies all having the same slash-based
>> namespace, along with alignments to other ontologies.
>>
>> This could be during one of the next telecon, I believe it would be
>> around October 4th.
>>
>> Following this demo, I believe it would be good to discuss about which
>> should be the URIs of each module, and which of the modules should be given
>> the namespace URI (and hence be the "default" one, available at the
>> namespace URI).
>>
>> Kind regards,
>> Maxime Lefrançois
>>
>>
>>
>>
>>