[topicmapmail] external resources reifying

[Jan Algermissen]

Lars Marius Garshol wrote:
> 
> * Jan Algermissen
> |
> | 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.
> 
> You do need extra explanatory steps. What an implementation does is up
> to the implementation, and for the QL and CL we can choose whether or
> not to require extra operations. What we eventually will do I don't
> know.

Maybe that is where we disagree: I don't think that either of them
can require 'extra operations' but I lack the theoretical
understanding why. 
> 
> * Lars Marius Garshol
> |
> | 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.
> 
> * Jan Algermissen
> |
> | 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.
> 
> Only the Shakespeare query is domain-specific, not the other two.

Ah, sorry. Being an RM-head, I see all semantics as domain specific,
actually even 'resource address' which is just a property. But, yes,
from your POV only the Shakespeare query is domain-specific.

> 
> | 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?
> 
> Because this is a data model, not a conceptual model. The only thing
> that is known about the resources are their locators, and so that is
> the only thing that shows up in the model. What's done in the model is
> very much driven by what there is a need for, and as I said doing this
> would complicate the model.

Well, I still claim that the model is overly complicated now (see reference
below).

> 
> | Is there any reason for this besides your claim that the model would
> | be more complicated (which it would not be, BTW).
> 
> Look, if you don't think the model would be more complicated, why
> don't you draw up a proposal for what it would look like with this
> change?

I did this some time ago:

http://www.isotopicmaps.org/tmmm/TMSM-1.3/TMSM-1.3.html

See especially 

http://www.isotopicmaps.org/tmmm/TMSM-1.3/TMSM-1.3.html#parid0027

and the paragraphs before it. Topic Maps can be completely expressed by
'surrogates with properties'. There is no need for the various surrogate
types (topic,occurrence,association,etc). I have really never understood
what all the types are for...

> 
> I see no reason to make this change, and there's no way I'm going to
> put effort into it at this late stage because you *claim* that it's
> useful, without being able to come up with anything that convinces me
> that this is the case.

It would be interesting what others think...

> 
> If you can put a proposal on the table you'll have something the
> committee can look at, evaluate, and make a decision on.
> 
> (And you should then consider merging of strings as well.)

Why? Strings are values of a certain type ("String") and equality
issues of values are handled by the value type already.

Or would you want to make ths strings subjects themselves?

> 
> * Lars Marius Garshol
> |
> | 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.
> 
> * Jan Algermissen
> |
> | Ah so,...you base TMQL and TMCL on the data model and this is in
> | turn not that important...?
> 
> Read what I write. "I don't think the data model, ON ITS OWN, is seen
> as anything like AS important." As I've said before it's a means to an
> end. It's a way to achieve a goal. The thing itself is not important,
> it's only what it enables us to do that is important.

Hmm...to me the data model is the foundation of everything else. Maybe there
is the misunderstanding.


Jan


-- 
Jan Algermissen                           http://www.topicmapping.com
Consultant & Programmer	                  http://www.gooseworks.org