Hello, Thank you very much for your help, it was very clear and very useful for me.
On 24 April 2016 at 13:05, Dave Reynolds <[email protected]> wrote: > Hi, > > On 22/04/16 12:45, Laurent Rucquoy wrote: > >> Hello, >> >> I want to manage a TDB notably to store observations which use terms >> defined in an external ontology. >> >> This ontology is defined in OWL files available on the following web page: >> https://bioportal.bioontology.org/ontologies/RADLEX?p=summary >> >> Example of OWL file used: >> - 3.13.1 version : >> >> http://data.bioontology.org/ontologies/RADLEX/submissions/36/download?apikey=8b5b7825-538d-40e0-9e9e-5ab9274a9aeb >> - 3.12 version : >> >> http://data.bioontology.org/ontologies/RADLEX/submissions/31/download?apikey=8b5b7825-538d-40e0-9e9e-5ab9274a9aeb >> >> >> What is the best practice to handle the ontology use ? >> >> My idea is to import the OWL file as a named model in my TDB whereas my >> instances are stored in the default model. These instances will be linked >> to the ontology through <ontology_base_uri#RIDxxxx> resources (where >> RIDxxxx is the local id of terms defined in this ontology) >> >> When I will have to reason with the ontology, I will use a 'work' model >> resulting from the union of the ontology named model and the default >> model. >> >> >> My questions: >> >> 1) Is this the right way to reason with imported ontologies (i.e. the >> default model to store the instances, named models used to import >> different >> versions of an ontology and a 'work' model resulting from the union of >> default model and named model) ? >> > > There's no "right" answer here. It'll depend on your work flow and the > sorts of queries you want to make. > > That said I would suggest putting your instance data in a named graph as > well, not in the default model. That leaves you free to set "union default" > so that you can query the union of the instance and ontology data. > > Note that the built-in Jena reasoners are in-memory reasoners only and > reasoning over a TDB model will be slow and not improve scaling. > > 2) How can I handle the different versions of OWL files ? >> >> e.g. in one version of this ontology, the RID31872 term is identified by >> the >> <http://www.owl-ontologies.com/Ontology1447432460.owl#RID31872> uri >> while the same term is identified by the >> <http://www.owl-ontologies.com/Ontology1415135201.owl#RID31872> uri >> > > Ugh, that's completely horrible. I don't see a reasonable way you can > handle that. > > As far as I can see there is no relationship between the different > versions of the term. Just because they happen to have the same localname > is irrelevant, they are different resources. Looking at those files I see > no provision for versioning - there's no unversioned resources, no > versioning links, no mapping terms, nothing. Hopefully that's somewhere and > I'm just missing it. > > Unless you have some separate mapping information that isn't included in > those links then I'm afraid this is a case of "don't start from here". > > Which information will be the more useful to store in my default model to >> be able to link to the corresponding term in the different versions of the >> ontology since the base uri could change from one version to the other >> (while the local part is still the same) ? >> > > As I say, there's just no easy way to handle that. You are dealing with > "ontologies" that have made no provision for versioning. Indeed I would > suggest you are dealing with data that started out not as an ontology and > has just been mapped to OWL syntax. > > To fix that would require deep understanding of what the nature of the > changes are between those different versions. > > Assuming the concepts actually have closely related meanings between the > different versions (a big assumption) then my best advice would be to > create a new URI set with unversioned URI corresponding to each concept in > the union of the ontology versions you are looking at. Use those > unversioned URIs in your instance data. Then create a set of mappings to > map your unversioned resources to the versioned ones. Precisely what > mapping terms to use depends on the detailed semantics involved. > > Dave > >
