Hi Miao,
On 15/02/12 16:21, Miao Chen wrote:
I'm developing an ontology about tornado forecast and run into this
problem:
I'd like to use some external ontology classes/properties in my ontology,
such as the "creator" property in the Dubline Core ontology. After some
study, I found there are two ways of using DC's creator property in Jena.
One is to use the createObjectProperty method of the OntModel class, which
will create an object property called "creator" in my ontology by referring
to the DC creator property (http://purl.org/dc/terms/creator). In the
output owl file from Jena, I will see this creator property, but it doesn't
contain the description of this property in the DC ontology. For example,
in the DC ontology the "creator" property has range of "Agent", but the
output owl file (my owl ontology) doesn't import/contain this part of
knowledge.
The second way is to import the whole DC terms ontology in my ontology,
this will import all description of the "creator" property like its range,
but it also imports extra classes/properties in DC that I don't need.
So there's pros and cons for this two ways. Is there any way that I can
just import the description part of the "creator" property in the DC
ontology? Thank you for your help!
The best approach depends on what your goals are. For a start, it
doesn't matter if the *definitions* to the terms you use are part of
your ontology. You can still use, say, dc:creator without having any
triples that state the domain and range of that property are. So, for
example, you can have:
ex:yourOntology
a owl:Ontology;
dc:creator [ foaf:name "Miao Chen" ]
without needing to do anything more. However, if you want to *extend*
classes or properties from an external ontology, then it helps if the
tools that process your ontology can see where the external declarations
come from. So suppose you have:
ex:originator
a owl:ObjectProperty;
rdfs:subPropertyOf dc:creator.
You'd like, say, an inference engine to be able to deduce the
domain/range of ex:originator from the domain/range of dc:creator. In
this case, the general pattern is to declare the external ontology via
an owl:imports statement:
ex:yourOntology
a owl:Ontology;
owl:imports <http://purl.org/dc/elements/1.1/>.
This tells an OWL-aware ontology tool that it may want to load the
definitions from that URL in order to get a complete set of axioms for
the ontology being defined. Jena happens to be such a tool; if you load
an ontology document into an OntModel it will (by default) try to load
the imports. Incidentally, you can switch this behaviour off using the
option methods on the OntDocumentManager.
You can simulate the effect of loading imports via the document manager
by adding sub-models to the OntModel using addSubModel(). An OntModel is
a union of one base model and zero or more sub-models; each loaded
owl:imports URL goes into one of those sub-models. The value of this is
that, for example, the inference engine will see the definitions from
the full set of models and sub-models, but updates to the OntModel will
only take place in the base model. Also, when you serialize the model
using model.write() on an OntModel, by default only the base model gets
written out.
If what you really want to do is to pull out just the sub-graph that
pertains to one resource, such as dc:creator, and assert that into
another model my suggestion is to read the source ontology into one
model, perform a SPARQL describe query on the resource you are
interested in, and then add the results model to the model you are
trying to update.
Hope that helps,
Ian
