Lars Marius Garshol wrote:
>
> * Jan Algermissen
> |
> | Applications that implement the 'Standard Application Model' (SAM)
> | suffer from the problem you describe [...]
>
> What's the problem, really? If you can get the information you need,
> is there really a problem here?
Consider:
<topic id="t1">
<occurrence>
<resourceRef xlink:href="http://foo/document1.pdf"; />
</occurrence>
</topic>
<topic id="t2">
<occurrence>
<resourceRef xlink:href="http://foo/document1.pdf"; />
</occurrence>
</topic>
In the above snippet http://foo/document1.pdf is an occurrence of both, t1 and
t2 but since the SAM does not provide a single surrogate for the information
resource
(http://foo/document1.pdf) it does not (at the model level) provide the ability
to
retrieve all topics that http://foo/document1.pdf is an occurrence of.
Ok, the information can be computed, but I find it very odd to say: "Yeah, I
know that
the locators in the two occurrences refer to the same resource...if you need
that
information readily available, go and compute it yourself". Really, what is the
benefit of Topic Maps then? I could equally well store everything in a
relational
database and compute the stuff I need.
Why not (at the model level) provide a surrogate for the information resource
and link
to it from both occurrences, why is the SAM crowd reluctant to this?
Especially in the case of occurrences it is very likely that there will allways
be
metadata about the information resources anyway (at least title!)
>
> | and need to provide proprietary indexes that make the information
> | you are concerned with directly available.
>
> All access to topic map structures is necessarily "proprietary" (I
> guess you mean non-standard)
Sure...non-standard == proprietary, eh?
now, regardless of whether you need an
> index or not, since there is no standard query language or API.
>
> Once TMQL is in place this whole issue goes away,
Beware that a query language can only express stuff in terms of
the data model on which it is based
since there will
> then be a standard way to do this. With tolog you'd just say
>
> select $DOCTOPIC from
> functional-description(valve16, $URL),
> subject-locator($DOCTOPIC, $URL)?
I am not familiar with tolog....how would you express
"Give me all topics that are occurrences of http://foo/document1.pdf";
regarding my snippet above?
> and that would be it. Once there's a standard TMQL it will presumably
> be even easier.
>
> | As an end-user you propably won't notice this, but I think it is
> | worth to point out that the connection you request is not explicitly
> | a part of the Standard Application (Data) Model
>
> There's nothing special about that. In any given topic map there will
> be an infinite number of potentially interesting connections that are
> not directly available. So what? Who cares about internal
> representation? As you say, certainly not the end user.
As I said above: If there is nothing special about these connection issues
regarding Topic Maps, what is their benefit (why not use the relational
model and compute what is needed)?
Another way to ask this is what the rationale behind the SAM's decisions
about what to connect how and what to provide a surrogate for and what not?
Is it an arbitrary decision to not provide surrogates for information resources?
If not, what is the rationale?
The Reference Model simply uses one surrogate for each subject and everyhing
related
to this subject is directly connected to the surrogate and thus available
without
pre-computations.
>
> | I have personally never understood why nearly nobody has ever been
> | concerned with this particular weakness of the SAM.
>
> What problems does it cause? If it doesn't cause any, why is it a
> weakness?
If a data model does not make explicit certain information that is actually
known (at the model level, not domain specific) to be there but requires
additional control structures or computations to make it accessable then
I consider that a weakness.
It is a bit like representing all columns in the relational world as
independent items and saying: "Yepp, the columns can be grouped to
tables...you may compute that information if you like".
> BTW: As I've told you before the name "SAM" is now deprecated. The
> official name is now Topic Map Data Model, or TMDM. It would be nice
> if you could start using it instead of confusing people with the old
> name.
Duh..I must have missed that ;-)
Jan
>
> --
> Lars Marius Garshol, Ontopian <URL: http://www.ontopia.net >
> GSM: +47 98 21 55 50 <URL: http://www.garshol.priv.no >
>
> _______________________________________________
> topicmapmail mailing list
> topicmapmail-Zo64W7twoUFWk0Htik3J/w@xxxxxxxxxxxxxxxx
> http://www.infoloom.com/mailman/listinfo/topicmapmail
--
Jan Algermissen http://www.topicmapping.com
Consultant & Programmer http://www.gooseworks.org
|
