the "Argument" interface

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

the "Argument" interface

Hrishikesh Sharma
Hi,
       I wanted to know a bit about this interface. Essentially the PropertyInfo, IndividualInfo etc. classes implement this interface, and the signature of method getPredicate() in the corresponding javadoc says
public Argument getPredicate()

Now the following line in my code gives compilation error
IndividualInfo pred = nProp.getPredicate();
where variable nProp is earlier defined of type PropertyInfo. Predicate I thought should be an individual anyway. I am not able to find how to use in code the Java methods whose return type is declared to be an interface. Please help. Even otherwise, what does interface "Argument" encapsulate?
 
Sincerely,
         Hrishikesh.

_______________________________________________
protege-owl mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-owl

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03 
Reply | Threaded
Open this post in threaded view
|

Re: the "Argument" interface

Martin O'Connor

getPredicate returns an Argument, not its implementing class IndividualInfo so standard Java assignment rules will not allow you to do what you want to do here. A property predicate can be either an IndividualInfo or a LiteralInfo based on whether the property is an object or datatype property.

 

Strictly speaking, getSubject and getPredicate should return more specific Info types, not Argument types. Arguments should really only be used in built-in method implementations [1]. I will take a look at updating the code. However, you should still be able to use the Argument objects and process them based on the relevant Info type that is returned.

 

Martin

 

[1] http://protege.cim3.net/cgi-bin/wiki.pl?SWRLBuiltInBridge

 


From: [hidden email] [mailto:[hidden email]] On Behalf Of Hrishikesh Sharma
Sent: Wednesday, July 25, 2007 7:24 AM
To: [hidden email]
Subject: [protege-owl] the "Argument" interface

 

Hi,

       I wanted to know a bit about this interface. Essentially the PropertyInfo, IndividualInfo etc. classes implement this interface, and the signature of method getPredicate() in the corresponding javadoc says

public Argument getPredicate()

Now the following line in my code gives compilation error
IndividualInfo pred = nProp.getPredicate();
where variable nProp is earlier defined of type PropertyInfo. Predicate I thought should be an individual anyway. I am not able to find how to use in code the Java methods whose return type is declared to be an interface. Please help. Even otherwise, what does interface "Argument" encapsulate?
 

Sincerely,

         Hrishikesh.


_______________________________________________
protege-owl mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-owl

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03 
Reply | Threaded
Open this post in threaded view
|

Protege software for back-end

JMiller

We have used the Protege GUI in the recent past, but currently we are predominantly using other tools to support our applications.  I have stayed with the Protege-OWL users mail list 1) because we will likely start using Protege again, and 2) for helpful hints on OWL, etc.

I am curious whether the Protege software is appropriate for use without the GUI front-end.  I am reading about features that we could make use of (rules processing, DB back-end, etc.).  However, since we are not presently using the Protege GUI, I wonder if the libraries would still be suitable for non-GUI, server-side processing?

Jim

_______________________________________________
protege-owl mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-owl

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03 
Reply | Threaded
Open this post in threaded view
|

Re: Protege software for back-end

Thomas Russ

On Jul 25, 2007, at 8:07 PM, James A Miller wrote:

>
> We have used the Protege GUI in the recent past, but currently we  
> are predominantly using other tools to support our applications.  I  
> have stayed with the Protege-OWL users mail list 1) because we will  
> likely start using Protege again, and 2) for helpful hints on OWL,  
> etc.
>
> I am curious whether the Protege software is appropriate for use  
> without the GUI front-end.  I am reading about features that we  
> could make use of (rules processing, DB back-end, etc.).  However,  
> since we are not presently using the Protege GUI, I wonder if the  
> libraries would still be suitable for non-GUI, server-side processing?

They are quite suitable for that.

In one of our projects, we built a Java application that uses  
additional semantic information in an OWL ontology to augment answers  
retrieved from a database system.  The OWL information is managed by  
using Protege-OWL to handle the OWL ontology without bringing up the  
GUI.  It just using the Programming API to load the ontology and then  
query it for semantic information.

_______________________________________________
protege-owl mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-owl

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03 
Reply | Threaded
Open this post in threaded view
|

Re: Protege software for back-end

JMiller

[hidden email] wrote on 07/26/2007 11:53:01 AM:

>
> On Jul 25, 2007, at 8:07 PM, James A Miller wrote:
>
> >
> > We have used the Protege GUI in the recent past, but currently we  
> > are predominantly using other tools to support our applications.  I  
> > have stayed with the Protege-OWL users mail list 1) because we will  
> > likely start using Protege again, and 2) for helpful hints on OWL,  
> > etc.
> >
> > I am curious whether the Protege software is appropriate for use  
> > without the GUI front-end.  I am reading about features that we  
> > could make use of (rules processing, DB back-end, etc.).  However,  
> > since we are not presently using the Protege GUI, I wonder if the  
> > libraries would still be suitable for non-GUI, server-side processing?
>
> They are quite suitable for that.
>
> In one of our projects, we built a Java application that uses  
> additional semantic information in an OWL ontology to augment answers  
> retrieved from a database system.  The OWL information is managed by  
> using Protege-OWL to handle the OWL ontology without bringing up the  
> GUI.  It just using the Programming API to load the ontology and then  
> query it for semantic information.
>


Interesting...  By using the Protege API, what dependencies does that imply?  Jena?  DIG reasoners?  In-memory vs persisted ontologies?  Others?

> _______________________________________________
> protege-owl mailing list
> [hidden email]
> https://mailman.stanford.edu/mailman/listinfo/protege-owl
>
> Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.
> html#01a.03

