Re: Can Ontobase be used with OWL?

[lenya...@gmail.com]

Thank you Len,

These are my main short term goals:

1) Use Ontobase API to connect to the DB and get the DB schema. In
particular, I would like to access the objects/methods containing the
information of the integrity contraints, starting with foreign keys. I
see some getKey method calls, but you may have another method to do
this.

2) Instead of creating frames with slots, I would like to create
classes and properties using OWLAPI (and a .owl file). This could be
done extending your classes that create frames or creating new ones.

Later on, I will use Ontobase to interact with the DB to create
instances. I really like how you do the lazy instantiation. I would
like to do something similar but using OWL API to create owl
instances. But I will worry only about 1) and 2) now. Also, I have
decided to have a first standalone protototype before integrating it
with a P4 plugin. A graphical interface is not a priority now.

I tried to explore using RDF/OWL files instead of the experimental XML
files that you use in the Ontobase Demo, but I had many exceptions and
no instances were created, so I suspect everything has been designed
to create frames and slots.

Your hints and recomendations will be appreciated. Thanks again,

Natalia


On Apr 4, 10:13 pm, lenyabl...@gmail.com wrote:
> Ontobase is using Protege facets which is only supported in frame
> version (I don't know about P4)
> But facets are only used for database binding so ontology can be
> separated (lifted) from grounding and exported into any format.
>
> The limitations are that initial import must be done using frame
> format (can be XML or DB, but not OWL) and when you export to OWL
> grounding is going to be gone. This is also why you don't see any
> database information attached to any instance (except as name).

[lenya...@gmail.com]

On Apr 4, 10:18 pm, lenyabl...@gmail.com wrote:

> On Apr 4, 10:15 pm, lenyabl...@gmail.com wrote:
>
> > Thank you Len,
>
> > These are my main short term goals:
>
> > 1) Use Ontobase API to connect to the DB and get the DB schema. In
> > particular, I would like to access the objects/methods containing the
> > information of the integrity contraints, starting with foreign keys. I
> > see some getKey method calls, but you may have another method to do
> > this.
>

> All information about DB is stored in class own slots :ARGS, :INIT
> and :SIGN and in template slots facets $ARGS, $INIT, $SING and $OBO.
> Technically speaking you don't need Ontobase API becasue all these can
> be access using Protege API. The main issue for you is to understand
> what is where - not how to access it, but that requires detailed API
> document explaining it. I can give you all the source code for methods
> like getKey(), getGround() etc, but none of them simply returns
> database constraints (as you can see they return classes and slots
> from Ontobase grounding ontology. If you simply need DB schema - you
> can use adpater classes directly, which have much simpler API defined
> by Metadata class (I can document that quickly).
>

OK. Just to make sure I understand, does it mean that in order to
interact with the DB (execute more queries) I have to go through the
facet?
I will loose the connection after exporting to OWL as you mention.

>
>
> > 2) Instead of creating frames with slots, I would like to create
> > classes and properties using OWLAPI (and a .owl file). This could be
> > done extending your classes that create frames or creating new ones.
>

> All information about DB is stored in class own slots :ARGS, :INIT
> and :SIGN and in template slots facets $ARGS, $INIT, $SING and $OBO.
> Technically speaking you don't need Ontobase API becasue all these can
> be access using Protege API. The main issue for you is to understand
> what is where - not how to access it, but that requires detailed API
> document explaining it. I can give you all the source code for methods
> like getKey(), getGround() etc, but none of them simply returns
> database constraints (as you can see they return classes and slots
> from Ontobase grounding ontology. If you simply need DB schema - you
> can use adpater classes directly, which have much simpler API defined
> by Metadata class (I can document that quickly).
>

Then the execution of queries is through Protege 3 API using the
adapter and metadata classes that you mention?

> > Later on, I will use Ontobase to interact with the DB to create
> > instances. I really like how you do the lazy instantiation. I would
> > like to do something similar but using OWL API to create owl
> > instances.  But I will worry only about 1) and 2) now. Also, I have
> > decided to have a first standalone protototype before integrating it
> > with a P4 plugin. A graphical interface is not a priority now.
>

> The main function of Ontobase is to maintain data binding froim DB to
> frame format. The only reason to use Ontobase for creating OWL classes
> is to wrap frame class inside as I explained.
>

