[sc34wg3] SAM-issue term-scope-def

Lars Marius Garshol sc34wg3@isotopicmaps.org
15 Jun 2002 17:37:30 +0200


* Lars Marius
|
| That would land us where RDF is now, and they have been having lots
| of debates on how to qualify statements. As far as I am aware they
| haven't really solved that problem to anyone's satisfaction yet.

* Bernard Vatant
| 
| Yes, but we have a reification process, right? I don't see why we
| should follow all RDF wrong tracks :)

Well, it's not just reification that is the difference, Bernard.
 
* Lars Marius Garshol
|
| Scope is simpler, and that's also its strength, I would say.
 
* Bernard Vatant
|
| Simplicity is paid by lack of semantic accuracy. 

Certainly.

| I don't think it's a valuable trade-off, because people use scope in
| a very lazy and loose way, because people are naturally lazy and
| loose if not forced otherwise ... as Graham example shows.  When
| newcomers in topic maps land are forced into defining role
| specifications to explicit non-typed or ill-defined relationships
| they were dealing with before, they first consider it as a
| constraint. But after a while, they see the gain of accuracy they
| get and they don't want non-typed relationships any more.

Ok. So what I hear is that some people would prefer to get rid of
scope altogether. To me that means that we have to reconsider what we
are doing. Either we are rearchitecting topic maps completely from top
to bottom, or we are merely strengthening the existing standard.

Now, the requirements document that we already published[1] says that
we will preserve backwards compatibility as far as we can. Discarding
the TNC may conceivably fit within that scope (provided we push hard,)
but I don't see how discarding scope altogether could do that.

So either we have to agree on a completely new direction, or we have
to stay with the original plan. Of course, the original plan does not
prevent us from first producing a firm and complete standard, and
*then* moving on to changing it, though admittedly this may cause
trouble for TMCL and TMQL.

Quo vadis, SC34?
 
* Lars Marius Garshol
|
| So I do think scope can be useful, and although I agree that the
| scope does not contain any information about what each theme is
| doing in the scope applications know this. They can figure this out
| either by recognizing the themes, or by recognizing what they are
| instances of.
 
* Bernard Vatant
|
| But if this information was carried in a standard way by a role
| specification in scoping association, the applications would be able
| to process it in a standard way, not through an ad hoc case-by-case
| process.

Possibly. I am not sure role types would give you so much more than
the types of themes, but that's a discussion I am not very eager to
start.

What we were discussing was whether scope is the intersection of its
themes, the union, or simply unspecified. If someone wants to argue
that we should redo everything then I'd be happy to discuss that as
well, but it belongs in a different thread, and we should be aware
what it is we are doing.

[1] <URL: http://www.y12.doe.gov/sgml/sc34/document/0241.htm >,
    see "Relationship to other standards", point 2.

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