_______________________________________________
protege-owl mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-owl

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03 
Reply | Threaded
Open this post in threaded view
|

Re: Protege software for back-end

Thomas Russ

On Jul 26, 2007, at 3:30 PM, James A Miller wrote:

>
> [hidden email] wrote on 07/26/2007  
> 11:53:01 AM:
>
> >
> > On Jul 25, 2007, at 8:07 PM, James A Miller wrote:
> >
> > >
> > > We have used the Protege GUI in the recent past, but currently we
> > > are predominantly using other tools to support our  
> applications.  I
> > > have stayed with the Protege-OWL users mail list 1) because we  
> will
> > > likely start using Protege again, and 2) for helpful hints on OWL,
> > > etc.
> > >
> > > I am curious whether the Protege software is appropriate for use
> > > without the GUI front-end.  I am reading about features that we
> > > could make use of (rules processing, DB back-end, etc.).  However,
> > > since we are not presently using the Protege GUI, I wonder if the
> > > libraries would still be suitable for non-GUI, server-side  
> processing?
> >
> > They are quite suitable for that.
> >
> > In one of our projects, we built a Java application that uses
> > additional semantic information in an OWL ontology to augment  
> answers
> > retrieved from a database system.  The OWL information is managed by
> > using Protege-OWL to handle the OWL ontology without bringing up the
> > GUI.  It just using the Programming API to load the ontology and  
> then
> > query it for semantic information.
> >
>
> Interesting...  By using the Protege API, what dependencies does  
> that imply?

In our case, just the main Protege, since this didn't involve OWL.

>  Jena?  DIG reasoners?

For that particular project, we were using the Protege Frames  
language rather than OWL, so Jena and DIG weren't issues.

On the other hand, it did mean that we had to implement our own  
(fairly simple) reasoning code rather than using such external  
reasoners.

If we were to do this in OWL, it would imply Jena dependence, as well  
as the protegex and OWL code.  DIG would only be an issue if we chose  
to use a classifier for either classes or individuals at run time.  
Instead, we did this virtually, partly so as not to clutter up the  
query-answering system, partly because we were dealing mostly with  
string data, and partly because some of the reasoning was based on  
statistical inference and thus would need special handling anyway.  
Dont' get excited about the latter part.  It hasn't been built out  
much at all.

>  In-memory vs persisted ontologies?  Others?

We used an in-memory use of the ontology, because it wasn't being  
changed.  It was just used to interpret and expand on information  
present in a database, which was changing.

>
>
> > _______________________________________________
> > protege-owl mailing list
> > [hidden email]
> > https://mailman.stanford.edu/mailman/listinfo/protege-owl
> >
> > Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.
> > html#01a.03
> _______________________________________________
> protege-owl mailing list
> [hidden email]
> https://mailman.stanford.edu/mailman/listinfo/protege-owl
>
> Instructions for unsubscribing: http://protege.stanford.edu/doc/ 
> faq.html#01a.03

_______________________________________________
protege-owl mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-owl

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03 
Reply | Threaded
Open this post in threaded view
|

Re: Protege software for back-end

Martin O'Connor
In reply to this post by JMiller

There is currently no standard OWL Java API so you are going to be dependant to some extent on whatever API you chose. (Hopefully, the OWLAPI from Manchester – which is being used by Protégé 4 - will change this situation.)  DIG is not a dependency per se – it is an open standard that many reasoners support, and the presence of DIG does not preclude direct reasoner API interactions. Pretty much all OWL tools will persist OWL ontologies in a standard way.

 

All major functionality in Protégé-OWL is accessible at the API level – and these APIs are quite stable (and have to be because they are used by plugin developers). For example, all of the SWRLTab’s functionality can be embedded in Java applications without using any of the GUI components.

 

Martin

 


From: [hidden email] [mailto:[hidden email]] On Behalf Of James A Miller
Sent: Thursday, July 26, 2007 3:31 PM
To: User support for the Protege-OWL editor
Cc: User support for the Protege-OWL editor; [hidden email]
Subject: Re: [protege-owl] Protege software for back-end

 


[hidden email] wrote on 07/26/2007 11:53:01 AM:

>
> On Jul 25, 2007, at 8:07 PM, James A Miller wrote:
>
> >
> > We have used the Protege GUI in the recent past, but currently we  
> > are predominantly using other tools to support our applications.  I  
> > have stayed with the Protege-OWL users mail list 1) because we will  
> > likely start using Protege again, and 2) for helpful hints on OWL,  
> > etc.
> >
> > I am curious whether the Protege software is appropriate for use  
> > without the GUI front-end.  I am reading about features that we  
> > could make use of (rules processing, DB back-end, etc.).  However,  
> > since we are not presently using the Protege GUI, I wonder if the  
> > libraries would still be suitable for non-GUI, server-side processing?
>
> They are quite suitable for that.
>
> In one of our projects, we built a Java application that uses  
> additional semantic information in an OWL ontology to augment answers  
> retrieved from a database system.  The OWL information is managed by  
> using Protege-OWL to handle the OWL ontology without bringing up the  
> GUI.  It just using the Programming API to load the ontology and then  
> query it for semantic information.
>


Interesting...  By using the Protege API, what dependencies does that imply?  Jena?  DIG reasoners?  In-memory vs persisted ontologies?  Others?

> _______________________________________________
> protege-owl mailing list
> [hidden email]
> https://mailman.stanford.edu/mailman/listinfo/protege-owl
>
> Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.
> html#01a.03


_______________________________________________
protege-owl mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-owl

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03