Hi ol3j,
TopBraid currently does not have an interactive graphical mapping
editor like the one on your first screenshot. This is one of the
things I always planned to do but never really had time to finish. As
described in my blog, the diagram view can visualize SPARQL-based
mappings (using spin:query) in class diagrams, but there is no way to
define new mappings this way.
SPIN has various mechanisms though to make the definition of such
mappings as easy as possible though. In particular you can define a
library of SPIN templates for typical patterns. Then you would just
need to instantiate those templates (which can actually be done nicely
with the Graph view of TBC).
Holger
On Aug 12, 2009, at 1:11 AM, ol3j wrote:
So, I can merge two files with different ontology by use import tab
and export/merge OWL/RDF files. I would like to know that is any
possibility alignment ontology in TopBraid using GUI for example
(http://webhome.cs.uvic.ca/~seanf/images/cogz_screenshot.png). I know
that I can use SPARQL for example
http://composing-the-semantic-web.blogspot.com/2006/09/ontology-mapping-with-sparql-construct.html(could
you fix images, I don't see).
Thanks
ol3j
On 6 Lip, 18:30, Dean Allemang <[email protected]> wrote:
Obrst, Leo J. wrote:
Perhaps then you already have the capabilities that e-connections
or comparable notions are intended to provide? Basically it is
both a way to logically partition a given ontology into sub-
domains and also a way to have mappings among ontologies which are
much finer-grained than imports, and not just reduced to ordinary
OWL equivalence assertions (sameAs, etc.)
There are a couple of such notions floating around: e-connections,
Distributed Description Logic (DDL), etc. For example, [1].
Thanks,
Leo
In principle, owl:imports can be as fine-grained as you like; you
could
have a bunch of named graphs with a single triple apiece. That's in
principle, but in practice it doesn't deviate that much. If you
have a
tool that make managing multiple named graphs / OWL files easy, you
can
split your ontology into a large number of pieces, and manage them
with
owl:imports. We have been doing this successfully for year.
Back the
the Protege days, managing a dozen such modules was an onus. We
typically manage several dozen nowadays, and occasionally in the
hundreds, without undue stress on project management.
Furthermore, within SPARLQMotion, you can define (with a SPARQL
CONSTRUCT) just what part of an ontology you are really interested
in,
and pass that on to the next SM module. This has the advantage of
keeping within standards as closely as possible (eg, SPARQL doing all
the heavy lifting for defining sets of triples), while providing
capabilities of the sort you are describing.
But of course, Holger's comment about extra plugins is the real
answer -
even if I am correct that with SM and our multiple ontology
management
infrastructure, we can support many of the same requirements, you
might
still want to support e-connections etc.
Dean
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "TopBraid Composer Users" group.
To post to this group, send email to
[email protected]To unsubscribe from this group, send email to
[email protected]For more options, visit this group at
http://groups.google.com/group/topbraid-composer-users?hl=en-~----------~----~----~----~------~----~------~--~---