I see. I guess that my options would be : i) to use Ontobase as you
suggest to keep the binding with the DB and then a wrapper to bind
with OWL classes, or ii) to rewrite the code -using the lessons
learned with Ontobase-?
For i) I believe there is already a wrapper to go from Frames to OWL.

>
>
> > I tried to explore using RDF/OWL files instead of the experimental XML
> > files that you use in the Ontobase Demo, but I had many exceptions and
> > no instances were created, so I suspect everything has been designed
> > to create frames and slots.
>
> > Your hints and recomendations will be appreciated. Thanks again,
>
> > Natalia
>
> > On Apr 4, 10:13 pm, lenyabl...@gmail.com wrote:
>
> > > Ontobase is using Protege facets which is only supported in frame
> > > version (I don't know about P4)
> > > But facets are only used for database binding so ontology can be
> > > separated (lifted) from grounding and exported into any format.
>
> > > The limitations are that initial import must be done using frame
> > > format (can be XML or DB, but not OWL) and when you export to OWL
> > > grounding is going to be gone. This is also why you don't see any

> > > database information attached to any instance (except as name).- Hide quoted text -
>
> > - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

[lenya...@gmail.com]

Correct. You can maintain two ontologies (frame and OWL) in synch, but
that is not trivial.

>
> > > 2) Instead of creating frames with slots, I would like to create
> > > classes and properties using OWLAPI (and a .owl file). This could be
> > > done extending your classes that create frames or creating new ones.
>
> > All information about DB is stored in class own slots :ARGS, :INIT
> > and :SIGN and in template slots facets $ARGS, $INIT, $SING and $OBO.
> > Technically speaking you don't need Ontobase API becasue all these can
> > be access using Protege API. The main issue for you is to understand
> > what is where - not how to access it, but that requires detailed API
> > document explaining it. I can give you all the source code for methods
> > like getKey(), getGround() etc, but none of them simply returns
> > database constraints (as you can see they return classes and slots
> > from Ontobase grounding ontology. If you simply need DB schema - you
> > can use adpater classes directly, which have much simpler API defined
> > by Metadata class (I can document that quickly).
>
> Then the execution of queries is through Protege 3 API using the
> adapter and metadata classes that you mention?

More specificaly - generation of query is based on information stored
in facets, but that does not require adapters (adapters do not depend
in any way on Protege API)

>
> > > Later on, I will use Ontobase to interact with the DB to create
> > > instances. I really like how you do the lazy instantiation. I would
> > > like to do something similar but using OWL API to create owl
> > > instances.  But I will worry only about 1) and 2) now. Also, I have
> > > decided to have a first standalone protototype before integrating it
> > > with a P4 plugin. A graphical interface is not a priority now.
>
> > The main function of Ontobase is to maintain data binding froim DB to
> > frame format. The only reason to use Ontobase for creating OWL classes
> > is to wrap frame class inside as I explained.
>
> I see. I guess that my options would be : i) to use Ontobase as you
> suggest to keep the binding with the DB and then a wrapper to bind
> with OWL classes, or ii) to rewrite the code -using the lessons
> learned with Ontobase-?
>  For i) I believe there is already a wrapper to go from Frames to OWL.
>

If you go with ii) - there is much more than lesson that you can re-
use, but it is still a lot of work.
If you go with i) - the question would be how to serialize wrapped
classes for storage and transport.

>
> > > I tried to explore using RDF/OWL files instead of the experimental XML
> > > files that you use in the Ontobase Demo, but I had many exceptions and
> > > no instances were created, so I suspect everything has been designed
> > > to create frames and slots.
>
> > > Your hints and recomendations will be appreciated. Thanks again,

What would prototype do?

[lenya...@gmail.com]

Create OWL classes, properties -datatype and object- using 3 different
sets of rules (which are similar to reverse engineering) to compare
them. E.g. in one of them relations are represented by object
properties, while in the other, they are represented as classes.
Instantiate the resulting ontologies through SQL queries to the DB -
which could be in a lazy fashion, but in this case only the instances
needed for answering a DL query -.

[lenya...@gmail.com]

It seems that the easiest way would be to generate instances in frame
format (loading data) and export to OWL for DL query.

Ontobase implements both types of relations. You can see in tutorial
that first type is implemented by @GROUND and second (reified
relations) by =SERVICE classes. Ontobase also generates ground level
directed bynary relations under :RELATION

[lenya...@gmail.com]

