Menu
▾
▴
tm4j-developers
|
From: Jack P. <jac...@th...> - 2002-02-22 03:59:09
|
At 10:28 AM 2/22/2002 +1100, Smith, Tim wrote: >I have been talking to a DAML guy here at work, and he seems to be saying >that DAML and TMs are pretty much the same. >Obviously I am missing something... >Can anyone tell me why TMs are superior to DAML? >Thanks >Tim Smith Tim, I'm sure Kal will have plenty to say about this, but my view is that they are not really the same thing at all. True, they both define graph structures. True, they both deal with the same kinds of objects, mostly ontological entities of one sort or another. But, they serve different purposes. Topic Maps were invented as a means of representating and navigating information resources, while DAML was invented to represent those resources, and do that to a much finer granularity than is easily accomplished with XTM. True, you can define lots of relations and use PSIs to do so. That is to say, one way or the other, you can make XTM serve the same purpose as DAML/OIL, and, while I haven't spent any time trying to do so, I imagine that you can find a way to use DAML as a navigational tool. Nobody is superior to the other, IMHO. Rather, each technology, XTM and DAML have contexts in which one is better suited: representation of a information resource space with XTM, and representation of an ontology within that space with DAML. Cheers Jack |
|
From: Kal A. <ka...@te...> - 2002-02-22 09:09:38
|
At 19:55 21/02/2002 -0800, Jack Park wrote: >At 10:28 AM 2/22/2002 +1100, Smith, Tim wrote: >>I have been talking to a DAML guy here at work, and he seems to be saying >>that DAML and TMs are pretty much the same. >>Obviously I am missing something... >>Can anyone tell me why TMs are superior to DAML? >>Thanks >>Tim Smith > >Tim, > >I'm sure Kal will have plenty to say about this, but my view is that they >are not really the same thing at all. > >True, they both define graph structures. >True, they both deal with the same kinds of objects, mostly ontological >entities of one sort or another. > >But, they serve different purposes. Topic Maps were invented as a means >of representating and navigating information resources, while DAML was >invented to represent those resources, and do that to a much finer >granularity than is easily accomplished with XTM. > >True, you can define lots of relations and use PSIs to do so. That is to >say, one way or the other, you can make XTM serve the same purpose as >DAML/OIL, and, while I haven't spent any time trying to do so, I imagine >that you can find a way to use DAML as a navigational tool. > >Nobody is superior to the other, IMHO. Rather, each technology, XTM and >DAML have contexts in which one is better suited: representation of >a information resource space with XTM, and representation of an ontology >within that space with DAML. > >Cheers >Jack I agree with Jack. And I also think that he has hit the nail on the head with his analysis of the relative "purposes" of the two technologies. It is possible to use Topic Maps to describe minutiae about information resources, and it is possible to use DAML to map conceptual relationships between resources. But in practice, having both tools in your toolbox makes sense. In fact, Jack hasn't left me with much to add ;-) 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 |
|
From: Jack P. <jac...@th...> - 2002-02-22 15:15:40
|
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. Cheers, Jack |
|
From: Kal A. <ka...@te...> - 2002-02-22 23:29:00
|
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 |
|
From: Jack P. <jac...@th...> - 2002-02-23 19:34:14
|
At 03:57 PM 2/22/2002 +0000, Kal Ahmed wrote: >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). Murray Altheim has become an advocate of GXL http://www.gupro.de/GXL/ Cheers Jack |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X