Hi Cameron,
Please forgive the barrage of responses from me of late. (01)
I want to caution against protocols of this sort. As I see it, there
are really just two (maybe three) operations for a knowledge base (and
maybe some optional parameters) - "ask" and "tell" (maybe "untell" if
you don't want to implement a direct contradiction as retraction). Just
about anything else starts to move portions of the language into the
interface.
Another view might be is that if we really want to get an implemented
OOR, start simple. Allow just CLIF and those three operations. Once
that actually works, create additional features.
Yet another caution - even if we choose a powerful language like CLIF
as the core, if we want to allow translations to and from any other
language, even one with closely equivalent expressiveness, it's
non-trivial. SUO-KIF and TPTP are very close in expressiveness.
Creating an initial version of a translator was not too hard, given that
we'd already spent several years figuring out how to convert SUO-KIF to
syntactically acceptable strict first order. But in practice we found a
number of additional constraints that all theorem provers that
implemented TPTP had assumed. It took two iterations of the yearly CASC
competition to get it right (assuming there isn't something else yet
undiscovered).
Since, as far as I know, no prover natively and completely implements
CLIF at the moment, that would also leave us with a moving target.
There have been so many big (and even well-funded) efforts to create
elaborate languages and protocols that never were completely
implemented. (02)
Adam (03)
On Sat, 2010-09-18 at 09:09 -0400, Cameron Ross wrote:
> Hi,
>
>
> During yesterday's OOR meeting, Immanuel proposed that we design the
> OOR as a collection of disparate web services. There was some
> agreement with this proposal. We also discussed some of the
> challenges with supporting multiple representation languages.
>
>
> Perhaps we could adapt some of the ideas used within the FIPA
> architecture to help achieve these objectives. Specifically, the FIPA
> ACL Message Structure Specification may have some value
> (http://www.fipa.org/specs/fipa00061/SC00061G.html). Basically, FIPA
> ACL messages carry with them meta-data describing the language,
> encoding and ontology associated with the payload. I'm not sure that
> the performatives or the control of conversation aspects make sense
> for OOR, but the meta-data describing the pay load might.
>
>
> Just a thought.
>
>
> Cameron.
> _________________________________________________________________
> Message Archives: http://ontolog.cim3.net/forum/oor-forum/
> Subscribe: mailto:oor-forum-join@xxxxxxxxxxxxxxxx
> Config/Unsubscribe: http://ontolog.cim3.net/mailman/listinfo/oor-forum/
> Shared Files: http://ontolog.cim3.net/file/work/OOR/
> Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OpenOntologyRepository (04)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/oor-forum/
Subscribe: mailto:oor-forum-join@xxxxxxxxxxxxxxxx
Config/Unsubscribe: http://ontolog.cim3.net/mailman/listinfo/oor-forum/
Shared Files: http://ontolog.cim3.net/file/work/OOR/
Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OpenOntologyRepository (05)
|