>As I explained new OWL classes will not have database binding required to load data from DB. I can publish another simple API allowing >you to extend class/instance factory methods (if needed) in order to wrap frame class inside OWL class, but only OWL class will be >saved in OWL format. It may be possible to use Protege project include to link OWL and frame project, but I doubt it.

If I extend the Ontobase class/instance factory methods to create OWL
classes and properties, I could generate the queries mentioned in my
previous comment, once I have the java objects representing the
classes and properties, I could use OWL API in order to create the
corresponding owl objects and use the several serialization methods to
create the owl file , without any binding. E.g. I could generate the
whole ontology using the queries.
I may be misunderstanding something, if the information is stored in
the class and I have a wrapper to store it also in the owl class and
send it to the Ontobase API, could I still execute the queries?

> > > > > All information about DB is stored in class own slots :ARGS, :INIT
> > > > > and :SIGN and in template slots facets $ARGS, $INIT, $SING and $OBO.
> > > > > Technically speaking you don't need Ontobase API becasue all these can
> > > > > be access using Protege API. The main issue for you is to understand
> > > > > what is where - not how to access it, but that requires detailed API
> > > > > document explaining it. I can give you all the source code for methods
> > > > > like getKey(), getGround() etc, but none of them simply returns
> > > > > database constraints (as you can see they return classes and slots
> > > > > from Ontobase grounding ontology. If you simply need DB schema - you
> > > > > can use adpater classes directly, which have much simpler API defined
> > > > > by Metadata class (I can document that quickly).
>
> > > > Then the execution of queries is through Protege 3 API using the
> > > > adapter and metadata classes that you mention?
>
> > > More specificaly - generation of query is based on information stored
> > > in facets, but that does not require adapters (adapters do not depend
> > > in any way on Protege API)

So, the generation of queries do not depend in any way on Progete API,
for option ii) this could be one of the main things to reuse via
Ontobase API, am I right? (considering a scenario where I only use
Ontobase API and nothing else -e.g.no Protege- to generate DB
queries.

>
> > > > > > Later on, I will use Ontobase to interact with the DB to create
> > > > > > instances. I really like how you do the lazy instantiation. I would
> > > > > > like to do something similar but using OWL API to create owl
> > > > > > instances.  But I will worry only about 1) and 2) now. Also, I have
> > > > > > decided to have a first standalone protototype before integrating it
> > > > > > with a P4 plugin. A graphical interface is not a priority now.
>
> > > > > The main function of Ontobase is to maintain data binding froim DB to
> > > > > frame format. The only reason to use Ontobase for creating OWL classes
> > > > > is to wrap frame class inside as I explained.
>
> > > > I see. I guess that my options would be : i) to use Ontobase as you
> > > > suggest to keep the binding with the DB and then a wrapper to bind
> > > > with OWL classes, or ii) to rewrite the code -using the lessons
> > > > learned with Ontobase-?
> > > >  For i) I believe there is already a wrapper to go from Frames to OWL.
>
> > > If you go with ii) - there is much more than lesson that you can re-
> > > use, but it is still a lot of work.
> > > If you go with i) - the question would be how to serialize wrapped
> > > classes for storage and transport.
>

Could you please elaborate more in what are the parts that I could
reuse and the parts that are independent of Protege API? I think I
don't have that part very clear.

[lenya...@gmail.com]

OK, you can re-use the main data binding logic (including query
generation and data loading). But you would have to remove all frame
API dependencies from it.Meaning that you have to replace facets and
own slots(as explained above) as carriers of binding information.
Basically all methods like getKey(), getGrounding() will need to be re-
implemented for OWL.
I can split the frame-dependant implementations and put it under
public interface consisting of all the methods like getKey(),
getGrounding() etc. Then you can write OWL implementation.This will
require a lot of testing because splitting public API is quite
intrusive change

[lenya...@gmail.com]

On Apr 5, 10:53 am, lenyabl...@gmail.com wrote:
> OK, you can re-use the main data binding logic (including query
> generation and data loading). But you would have to remove all frame
> API dependencies from it.Meaning that you have to replace facets and
> own slots(as explained above) as carriers of binding information.
> Basically all methods like getKey(), getGrounding() will need to be re-
> implemented for OWL.
> I can split the frame-dependant implementations and put it under
> public interface consisting of all the methods like getKey(),
> getGrounding() etc. Then you can write OWL implementation.This will
> require a lot of testing because splitting public API is quite
> intrusive change
>

