Re: [Tm4j-developers] how are we different to DAML

[Kal A. <ka...@te...>]

At 07:13 22/02/2002 -0800, Jack Park wrote:
>At 09:08 AM 2/22/2002 +0000, Kal Ahmed wrote:
>>I would say one thing - ignore the markup argument. IMHO, the principle 
>>part of DAML is the specification of the primitives with which one can 
>>construct a rigorously defined ontology. The less significant part of 
>>DAML is its representation as RDF. In fact, if I were wanting to 
>>represent an ontology with a high degree of formal rigor (e.g. for later 
>>applying inference tools to the data set), then I would probably look at 
>>using DAML+OIL as an adjunct to the XTM map of the instance data. I could 
>>then use transformation tools (XSLT ?) to generate an XTM representation 
>>of the DAML+OIL ontology definition, while still using DAML+OIL tools to 
>>define my ontology and XTM tools to map it to real world resources.
>>
>>Cheers,
>>
>>Kal
>
>To which, I would like to point out that this is precisely the direction 
>that Nexist is headed!  In the long run, I want Nexist to be based on open 
>standards.  If you want a topic map from it, you get it in XTM.  If you 
>want an ontology, you get that in DAML/OIL.
>
>There exists, however, an open question: is there some canonical way to 
>represent everything in the database such that it can come out any way you 
>want it?  The idea being that you apply some transcoding scheme (i.e. 
>XSLT) to some canonical "document" (Douglas Engelbart calls this an 
>"iFile") to get the representation you want.

Off the top of my head I would suggest a graph model. Just labelled nodes 
and arcs (maybe with some "type" label too) That should be representable in 
XML so it should be possible to apply XSLT - of course, thats not to say 
that the mapping will be easy, but labelled nodes and arcs is probably the 
lowest common denominator (or should that be highest common factor ?)

A graph model also has the advantage of being relatively easy to represent 
in a relational db (though it would probably be more efficient to use an OO 
database, given the amount of traversal you would be doing).

Cheers,

Kal