OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

topicmaps-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [topicmaps-comment] RE: OASIS vs W3C



On 25/09/2001 13:58:16 Lars Marius Garshol wrote:

>As for the original question: what RDF and topic maps do better than
>each other, I can only agree that the answer to this is less clear
>than it ought to be. I trying to work this out for myself, but so far
>a major part of the problem has been that I don't know what anyone
>would use RDF for. (I'm not saying it's useless, just that I am not
>very clueful about practical applications of it.)

Well, I'm not an RDF expert either, but I was chatting to a couple recently, so let me pass on a couple of things they pointed out.  One interesting thing about RDF is that any XML document is also an RDF document.  For example, even without any RDF annotations, an RDF parser will report an element with child elements as being an RDF container.  So they have some worthwhile default relationships.  Now, the default information alone is actually not so useful by itself, but you can then use as many RDF annotations as you need to make the RDF information for the document sufficiently useful.

This is the side of RDF that competes with SOAP, not topic maps.  This is to do with parcels of information encoded as XML, parcels that are more-or-less equivalent to serialised objects.  I expect SOAP to win in that arena, but that is another discussion.

Once you have these bundles of information, the next question is how you create useful links between them.  This is the area where I see topic maps, RDF, and XLink playing.  They could compete or they could interoperate, depending on how things develop.  The choice between them may not be easy, because you don't always start from a position of knowing exactly what functionality you will need in the future.  Unless the different choices integrate well, you may have to make an early choice about whether to go with the simplest and least extensible solution or instead the most flexible but most resource-intensive solution.  Alternatively, you may just procrastinate about that choice for as long as it takes to get a firmer idea.

What kinds of business questions will arise here?  Well, how easy is it with one of these solutions to express a particular kind of relationship between two things?  How easy is it to store/retrieve/process/query/maintain that information?  Are some solutions so low level that it is too easy to invalidly encode the relationships?  In general, how do you validate your encoding of the relationships?  How much ambiguity is there is the expression of the relationships?  How easy is it to compare and/or merge relationship information from different sources?  How complex can the relationships be?  Are simple relationships simple to set up, or is there a high barrier to entry?  How much do the available tools reduce (or increase) the complexity of the task?  How well do the available tools integrate with legacy data sources?  Which paradigms are simplest for non-technical staff to grasp?  Those are just some of the ones that come to mind.

Anyway, back to RDF, I can see someone who is interested in object serialisation plus a bit of linking being attracted to RDF initially.  I can see someone who is interested in linking lost of simple (reasonably unstructured) bits of information being attracted to topic maps initially.  I suspect there must be a useful middle ground, though I won't suggest I know what it is as yet.

     Cheers,
          Tony.
========
Anthony B. Coates
(1) Content Distribution Architect - Project Gazelle
(2) Leader of XML Architecture & Design - Chief Technology Office
Reuters Plc, London.
Tony.Coates@reuters.com
========



-----------------------------------------------------------------
        Visit our Internet site at http://www.reuters.com

Any views expressed in this message are those of  the  individual
sender,  except  where  the sender specifically states them to be
the views of Reuters Ltd.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC