Hi Benson,
Given that sketch of the process I don't see any particular advantage in
explicitly importing the ontology into each graph. It would certainly
not be harmful but doesn't seem necessary.
There doesn't seem to be any inference involved (the primary reason to
worry about DL conformance). Process 1 can generate a bare graph,
process 2 can store it and proces 3 can query and visualize the data
without needing the ontology import. If you want to publish the data on
the web as an OWL file then adding an import would be reasonable but can
be done as part of the publication step and doesn't have to be
maintained through the internal chain.
The small reasons to not include the imports during the internal process
chain are:
(1) When you create OntModels over the graphs the ontology will be need
to be loaded in from somewhere and will be included in queries over it
(that's the point of import). This is an overhead and has the potential
to cause problems if the link to the imported ontology breaks.
(2) The whole notion of imports is a document-oriented notion. It sounds
like you do have document-centric processing mode with a separate graph
for each processed source document. However, you may in the future be
merging graphs and ending up with multiple ontology declarations in the
merged graphcs can be unhelpful clutter.
So six of one, half a dozen of the other, YMMV.
FWIW in almost all applications I've developed I've not included
explicit import statements in internal graph stores or procesing chains
but have sometimes inserted them in published output.
Dave
On 09/12/2010 17:57, Benson Margulies wrote:
Dave,
Permit me to take this up one more conceptual level.
So, here at Basis we have a named entity extractor, plus we have been
dabbling in JAPE rules to build some relationship extraction, and we
have a coref system coming on line.
We want to represent the output of these things in RDF, and then do
'interesting' queries in the RDF we come up with, and we eventually
want to extend to querying dbpedia.
I read a few books and tutorials and concluded that it made sense to
work OWL-ishly instead of with naked RDF. I flirted with Proton, but
decided for now to use my own little ontology.
The flow is that one process does all this NLP and derives RDF/OWL,
one graph per source. The second process takes these graphs and wants
to stuff them into a store. And the third will do queries and
visualization. On another thread I'm borrowing Andy's neurons on the
subject of choosing a tuple store.
After reading your messages, my thought is that I need to add the
import into 'process 1', I don't really need any model in 'process 2'
if I'm just pushing RDF/XML from here to there, and that in process 3
the big question is to pick a store.
Can you give me a pointer to read up to conform to OWL/DL, which from
your email seems like it's what I'm stumbling toward doing?
Or do you care to give me a shove in some other direction altogether?
thanks,
benson
