- From: Maxime Lefrançois <maxime.lefrancois.86@gmail.com>
- Date: Fri, 23 Sep 2016 19:45:04 +0000
- To: Rob Atkinson <rob@metalinkage.com.au>, Armin Haller <armin.haller@anu.edu.au>, SDW WG Public List <public-sdw-wg@w3.org>
- Message-ID: <CALsPASVriM4XETq_Lk-MgvoeKFAgN3aejs_59dHW4YYbfxqaDg@mail.gmail.com>
> > I guess there are some issues around versioning of sets of ontologies in > the same namespace? > Not at all ;-) for the spec about versioning, see https://www.w3.org/TR/owl2-syntax/#Versioning_of_OWL_2_Ontologies Versioning goes very well along with this approach. The SEAS modules are all versioned. SEAS module https://w3id.org/seas/ArchitectureOntology has two versions: version 0.9 has URI https://w3id.org/seas/ArchitectureOntology-0.9 . It is accessible there. version 2.0 has URI https://w3id.org/seas/ArchitectureOntology-2.0 . It is accessible there, and at the URI of the SEAS module, because it is the latest version. Each defined term redirects to the latest module version where it is defined. For example, seas:EndNode redirects to https://w3id.org/seas/ArchitectureOntology-0.9 , because it has been deleted in version 2.0. On the other hand, seas:CoreEntity redirects to https://w3id.org/seas/ArchitectureOntology-2.0. An ontology version should use axiom owl:priorVersion to refer to the previous ontology version URI. (although I did not use this in SEAS for now, my mistake) Also do you have a mechanism in mind for finding the alignment ontologies > for a term? > This is an interesting question, we should discuss about this in a separate thread. > One approach would be to force the response to include links to all > alignment ontologies (and this requires standardisation of such links!), > what about the alignments that some other organization would have made ? would you force yourself to include links to those also ? I know no way to automatically know the list of ontologies that refer to a specific term. > another would be to use Linked Data API style views > https://w3id.org/seas/Property?_view=qudt > I do not know about this approach... > > (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 > That's interesting, but not that URI https://w3id.org/seas/Property?_view=qudt is a different URI than https://w3id.org/seas/Property. There may be some implications. > - 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 > I agree. and iteratively importing any inherited or referenced resources. Given a > resource may not be dereferencable, and you cant tell, this seems > problematic, > Well, tools such as Protégé just trigger an error in those cases. Your fault to import an ontology that cannot be accessed... Kind regards, Maxime > > 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 >>>> >>>> >>>> >>>> >>>>
Received on Friday, 23 September 2016 19:45:46 UTC