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


Help: OASIS Mailing Lists Help | MarkMail Help

tm-pubsubj-comment message

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

Subject: RE: [tm-pubsubj-comment] human actors and machine agents

Title: RE: [tm-pubsubj-comment] human actors and machine agents

> -----Original Message-----
> From: Lars Marius Garshol [mailto:larsga@garshol.priv.no]

> Then I think you need to train yourself, basically.

That's what I say, this is reasonable to a certain extent. XML is human readable - genertally.
At least this has been one of the "design goals" of http://www.w3.org/TR/2000/REC-xml-20001006:
"6. XML documents should be human-legible and reasonably clear."

> I don't see that
> "Thomas Bandholtz" is a subject, while "person" is not. You can
> legitimately assign topic characteristics to both, and therefore it
> makes sense that both can be topics in their own right.

If I want to make a small topic map about the members of our TC, do I really have to look for a definintion (or make one myself) what a "person" is, then do the same for "member", "organisation", "tc", etc., etc. ? If so, we really need a well-accessable registry of topic types to be used by authors that do not want to make the definition of these general terms to become their topic when they talk about, for example, a finite list of known people.

> | Secondly, there is too much tagging between the information. When we
> | use attributes instead of elements wherever possible, everything
> | would become much more compact and more human readable.
> That's true, but I don't think it is important. XML is inherently
> awkward for this, which is why I chose a completely different
> syntactical base for LTM. (Note that Robert Barta did the same with
> his AsTMa, as did the RDF people with their n3.)

I don't think XML is "inherently awkward" for anything, but that is another question. I guess we have agreed to use XML, and we should make the most of it. Any non-XML syntax may be a interesting contribution, but it does not help to achieve interoperablity, so I would not recommend this.

> Go back and read what I wrote. We would *not* put the assertions in
> the HTML, we would put a link to them. It is not hard to make an agent
> able to find that link and follow it to, say, an XTM resource.

Ok, we discussed that in BCN friday morning. Unfortunately you haven't been there.

> This is where you would need a generic fragment creation algorithm,
> which I think is very hard to do.

Why? I see a fragment is always "centered" by one pre-identified topic. Then I include the direct associations, and the topics associated directly (without their further associations. Full stop. In ISO terms this may be called a distance of zero, as ISO uses "the number of intervening topics" as the counter. I would prefer to say: the distance of the fragment is one association.

In a second step, I think about letting the request specify the distance it want to find in the fragment response.

> I am also not at all convinced that you need it.
> If you think there is a useful use case to be served by this fragment
> retrieval stuff, then please define it and let us consider it as a
> possible step 4. I would *not* start there, however, as it would make
> published subjects enormously much harder to publish and use, and it
> would also limit them to topic maps.

OK, I would not *start* there either. A use case: Say, I have an application ("agent") that is able to process XTM and display it in a very user-friendly way, the topics one-by-one, using the "centered" fragments I have been talking about. When my agent finds an external topic- (or PSI-) reference in the map it currently is processing, it wants to display the PS in the same way without having to merge the external Topic Map totally first. May be this is the Alexandria Gazetteer (4,9 million topics).

> So what? They don't have to use documents. Nothing says they should,
> nothing requires them to. So what is the problem?

Once again: currently fragment identifiers do not work with web services, or any webified database application.

> Certainly, we should document this issue and help publishers avoid
> this pitfall, but I don't see what more we can do. Do you?

Yes. I think we *must* raise this question somewhere in W3C or IETF. This is a dangerous gap in the standardization environment we have to use. There will be no local solution. I will continue thinking about this. Mostly related standard issues are

Thomas Bandholtz
CM / KM Division Manager; XML Network Moderator
Competence Center Content Management

Kaltenbornweg 3
D50679 Köln / Cologne
+49 221 8299 264


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

Powered by eList eXpress LLC