Re: Exposure of the modularized SSN ontology as different files: explanation

Dear Rob,

if you have any details to share in advance I'd be keen to see
>

Ok so more details (might not need a demo after that):
my demo involves the knowledge model we have been developing for European
project ITEA 2 SEAS https://itea3.org/project/seas.html

Say I have namespace https://w3id.org/seas/ , with preferred prefix seas

The "default" ontology has URI https://w3id.org/seas/ .
This default ontology imports the latest versions of all the ontology
modules, among other modules seas:FeatureOfInterestOntology
<https://w3id.org/seas/FeatureOfInterestOntology>, and
seas:EvaluationOntology <https://w3id.org/seas/EvaluationOntology>

They define different resources, for instance:
 - module seas:FeatureOfInterestOntology defines seas:Property
 - module seas:EvaluationOntology defines seas:hasSpatialContext
<https://w3id.org/seas/hasSpatialContext>

Finally, there is a module with URI seas:SSNAlignment that defines
alignments between module seas:FeatureOfInterestOntology and the SSN
ontology.
This ontology imports both the seas:FeatureOfInterestOntology, and the SSN
ontology.

Hence, all of the resources have the same namespace, but I mentioned 4
different files:
 - https://w3id.org/seas/
 - https://w3id.org/seas/FeatureOfInterestOntology
 - https://w3id.org/seas/EvaluationOntology
 - https://w3id.org/seas/SSNAlignment

and two resources that redirect to the module that defines them when they
are accessed:
 - https://w3id.org/seas/Property 303 redirects to
https://w3id.org/seas/FeatureOfInterestOntology
 - https://w3id.org/seas/hasSpatialContext 303 redirects to
https://w3id.org/seas/EvaluationOntology

An that's it. No big deal. All of my recent ontologies are exposed using
this approach:
https://w3id.org/seas/
https://w3id.org/rdfp/
https://w3id.org/pep/
https://w3id.org/lindt/

They all use the same tool I developed:
https://w3id.org/ontop/

I'd be happy that the new SSN ontology be the first W3C ontology to use
this exposition approach.

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
>>
>>
>>
>>
>>