[sc34wg3] Illustrating SIDPs

[Patrick Durusau]

(Apologies for the length but Ann, as usual, has hit on a core issue 
that requires extended comment.)

Ann,

Ann Wrightson wrote:
> Robert/Patrick said:
> 
> 
>>TMCL is a language which allows to define constraints C ala "a + b >
>>c".  Our concrete universe is the set of possible topic maps M.  A
>>TMCL constraint C then validates against a map m (element from M)
>>under particular conditions as is defined by the TMCL semantics.
>>
> 
> 
> The question I would have is what defines your:
> 
> "concrete universe is the set of possible topic maps M."
> 
> Seems to me that if we take seriously the claim that a subject is 
> anything, anyone would want to say...., then you have a fairly large 
> universe to deal with. Or is there some subset that you intend to address?
> 
> I say:
> 
> I think Robert meant to talk about the things that are topic maps
> (considered as maps) - a universe that includes at least TMDM-compliant
> topic maps - and to exclude from M those things that (although they may be
> named in or referenced from topic maps) are not topic maps. He was also
> initiating the very respectable mathematical/logical move of indicating the
> universe relatively informally, then using the development of a formal
> definition of its members as a way to get more precise (while trying to stay
> faithful to the original intuition).
> 

Errr, none of which answers the question I posed to Robert:

That is: what defines "concrete universe is the set of possible topic 
maps M."?

Noting that the only ISO standard in the area defines a topic map in 
part as:

"a) A set of information resources regarded by a topic map application 
as a bounded object set whose hub document is a topic map document 
conforming to teh SGML architecture defined by this International 
Standard."

The point being, despite the reliance on HyTime, it is clear that topic 
maps are, at least in part, a view of information resources. cf. the 
classic TAO paper for illustrations that make this point better than I 
can in prose. (Also note the the idea of a "view" is not limited to the 
use of HyTime syntax. cf. my remarks on relational databases below)

I do note that further in ISO 13250:2002 section 3.26, topic map is 
defined to include instances of conforming syntax but the definition is 
clearly not limited to instances of a particular syntax.

> I read Patrick as including the range of values for subjects in the universe
> as well, so we have different universes.
> 
Sorry, that went by a little fast for a Monday morning. ;-)

True, since a range of values falls within (I think): "any thing 
whatsover, regardless of whether it exists or has any other specific 
characteristics, about which anything whatsoever may be asserted by any 
means whatsover" I do regard ranges as subjects but I am not sure how 
that fits into having a different universe.

I did not read Robert's post as necessarily excluding ranges, but that 
question may be answered when he describes his "concrete universe" in a 
little more detail.

> To Patrick: it might be helpful if you provided an example of an information
> artefact that is not a topic map.
>

Well, that depends on what you mean by "information artefact" and topic 
map doesn't it?

 From a certain point of view, a relational database is a set of tables 
(the logical view), while from a physical view, the same "information 
artefact" doesn't have anything that at first glance we would call a 
table, but sequential files, indexing, hashing, pointer chains, etc., 
that map onto the logical view.

I would consider a relational database to be an "information artefact" 
but the question is, what do you mean by topic map?

If you mean, does it conform to ISO 13250:2002 section 3.26, then no, it 
is not a topic map.

On the other hand, if "topic map" includes a view of an information 
artefact, then certainly, I can have a topic map view of the same 
relational database. That does not make a relational database into a 
topic map, it retains all of its original characteristics that made us 
say it was a relational database.

Does a topic map view = topic map? That certainly seems to be the case 
(section 3.26). Granted that it was poorly phrased in terms of a 
particular technology but I don't think there is any doubt that 
technology aside, a topic map view as a topic map is contemplated by 13250.

And I see no reason to change that view, save for making it more 
explicit and not tied to a particular manner of achieveing such a view.

To do otherwise would be to ignore the lessons learned from the years of 
experience with relational databases. The divorcing of the 
physical/implementation layer from the logical view layer, has made 
changes possible in the former, while maintaining the latter. Not to 
mention having a view of resources notion of topic maps allows users to 
integrate views of diverse resources without rather doubtful and 
expensive reworking of legacy or incompatible systems.

Your use case for the TMRM I believe is a better expression than I can 
manage of the need for a topic map view as a topic map.

Hope you are having a great day!

Patrick



> Ann W.
> 
> 
> _______________________________________________
> sc34wg3 mailing list
> sc34wg3@isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/sc34wg3
> 


-- 
Patrick Durusau
Director of Research and Development
Society of Biblical Literature
Patrick.Durusau@sbl-site.org
Chair, V1 - Text Processing: Office and Publishing Systems Interface
Co-Editor, ISO 13250, Topic Maps -- Reference Model

Topic Maps: Human, not artificial, intelligence at work!