You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Laurent Rucquoy <la...@telemis.com> on 2016/04/22 13:45:33 UTC
Imported ontology handling
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) ?
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
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) ?
Thank you in advance for your help.
Sincerely,
Laurent
Re: Imported ontology handling
Posted by Laurent Rucquoy <la...@telemis.com>.
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 <da...@gmail.com> 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
>
>
Re: Imported ontology handling
Posted by Dave Reynolds <da...@gmail.com>.
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