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/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.

   ============
  Dick McCullough
  knowledge := man do identify od existent done
  knowledge haspart proposition list

    ----- Original Message -----
    From: Graham Klyne
    To: Danny Ayers
    Cc: RDF-Interest ; don_raka@hotmail.com
    Sent: Thursday, December 19, 2002 8:51 AM
    Subject: RE: Issue/bug tracking terms in RDFS?



    At 03:52 PM 12/19/02 +0100, Danny Ayers wrote:
    >At the moment I'm not sure whether to aim towards using two or three
    >vocabularies : people (FOAF); projects (tasks); issues (issues/bugs).

    I think it's probably a good thing to use existing vocabs in your
overall
    scheme, where they exist and are defined to serve the purpose in the way
    you want.  Modularization of vocabularies seems like a good thing to me.

    As you say:
    >Bugzilla's userid should be covered by using FOAF, as you have with
    >raisedBy, though internally I wonder if there's a good way of assigning
URIs
    >to users for this. For me this might look something like:
    >http://ideagraph.net/xmlns/users/#nick

    As for assigning URIs, I do that sometimes.  It can be useful to assign
    URIs when you want to mention the same person several times.  Otherwise
a
    blank node can do.  In practice, I find they work pretty much the same.
In
    fact, it's one of the areas I find that RDF data is very much more
    convenient than more prescriptive data formats.

    >btw, earlier on I was contemplating using Bugzilla for the back end and
    >communicating with it using Ideagraph, which would need some RDB/RDF
    >mapping. After looking over the schema  a bit I now reckon it would be
    >easier, (and potentially a lot more useful) to stick to RDF at the
backend
    >(Jena ModelDB?, perhaps using the NetAPI) with the possibility of using
    >Ideagraph at the front and/or a HTML form (from hell) like Bugzilla's.

     From my experience, I'd say that using Jena ModelDB as a back end is a
    good plan.  I believe it would take very little work to link my stuff to
    Jena in this way (I just haven't got round to doing it).

    Something else I haven't properly exploited in my own issue tracking
work
    is use of inference rules. E.g. using Cwm to calculate things that can
be
    deduced, rather than entering the same information in different ways,
which
    is what I do at the moment.  Again, it would be dead easy to do (at
least
    for for some of the duplicated information I've noticed), but I just
    haven't got round to doing that yet.

    #g
    -------------------
    Graham Klyne
    <GK@NineByNine.org>