Assuming I could save the information needed to (de)serialize the
information to create the frames and send it to ontobase, I would be
able to change how the mappings are generated, right? (e.g. if
currently the sql queries generate a slot (or relation) and I want to
generate frames (or class), would this be possible by extending the
current API?

I think I have a better understanding now. The easier way to do it is
i), however, I will need to keep somehow the frames since these are
required to the SQL and I still need to modify the generation of the
grounding classes.
If I go with ii) is way much work not only for the reimplementation
but also for the current Ontobase API changes required. In this case,
I also need to modify the generation of the grounding classes.



> > > > > > > > Natalia
>

[lenya...@gmail.com]

On Apr 5, 8:24 pm, lenyabl...@gmail.com wrote:
> On Apr 5, 10:53 am, lenyabl...@gmail.com wrote:> OK, you can re-use the main data binding logic (including query
> > generation and data loading). But you would have to remove all frame
> > API dependencies from it.Meaning that you have to replace facets and
> > own slots(as explained above) as carriers of binding information.
> > Basically all methods like getKey(), getGrounding() will need to be re-
> > implemented for OWL.
> > I can split the frame-dependant implementations and put it under
> > public interface consisting of all the methods like getKey(),
> > getGrounding() etc. Then you can write OWL implementation.This will
> > require a lot of testing because splitting public API is quite
> > intrusive change
>
> Assuming I could save the information needed to (de)serialize the
> information to create the frames and send it to ontobase, I would be
> able to change how the mappings are generated, right? (e.g. if
> currently the sql queries generate a slot (or relation) and I want to
> generate frames (or class), would this be possible by extending the
> current API?
>

This is a main question! I will try to give detailed and clear answer.

Ontobase generates all possible logically consistent mappings from DB
to grounding ontology (this is why initial import and analysis takes
more time if you have more constraints). Later when you guide it via
decision tree new (=service) classes are generated to represent
particular data flow. These are mapped by means of the same facets to
initial (@ground) classes. Therefore there is NO DIRECT MAPPING
=SERVICE to DB (the idea was to make services purely logical units
independent from data serialization mechanism).

So to answer your question: yes you can map =service classes to
@ground classes any way you choose. For example you can map one-to-one
=service to @ground - that will represent every DB relation as
instance slot. Or you can map one =service to a join of several
@ground classes - that will reify DB relation into a sub-class of
DIRECTED-BINARY-RELATION with name concatenating names of joined
tables. But doing mapping manually is a lot of work, much like
creating logical DB model. Decision tree supposed to simplify this
process - it is essentially a simple form of logic programming. And
you can get reasoning support from Protege to automate mapping. Also
Ontobase has a built-in Prolog reasoner with separate API.

[Natalia]

Hello,
I found this paper useful to have a general idea of the differences
and similarities between Frames and OWL.
http://protege.stanford.edu/conference/2006/submissions/abstracts/7.2_Wang_Hai_Protege_conf.pdf

A few more questions:

On Apr 5, 9:12 pm, lenyabl...@gmail.com wrote:
> On Apr 5, 8:24 pm, lenyabl...@gmail.com wrote:
>
> > On Apr 5, 10:53 am, lenyabl...@gmail.com wrote:> OK, you can re-use the main data binding logic (including query
> > > generation and data loading). But you would have to remove all frame
> > > API dependencies from it.Meaning that you have to replace facets and
> > > own slots(as explained above) as carriers of binding information.
> > > Basically all methods like getKey(), getGrounding() will need to be re-
> > > implemented for OWL.
> > > I can split the frame-dependant implementations and put it under
> > > public interface consisting of all the methods like getKey(),
> > > getGrounding() etc. Then you can write OWL implementation.This will
> > > require a lot of testing because splitting public API is quite
> > > intrusive change

Would it be possible to have a look to one of those methods codes to
have an idea of how they are implemented?
It would be great if I could have access to the object that holds the
DB information between creating the Frames.

>
> > Assuming I could save the information needed to (de)serialize the
> > information to create the frames and send it to ontobase, I would be
> > able to change how the mappings are generated, right? (e.g. if
> > currently the sql queries generate a slot (or relation) and I want to
> > generate frames (or class), would this be possible by extending the
> > current API?
>
> This is a main question! I will try to give detailed and clear answer.
>
> Ontobase generates all possible logically consistent mappings from DB
> to grounding ontology (this is why initial import and analysis takes
> more time if you have more constraints).

Would it be very hard to abstract the classes that have the rules to
create these consistent mappings in order to create new
implementations for those?

Later when you guide it via
> decision tree new (=service) classes are generated to represent
> particular data flow. These are mapped by means of the same facets to
> initial (@ground) classes. Therefore there is NO DIRECT MAPPING
> =SERVICE to DB (the idea was to make services purely logical units
> independent from data serialization mechanism).
>


> So to answer your question: yes you can map =service classes to
> @ground classes any way you choose. For example you can map one-to-one
> =service to @ground - that will represent every DB relation as
> instance slot. Or you can map one =service to a join of several
> @ground classes -  that will reify DB relation into a sub-class of
> DIRECTED-BINARY-RELATION  with name concatenating names of joined
> tables. But doing mapping manually is a lot of work, much like
> creating logical DB model. Decision tree supposed to simplify this
> process - it is essentially a simple form of logic programming. And
> you can get reasoning support from Protege to automate mapping. Also
> Ontobase has a built-in Prolog reasoner with separate API.

I assume you use Prolog to generate the mappings. My idea is not to
generate the mappings directly, but instead I would like to implement
different set of rules to generate these mappings. For this purpose,
the class where you generate those mappings would be a kind of
"abstract class" for which inner classes that instantiate them can be
created.

Does this make sense?

[Len Yabloko]

On Tue, Apr 7, 2009 at 2:05 PM, Natalia <citl...@gmail.com> wrote:

Hello,
I found this paper useful to have a general idea of the differences
and similarities between Frames and OWL.
http://protege.stanford.edu/conference/2006/submissions/abstracts/7.2_Wang_Hai_Protege_conf.pdf

A few more questions:

On Apr 5, 9:12 pm, lenyabl...@gmail.com wrote:
> On Apr 5, 8:24 pm, lenyabl...@gmail.com wrote:
>
> > On Apr 5, 10:53 am, lenyabl...@gmail.com wrote:> OK, you can re-use the main data binding logic (including query
> > > generation and data loading). But you would have to remove all frame
> > > API dependencies from it.Meaning that you have to replace facets and
> > > own slots(as explained above) as carriers of binding information.
> > > Basically all methods like getKey(), getGrounding() will need to be re-
> > > implemented for OWL.
> > > I can split the frame-dependant implementations and put it under
> > > public interface consisting of all the methods like getKey(),
> > > getGrounding() etc. Then you can write OWL implementation.This will
> > > require a lot of testing because splitting public API is quite
> > > intrusive change

Would it be possible to have a look to one of those methods codes to
have an idea of how they are implemented?

 

Sure, here are all facet-based methods (META_SIGN, META_ARGS,..are facets):

 

Cls getAbsoluteGround(Cls parent) {

if (parent == null)

throw new IllegalArgumentException("null class");

if (parent.isClsMetaCls() || parent.isAbstract())

throw new IllegalArgumentException(parent.getName()+ " is abstract!");

String sign = (String)parent.getOwnSlotValue(

META_SIGN);

while (sign != null && !parent.isMetaCls() && !parent.isAbstract()

&& parent.hasType(

META_TYPE) && !parent.hasDirectSuperclass(DATABASE)) {// exit if absolute @ground class

Cls cls =

KB.getCls(sign);

if (cls == null || cls.isMetaCls())

break;

else

parent = cls;

sign = (String)parent.getOwnSlotValue(

META_SIGN);

}

return parent;

}

public Cls getGroundKey(Cls parent) {

return getKey(getGround(parent));

}

public Cls getAbsoluteGroundKey(Cls parent) {

return getKey(getAbsoluteGround(parent));

}

public Cls getAbsoluteKeyGround(Cls cls) {

return getGround(getAbsoluteGroundKey(cls));

}

public Cls getGround(Cls cls) {

if (cls == null)

throw new IllegalArgumentException("null class");

if (cls.isMetaCls() || cls.isAbstract() ||

cls.equals(

SUPER_RELATION) || cls.hasSuperclass(SUPER_DATABASE)) // don't use hasDirectSuperclass(DATABASE) here !

return cls;

String sign = (String)cls.getOwnSlotValue(

META_SIGN);

if (sign == null || sign.length()==0)

throw new IllegalArgumentException(cls.getName()+" not grounded! ");

Cls ground =

KB.getCls(sign);

if (ground == null)

throw new IllegalArgumentException(cls.getName()+" has invalid grounding: "+sign);

return ground;

}

 

public

Cls getKey(Cls cls, Slot slot) { // always use ARGS here (never SIGN !!!)

if (cls == null)

throw new IllegalArgumentException("null class");

if (!cls.hasTemplateSlot(slot))

throw new IllegalArgumentException(cls.getName()+ " has no slot "+slot.getName());

String args = (String)cls.getTemplateFacetValue(slot,

ARGS);

if (args == null || args.length()==0) {

return getKey(getGround(cls));

}

Cls key =

KB.getCls(args);

if (key == null || !key.hasSuperclass(SUPER_KEY))

throw new IllegalArgumentException(cls.getName()+" slot "+slot.getName()+" is illegal key "+args);

return key;

}

public Cls getKey(Cls cls) {

if (cls == null)

throw new IllegalArgumentException("null class");

if (cls.isAbstract() || cls.isClsMetaCls() || !cls.hasType(META_TYPE))

throw new IllegalArgumentException(cls.getName()+ " is abstract or extraneous!");

String args = (String)cls.getOwnSlotValue(

META_ARGS);

if (args == null || args.length()==0) {

if (cls.hasSuperclass(SUPER_DATABASE))

throw new IllegalArgumentException("Database object " + cls.getName()+ " has no key");

return getKey(getGround(cls));

}

Cls key =

KB.getCls(args);

//if (key == null || !key.hasSuperclass(SUPER_KEY) )

// throw new IllegalArgumentException(cls.getName()+" has illegal key: "+args);

return key;

}

public Cls getAbsoluteKey(Cls root) {

Cls parent =

null;

String args = (String) root.getOwnSlotValue(Navigator.

META_ARGS);

if (args != null && args.length()>0) {

parent =

KB.getCls(args);

if (parent != null && parent.hasSuperclass(Navigator.SUPER_DATABASE)) {

args = (String)parent.getOwnSlotValue(Navigator.

META_ARGS);

if (args == null)

throw new IllegalStateException("Missing key: "+parent.getName());

parent =

KB.getCls(args);

}

}

return parent;

}

You can see that all they do is fetching facet values

 

 

It would be great if I could have access to the object that holds the
DB information between creating the Frames.

 

 

Diagrams are the objects holding DB information used to create frames. All diagrams are saved and loaded every time you select corresponding frame class. You can find all of them in user.dir with *.PL extension (digrams are implemented with Prolog dialect)

 

>
> > Assuming I could save the information needed to (de)serialize the
> > information to create the frames and send it to ontobase, I would be
> > able to change how the mappings are generated, right? (e.g. if
> > currently the sql queries generate a slot (or relation) and I want to
> > generate frames (or class), would this be possible by extending the
> > current API?
>
> This is a main question! I will try to give detailed and clear answer.
>
> Ontobase generates all possible logically consistent mappings from DB
> to grounding ontology (this is why initial import and analysis takes
> more time if you have more constraints).

Would it be very hard to abstract the classes that have the rules to
create these consistent mappings in order to create new
implementations for those?

 

Abstracting is not a problem, but rules are coded in the implementation. So there is no explicit declaration of rules. It was planning to implement all rules as Prolog theories, but ended up doing it in Java. If you are comfortable with Prolog , then it should not be difficult to do it since diagrams extracted from DB in that format. Another option to use JDBC directly and bypass diagrams alltogether. 

Later when you guide it via
> decision tree new (=service) classes are generated to represent
> particular data flow. These are mapped by means of the same facets to
> initial (@ground) classes. Therefore there is NO DIRECT MAPPING
> =SERVICE to DB (the idea was to make services purely logical units
> independent from data serialization mechanism).
>


> So to answer your question: yes you can map =service classes to
> @ground classes any way you choose. For example you can map one-to-one
> =service to @ground - that will represent every DB relation as
> instance slot. Or you can map one =service to a join of several
> @ground classes -  that will reify DB relation into a sub-class of
> DIRECTED-BINARY-RELATION  with name concatenating names of joined
> tables. But doing mapping manually is a lot of work, much like
> creating logical DB model. Decision tree supposed to simplify this
> process - it is essentially a simple form of logic programming. And
> you can get reasoning support from Protege to automate mapping. Also
> Ontobase has a built-in Prolog reasoner with separate API.

I assume you use Prolog to generate the mappings. My idea is not to
generate the mappings directly, but instead I would like to implement
different set of rules to generate these mappings. For this purpose,
the class where you generate those mappings would be a kind of
"abstract class" for which inner classes that instantiate them can be
created.

 

Yes, I though about it. Prolog would be ideal way to implement plug-in algorithms for mapping. I have also considered Alloy (another logic programming langauge). Java can also be used, but it is not ideall for this purpose. In any case I will think about some way to expose mapping algorithm hooks (most likely using diagrams)  

Does this make sense?

 

Absolutely.

[Natalia Villanueva Rosales]

Hello,

Yes.
 

 

 

It would be great if I could have access to the object that holds the
DB information between creating the Frames.

 

 

Diagrams are the objects holding DB information used to create frames. All diagrams are saved and loaded every time you select corresponding frame class. You can find all of them in user.dir with *.PL extension (digrams are implemented with Prolog dialect)

I see them. These files should be the same ones to generate the visual representation included with the plugin, since I see edges. I guess that dre_nodes are used to  generate the frames.

 

>
> > Assuming I could save the information needed to (de)serialize the
> > information to create the frames and send it to ontobase, I would be
> > able to change how the mappings are generated, right? (e.g. if
> > currently the sql queries generate a slot (or relation) and I want to
> > generate frames (or class), would this be possible by extending the
> > current API?
>
> This is a main question! I will try to give detailed and clear answer.
>
> Ontobase generates all possible logically consistent mappings from DB
> to grounding ontology (this is why initial import and analysis takes
> more time if you have more constraints).

Would it be very hard to abstract the classes that have the rules to
create these consistent mappings in order to create new
implementations for those?

 

Abstracting is not a problem, but rules are coded in the implementation. So there is no explicit declaration of rules. It was planning to implement all rules as Prolog theories, but ended up doing it in Java. If you are comfortable with Prolog , then it should not be difficult to do it since diagrams extracted from DB in that format. Another option to use JDBC directly and bypass diagrams alltogether. 

My idea so far was to represent these mappings as SWRL (horn-like) rules which is more standard. It would be very similar to the prolog theories you talk about.
 

My only concern would be the time involved in the modifications for i) create an OWL model instead of frames and ii) the modification needed to represent the rules for mapping in order to change them easily.

Thank you for the information, those are my questions so far. it is now more clear to me the work involved to extend Ontobase for this particular goal.

[Len Yabloko]

Hello,

Yes, you can open each file directly from ontobase plug-in (buttons at top right) and dre_n odes are used as interim representation of DB schema used to generate frames.

 

>
> > Assuming I could save the information needed to (de)serialize the
> > information to create the frames and send it to ontobase, I would be
> > able to change how the mappings are generated, right? (e.g. if
> > currently the sql queries generate a slot (or relation) and I want to
> > generate frames (or class), would this be possible by extending the
> > current API?
>
> This is a main question! I will try to give detailed and clear answer.
>
> Ontobase generates all possible logically consistent mappings from DB
> to grounding ontology (this is why initial import and analysis takes
> more time if you have more constraints).

Would it be very hard to abstract the classes that have the rules to
create these consistent mappings in order to create new
implementations for those?

 

Abstracting is not a problem, but rules are coded in the implementation. So there is no explicit declaration of rules. It was planning to implement all rules as Prolog theories, but ended up doing it in Java. If you are comfortable with Prolog , then it should not be difficult to do it since diagrams extracted from DB in that format. Another option to use JDBC directly and bypass diagrams alltogether. 

My idea so far was to represent these mappings as SWRL (horn-like) rules which is more standard. It would be very similar to the prolog theories you talk about.
 

I am not sure that SWRL has sufficient expressive power for representing and reasoning about relational DB. There may be mismatch between types of logic (horn vs relational). I think Prolog is a good logical bridge from DB to Semantic Web because of support for CWA (aka negation as failure). Generaly it is not trivial task to bridge three different logical frameworks DB<--->graphical model<--->DL (it can take entire PhD thesis :-)

I think from the research prospective mapping from one logic to another is much more interesting (my understanding is that this would be generalization of your thesis of mapping between different ontologies). But it is also much more challenging as far as I can see. And besides - doing i) would still require some mapping rules to be implemented. So ii) seems to be more efficient approach in a long run. Frankly I would be interested in exploring theoretical side of the challange before even commiting to any appraoch.  

 

Thank you for the information, those are my questions so far. it is now more clear to me the work involved to extend Ontobase for this particular goal.

 

Let me know if I can help.