[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Topic Maps and RDF
Hi Kent, Kent said: Could someone across this area explain how Topic Maps and RDF fit together, if at all? Didier reply: This is something we try to resolve since one year ;-). Here is what we discovered. a) topics are links (links governed by the Hytime architecture). We learned that these links can easily be mapped to xlink:type="extended" links. So far, so good. b) RDF descriptions are, simply said, records about a resource. An RDF record can also be perceived as a property collection or as a property set (not to be confounded by SGML property sets). c) both xlink and rdf behave like an architecture (I said, behave like). We can have our own tags and include the "architecture" attributes in it, so that, theoretically (or practically in the case of an SGML processor) an Xlink or RDF processor can recognize and process the elements as xlink or rdf elements. So far, so good. The example below is a folder object. This object is a topic, as such, it contains occurrences or links. It would obviously be useful to have more than just links but also information about the resource pointed by the link doesn't it? For example, to tell you who is the author, in which language is this resource written, and so on and so forth. So, in such ways that, in addition to include the object's location we also have some more information about the object and that this information is "at the right place" or contained near the "location" reference. This is the principle of locality, which, as we all know, augment the readability of the content. (have ever used a listing where you have to move back and forth between the beginning of the document and the end of it. particularly when the document has more than 50 pages? Remember how funny it was :-)). So, the example below is XMLized and uses name spaces. Why? simply because we talked about name spaces this week :-). No, just kidding, it also helps the interpreter to retrieve its eggs. Example: -------- <tm:topic scope="public"> <tm:topname> <tm:basename>Name spaces</tm:basename> <tm:dispname>Name spaces</tm:dispname> </tm:topname> <tm:occurs xlink:type="extended"> <tm:loc xlink:type="locator" rdf:about="http://mydomain.com/HotTopic/name_space.htm" xlink:href="http://mydomain.com/HotTopic/name_space.htm"> <tns:name>Name_space</tns:name> <tns:creator>code runner, bip bip!</tns:creator> <tns:date>today</tns:date> </tns:item> </tm:occurs> </tns:folder> Let's explain a bit what it is, and the actual limits of merging this "poutine" (for those who do not know what this is, it a strange mixture of French fries and cheese :-). a) the master element is the tm:topic element. When I said that the topic element is a link, I should have said instead "contains an extended link" when we adapt the topic map element to the XML world. Thus, the scope attribute is a topic attribute. An XML parser can now provide to a topic map interpreter the tm:topic element and this latter to recognize that this is a topic. Because the XML world does not have any architectural form recommendation, a W3C compliant parser cannot make the right substitution, so, the interpreter then needs a clear way to know that this is a topic. Thus, we have to help this poor guy by being explicit and tell it that this is a topic element (if we want it to do its job). So far, so good. We discovered that architectural form cannot be applied when we deal with XML parser which never heard about this feature (I have been told by a good friend of mine these XML parsers consider Architectural form as snobbish, but this is between you and me and do not repeat this to "SP" he does not feel well these days :-)) b) We then have a name element which contains as sub elements several flavors of naming. Enough to make Ben and Jerry jealous :-) c) This is followed by the occurs element, itself the real stuff: the link (with a background music of "Also spreach Zaratoustra"). It is a one to many link. I.e. a link pointing to multiple resources. Here come the xlink "extended" kind of link and this latter contains locations. Again, to help our friend, the topic map interpreter, we used a keyword which is part of the tm vocabulary (tm:occurs). Now the topic map parser knows that this is a topic occurrence set. The topic map intepreter expect to retreive location element as content. Some sophisticated interpreter may do the following process 1 - transform what the parser gave into an internal structure or use the structure provided by the parser (i.e. the DOM) 2 - Then, have different "element handler" recognize what an element is. So, in our case, the tm:occurs, help our friend (the topic map interpreter) to recognize here a topic map occurs element and then will expect locations to be contained in it. The element could also ge given as food to the xlink interpreter. The "xlink:type" attribute is a keyword recognized by the xlink interpreter and thus indicates to this latter that this is a one to many kind of link and that this latter will contain one or more locators. Thus, both the topic map and xlink interpreters have expectations about what's should be coming next. 3 - Then, we encounter a loc element. Hummm, we have some guys here that have expectations about what this element should be. The xlink interpreter is anxiously waiting for a "locator", the topic map interpreter for a "location", this latter may simply decide that linkage is after all a matter to be treated by the xlink interpreter and will simply let this later do the job. These two guys already satisfied, give as food, the element to other interpreters, just in case... Bang! (a big gong sound) the rdf interpreter recognizes the "rdf:about" attribute and prepare itself to build a property set for the resource identified by the "about" value. The rdf interpreter expects properties to be contained in this element. Finally, the "xlink:href" attribute is what the xlink interpreter expected: a resource reference. The xlink interpreter can do something with it like store it, or information about the kind of behavior we expect from it if some more attributes are included in the locator element. But wait a minute here! we have two times the same value (a) for the rdf:about attribute and (b) for the xlink:href attribute. Hummm, I guess these guys will go to meet the judge to know how to resolve this dispute about the resource location. One of these guys say that to be an rdf description "about" this resource, you need to provide the resource URI as a value. And the other party repeat that to be able to resolve the link, it needs the URI too. And I have been convened to be part of the jury. Both have a good story to tell. Hummm hard to decide. And here I am, sitting on my jury chair, trying to figure out why these two guys do not talk each other and could share the same resource pointer. So here we are, yes we have all the intuition that these two world could be merged and that it make sense that these two world be merged, but when you are seated on a jury's chair, things are not so easy. Have a good day (And please do not tell to SP what the other parsers think about architectural form, I heard that he feels lonely these days since all his SGML friends moved to XML, be kind to him :-)) Note: All resemblance between characters and real persons is pure coincidence and the producers may not be held as responsible for such resemblance :-)) PS: I am writing about this topic and issues and will try to do my jury's job as well as possible. Didier PH Martin ---------------------------------------------- Email: martind@n... Next conference: Web New York (http://www.mfweb.com) Book to come soon: XML Pro published by Wrox Press Products: http://www.netfolder.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To unsubscribe, mailto:majordomo@i... the following message; unsubscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|