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] referring to a topic from outside a TM (w as:multilingual thesaurus - language, scope ,and topic naming constrain t)



Hi Thomas,

* Thomas Bandholtz
| 
| I think I have already answered most of your comments in
| http://lists.oasis-open.org/archives/topicmaps-comment/200203/msg00037.html.

Could be. I'm offline in a hotel room in Washington D.C. right now,
and can't dereference that URI.
 
| To summarize:
| * if the URI reference does not really address something physically,
| it will only be a name (still an URI reference).

In what context? URIs appear in many different roles in topic map
documents, and the behaviour associated with each situation is
different.

| * the meaning of a fragment identifyer is only defined in relation
| to certain media types.

Yes, absolutely.

| * this seams to be implemented for HTML only till now.

Yes, but so what? We are not using web browsers to work with XTM
documents, anyway, so what do we care?

| * a database service (i.e. using a Java Servlet) has no
| pre-detectable media type, so the Web server/Servlet engine will not
| pass the fragment identifyer at all.

That is not relevant to XTM at all. Let's say that I would like a
topic map service to return a particular topic to me using HTTP
requests. I could do it any of these ways:

  http://www.ontopia.net/tmserver/topic-lookup?objectid=348231
  http://www.ontopia.net/tmserver/topic-lookup?subjind=http://psi.ontopia.net/ontopia/ontopia.xtm#ontopia
  http://www.ontopia.net/tmserver/topic-lookup?topicid=ontopia
 
All of these would give me the same topic, but I could conceivably
devise completely different interfaces to this kind of service.

What kind of interface and service it is you are thinking of I don't
know. If you could explain it would make this discussion a lot easier.

| * A *query* (indicated by an ? in an URI) is not a fragment
| identifyer, but part of the URI (not: URI reference) itself, so the
| meaning is not dependant of the media type.

Again true but irrelevant.
 
| * There seems to be no implementation of query-support for HTML
| files.

Ditto.
 
| --> If a PSI shall be a persistant URI able to access a Topic
| definition physically - you must never change the "media type"
| (including data base) of this definition :-)

That is correct, and it's not really any different from any other URI
in this sense. You must be careful never to break the connection
between the URI and the resource it refers to in any way.
 
| Another question is: what do you really access?

In what context? You're discussing some situation, but you never
really make it clear what that situation is, which makes it really
hard to achieve anything in this discussion.

| *** Fragment identifyers address sequential positions (points) in
| documents that are of random sequence. They do not address
| objects. What is behind your access point - up to the "end of file"
| - is completely undefined, and there is no way to define it.

So? I'm not saying this is wrong, but I do fail to see how it relates
to XTM.
 
| *** The meaning of a query is completely undefined at all, but there
| is a way to define it. I am currently preparing a Web Service
| Description (WSDL) sample that exactly defines that an URI like
| http://your.domain.xyz/psi/services/getTopic?id=4711 will return
| exactly the definition of Topic 4711.  This WSDL is also including
| the schema that will be used in the response.

Many people are doing things like this, but it's still not relevant to
XTM as far as I can see. That is, it's not relevant to the XTM syntax,
but it's certainly a meaningful kind of topic map service.
 
| But - what shall be returned when you access an association? 

It's up to the application that receives the HTTP request. It can
return anything at all. What the correct thing to return is depends on
what you want to happen, and only you can know this.

This is like discussing what should be returned when you call a Java
servlet. Obviously, it depends on the servlet. There is no single
answer that is true in all situations.

| The association only, containing unresolved links to its topics? The
| association plus these topics? There are different "chunk" (as
| Thomas Passin said) options, and I am afraid we need a concept of a
| <topicMapFragment> to get this solved.

Any <topicMap> element is really a fragment, in a philosophical sense,
and I don't think we need a new XML element for this. I think all of
the answers you give are plausible ones, for certain kinds of
services. For another service it might be: an SVG visualization of the
association. 

In short, it all depends on the application.

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
ISO SC34/WG3, OASIS GeoLang TC        <URL: http://www.garshol.priv.no >



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


Powered by eList eXpress LLC