[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [topicmaps-comment] multilingual thesaurus - language,scope ,and topic naming constraint
[Lars Marius Garshol] > > * Lars Marius Garshol > > * Thomas B. Passin > | It's easier for me to see this as a potential problem than to know > | what to do about it. Or maybe someone can explain why it is a > | non-issue. Perhaps it means only that the granularity of a topic > | map is the whole map itself. But who wants to have import giant > | maps into their little one? > > You're making lots of usage assumptions here that I can't follow. I > haven't yet seen this to be a problem, but I'm open to the possibility > that there might be one. If you could explain what you think that is > I'd like to hear it. > > | Perhaps we need a Rec analogous to xinclude, so we can import a > | topic or a small set of topics without having to import an entire > | map. > > Why? Suppose I have a web site (or it could be a processsor that would do something further with the information). I want to link to some information in your topic map. Perhaps I want to get information on how to cook a goose, let us say. I don't want to view a representation of the information, I want to do some more topic map processing on my system, connecting the new information to information on geese that I already have. How can I do this? 1) I reference topic IDs in your map. 2) I import your whole map. 3) I extract part of your map with a topic map query language. 4) I extract a relevant fragment of your map 1) I may reference a topic in your map by its uri, but I can't do much with that unless I can also reference all the other topics and associations in your map the that given topic links to. I also have to be able to retrieve them if necessary. We don't have a well-defined way to allow that. Also, your URIs may change if you merge other maps, so my links, if I could establish them, may not continue to work. So I cannot be sure I can update my information from you. 2) I do not want to import your whole 100 MB map to get information just about the cooking of geese, which may only amount to 30 KB, say. 3) This is probably the intended way of doing the task, but I'm concerned that any such query would not return enough context information to make the topics useful for me - that is, to merge into my map. For example, a query might return an association of a goose topic with cooking information, but not about what classes the "goose" topic and association topic are. If we have removed the names from being children of the topics, as in PMTM4, we may not even get the name of the "goose" topic unless we craft a more complex query. You may argue that I should examine the query results and query again for any more information I need, but that could easily become a resource and time-intensive recursive activity both for me and for your server. 4) This would be where an xinclude-like ability would come in. It's not necessarily the same as an ordinary query, because it would include as much context as necessary for the recipient to make proper use of the returned information. I welcome anything which can show me how this kind of operation will not in fact incur serious difficulties of the kind I sketched out above. Note that none of this applies to the case where a person looks at some results in, say, html format, such as in the Ontopia demo system. It applies, rather, to the case where I want to do something further in the way of topic map processing. Cheers, Tom P
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC