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

Thanks Maxime

That makes sense to me. The ability to use something other than a single
all-encompassing file is why / not # makes sense for any ontology with a
large number of terms.

I guess there are some issues around versioning of sets of ontologies in
the same namespace?

Also do you have a mechanism in mind for finding the alignment ontologies
for a term?

One approach would be to force the response to include links to all
alignment ontologies (and this requires standardisation of such links!),
another would be to use Linked Data API style views
https://w3id.org/seas/Property?_view=qudt

(with a special view offering the list of views available) _view=alternates

FYI Thats the way I plan to publish the QB4ST datacube specialisations as
ontologies - AFAICT its compatible with what you are doing. I dont see
another alternative other than putting the burden on clients to magically
know the many things they may need to inherit and iteratively importing any
inherited or referenced resources.  Given a resource may not be
dereferencable, and you cant tell, this seems problematic,

Cheers
Rob


On Sat, 24 Sep 2016 at 04:53 Maxime Lefrançois <
maxime.lefrancois.86@gmail.com> wrote:

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