Lars Marius Garshol wrote:
>
> * Jan Algermissen
> |
> | 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.
>
> Come on, Jan. You really know better than to claim something like
> this.
Ok, I should have said something like 'to *directly* retrieve'. My point is
that you need additional operations for something that is actually known
at the model level already.
>
> select $TOPIC from
> occurrence($TOPIC, $OCC), resource($OCC, "http://foo/document1.pdf";)?
>
> | 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?
>
> What's so magical about this particular query? Why is it not
> unacceptable that you have to compute all supertypes (recursively) of
> topic type X? Or all operas based on plays written by Shakespeare? Or
> all topics that are instances of both X and Y? And so on.
Because your examples are domain specific and the model has no notion of
Shakespeare etc. OTH, the semantics of resource addresses *are* known
at the model level.
If the model provides surrogates for other subjects and demands their merging
on the basis of subject indicators, why does the model not provide
surrogates for information resources and demands their merging on the basis
of their addresses?
Is there any reason for this besides your claim that the model would be
more complicated (which it would not be, BTW).
> I think there's widespread agreement that a TMQL and a TMCL are
> absolute musts. I don't think the data model, on its own, is seen as
> anything like as important.
Ah so,...you base TMQL and TMCL on the data model and this is in turn not
that important...?
>
> And even if we disregard the whole query language issue, suppose we
> *did* require the locator items to be merged.
This is not what I mean! The model should provide surrogates (items)
for the information resources, each with a locator property and the
merge the items based on that property.
If we did, how would you
> access all topics of which X is an occurrence in a standard way?
In the same way as you go from topic to occurrance-resource now, just
the opposite direction. The connection comes in automatically because
the information resource would then sit at the other side of the occurrence.
That is my whole point: the connection would simply *be* there.
OK,
> so you have a data model, but that doesn't give you a standard way to
> do this, only a standard way to talk about it.
>
> So I really don't get what the issue is here, Jan. If we were talking
> about a conceptual model I would agree with you, but we aren't.
Huh.....the whole discussion is about the model. OTH, what do you
mean by 'conceptual model'?
>
> | 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)?
>
> Jan, is the point having a single node or getting all topics of which
> X is an occurrence? (In other words: why this focus on what's going on
> under the covers? One of the original complaints about the TMDM was
> that it constrained implementations too much.
At least I never said that.
Now it suddenly doesn't
> constrain them enough. This whole discussion really makes no sense to
> me.)
>
> | 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?
>
> Requiring merges of locators (and strings) would make the model a lot
> more complex, to no perceivable gain.
As said above I 'propose' something else and it remains to be proved that
the model would be more complex.
>
> | 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.
>
> Remember that text in the RM that it is acceptable simply to say
> specify rules for when values are equal rather than requiring them to
> have the same proxy?
What do you mean? Values are not subjects, thus they are not surrogated and
thus not subject to merge.
>
> * Lars Marius Garshol
> |
> | What problems does it cause? If it doesn't cause any, why is it a
> | weakness?
>
> * Jan Algermissen
> |
> | 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.
>
> Actually, the model *does* make the information known. It specifies
> the rule for when the locators are to be considered the same. In the
> RM you have to traverse to find the topics, and so you do in TMDM,
> though the traversal is different. What is the big deal?
The traversal is far more complex than it could be, you have to
traverse the entire graph to find the answer!!!
>
> | 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".
>
> For all you know the RDBMS may be *doing* just that...
I am talking about the model, not an implementation!
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
|
