RE: KR & Issue/bug tracking terms in RDFS?

KR/KE can interoperate in many ways. 

 

It is unfortunate that you have chosen to use the name "KR" for your
particular language, since it flies against the common usage of "KR" (to
mean "knowledge representation") and makes communication burdensome.  I
will use "KR" to mean "knowledge representation" in this e-mail.

 

RDF is an XML syntax for KR.  It is designed specifically to allow
different KR systems to exchange knowledge representations, and with low
cost of interop.  This list is populated by people who are interested in
exchanging KRs using RDF.  This is just an FYI in case you were
wondering why people discuss RDF and KR interop.

 

(Suprisingly enough, there are many KR systems available which can use
RDF to exchange knowledge representations.  Considering that your
software has no RDF interface, and is not involved in exchanging
knowledge representations with other KR systems, I am more than a bit
puzzled by the sheer volume of e-mails extolling the virtues of your
system which you find fit to send to the list.)

 

 

  _____  

From: Richard H. McCullough [mailto:rhm@cdepot.net] 
Sent: Thursday, December 19, 2002 3:52 PM
To: Danny Ayers
Cc: RDF-Interest

KR/KE can interoperate in many ways. 

 

I currently support Linux & Windows versions of KE.  

You have all the facilities of those OSes at your disposal.  

All of the external files are plain ASCII files, including KR's
"relational databases".

KE can easily be ported to many other systems, just by building Unicon
on the other systems.

 

A Java version of KR/KE is feasible, 

since there is a Jcon variant of the Unicon language that I used to
implement KE.  

However, a Java version is very low on my priority list. 

 

An XML interface is higher on my priority list, but I haven't done
anything yet.

 

P.S. Unicon is a high-level language developed by Clint Jeffery and
supported at Sourceforge.net.

Unicon is an extension of the Icon language developed by Ralph Griswold
and supported at University of Arizona.
============ 
Dick McCullough 
knowledge <http://rhm.cdepot.net/>  := man do identify od existent done
knowledge haspart proposition list

----- Original Message ----- 

From: Danny Ayers <mailto:danny666@virgilio.it>  

To: Richard H. McCullough <mailto:rhm@cdepot.net>  

Cc: RDF-Interest <mailto:www-rdf-interest@w3.org>  

Sent: Thursday, December 19, 2002 2:33 PM

Subject: RE: KR & Issue/bug tracking terms in RDFS?

 > You seem hesitant to use regular DB software. 

 

Not hesitant, I simply think that this is a case where RDF offers
advantages over e.g. using a relational DB system. An RDB or object DB
or whatever might offer similar potential in terms of modelling, and an
XML DB might also offer some potential for interoperability with other
languages, but RDF allows the modelling plus major interop potential.
The fact that the rest of my app uses RDF is also a consideration (!),
but not an overriding one - I'm planning on using an RDB for text search
stuff, where I think performance might be an issue if I went through
RDF.

 

 > You might try using KR/KE, at least for prototype development.

 

Is there a Java API? I could add an interface ;-)

 

 > KR tuples are a single line of text, with semicolon-separated fields.

 >  Each relation has a KR script (or a Unicon procedure) to define the
meaning of its tuples.

 >  Queries of the resulting knowledge base use KR's "form-based"
questions.

 

 > I have personally used KR for:

  >    my family genealogy knowledge base of over 1000 persons

   >   my expense records & summaries

 > The relation definitions for both of these applications are included
on my web site.

 <http://www.volcano.net/~rhm/knowledge/application/Genealogy>  >
http://www.volcano.net/~rhm/knowledge/application/Genealogy

 <http://www.volcano.net/~rhm/knowledge/application/ExpenseRecord>  >
http://www.volcano.net/~rhm/knowledge/application/ExpenseRecord 

 

 It certainly looks a versatile system, and it's obvious a lot of
thought & effort has gone into it. But for me to use KR & your apps, it
would have to be possible to easily exchange data or otherwise
interoperate with it using the (data  & programming) languages in
widespread use, and/or offer really significant advantages over other
systems. Anything with a Java, Python or Perl API and/or an XML
serialization has a head start over everything else in terms of
adoption, irrespective of any other merits.

 

Cheers,

Danny.