Hi, On Mon, 2011-08-29 at 14:20 +0200, Mario Kofler wrote:
> >> NOTE: For the real implementation in my case it is necessary to keep > >> the two ontologies seperate due to performance reasons. > > > > Are you sure about that? > > > > If there is a performance problem it will be in the reasoning not the > > storage and if you are joining the information back together again for > > reasoning then nothing will have been saved by separating the storage. > > Please try to explain, I think I do not get the message. Of course I > believe the > performance problem lies in the reasoning on the ontologies. That is the > reason > why i keep them in two seperate TDB stores, so that i can start > reasoning just on > one part at a time. Reasoning over two halves of an ontology separately will not give the same results as reasoning over the union. If at some point you want to end up with inference results as over the union (which is what I understood) then there's no performance advantage from the separation. Note also that you should not be reasoning directly over a TDB model. The inference engines available in Jena are all memory based so there's no scaling advantage, and a large performance hit, to reasoning directly over TDB/SDB. Instead load your data into a memory model and reason over that. > >> Therefore, I need to programmatically assure the fact that the > >> NeapolitanPizza from TDB store A is the same as NeapolitanPizza from > >> TDB store B, meaning it just states some extra information about the > >> same individual. > >> > >> Does anyone have a suggestion about how to solve this programmatically > >> in Java code? > > > > First, please define what you mean by the two NeopolitanPizzas being the > > "same individual". > > > > If the URIs are the same then they are the same individual, QED. > > > > If the URIs are different then what are your criteria for identity? > > The URIs are different, as stated above, however my criteria of identity is > the > unqualified name of the individual (without namespace). I could unify > the URI just > by storing the individual with the same namespace into both > ontologies. However then > I would end up with one of the two ontologies containing individuals > with different > namespaces: > > for ex. > OntologyA: URI of Individual A: NSA+IndividualA > OntologyA: URI of Individual B: NSB+IndividualB > > IndividualA is an Individual that has the native namespace of OntologyA and > IndividualB is an Individual that has the Namespace of OntologyB > because this Individual > also exists in OntologyB but with different relations and information. Sure. There's no requirement that a given ontology only mention URIs which correspond to its default namespace. A single OWL or RDF graph can contain data crossing many namespaces quite freely. I'm confused about whether you are being given ontologies which talk about different individuals which you want to merge or whether you are in fact generating these partitioned ontologies yourself just for management/performance reasons. > > I don't understand what you trying to achieve but it would seem easier > > to create a merged model into which you load the selected and mapped > > triples from each source. > > Do I get this right, that this merged model then would contain only > individuals and concepts > that occur in both ontological representations and need to be mapped? I wasn't thinking that but since I don't understand what problem you are trying to solve it is hard to be clearer. My interpretation was that you had two ontologies which talk about the same concept but using different URIs and you wanted to map those concepts together so you could query the resulting union. I would do that by constructing the union (not intersection) as a separate third model. There is then a choice of how to represent the mapped concepts in the merged model. Among the options are: (a) Pick one the source URIs as definitive, use that in the merged model, map statements about the other alias URI as you do the merge. (b) Create a new URI for the merged concept and map statements about both the source URIs to the new merged concept. (c) Keep both source URIs in the merged model and use owl:sameAs assertions to represent the mapping. Dave
