Use and abuse of occurrence RE: [topicmapmail] Are Facets Really Simple After All?

[Kal Ahmed]

Jan,

On Mon, 2003-12-01 at 11:31, Jan Algermissen wrote:
> Bernard Vatant wrote:
> 
> > Rather than trying
> > to interpret whatever semantics are or are not to be found in the
> > definition of occurrence in various versions of the standard, let's face
> > some pragmatic evidence. Everything relevant to the topic has to be
> > attached to it in some way. Beside names and subject identifiers, TM
> > provides only two ways to do that. Either you use an association, or you
> > use an occurrence. In any case where you can't or don't want to use an
> > association, using occurrence is the default way. So the spectrum of
> > occurrence use has spread from the ones fitting with the original BOTB
> > index intention, to more and more exotic, and you say *heretic* ones.
> 
> Bernard--
> 
> just because <occurrence> is the only way to attach a property to a topic
> in XTM doesn't mean that it is correct to use it as such. Let's distinguish
> between:
> 
> a) XTM is broken because it does not provide a facility to attach mere
>    properties to as topic
> 

What do you mean by properties ? Do you mean meta data regarding the
topic construct in the topic map, or meta data regarding the subject
that the topic is a proxy for ? As I have already said in reply to
Murray, I don't think that it is correct to use an occurrence of topic T
to express meta data about the topic itself, but that it is perfectly
valid to use occurrences to express meta data about the subject that the
topic is a proxy for. From what follows I suspect that you are talking
about properties of the subject, not properties of the topic, right ?

> b) <occurrence> really has the semantics that make it suitable for
>    using it to assign properties to a topic.
> 
> If it is b) then we are fine but if it is a) I'd rather have XTM extended
> (fixed) than to carry this 'error' onward.
> 

If you are talking about properties of a topic, I have already outlined
in my reply to Murray how occurrences can be used to represent that (by
creating a topic whose subject is the topic to which you wish to apply
the meta data). If you are talking about subject properties, then I
don't have a problem with the use of occurrences for this.

> I am deeply convinced that a) is correct and that XTM should be extended
> with an element that allows assigning property value pairs to topics.
> 
> What do others (especially authors of topic maps, not XTM software developers)
> think about this?
> 

That excludes almost everyone who has taken part in this conversation so
far ;-)

> 
> Some issues to consider:
> 
> * All interpretations of the <occurrence> element I have seen so far
>   (PMTM4, various APIs, the current SAM draft) regard an occurrence
>   (that is: the relationship between topic and the other end) as someting
>   with identity (occurrences have type(s), scope, are represented as
>   objects in their own right, etc). This conceptual and implementation
>   overhead does not seem to match the semantics of a simple property
>   (e.g. "Jim weighs 150kg")
> 

> * Two very important properties of topics: the SubjectAdress and the
>   SubjectIndicators are *not* interpreted with the complexity of
>   an occurrence - they are understood to be simply propety class/value
>   pairs attached to a topic. So, why the overhead for "Jim's age is 34"
>   but not for "Jim has {URI} as the set of subject indicators". Makes
>   not much sense to me.
> 

The subject address and subject indicators do not need typing, they do
not need scoping. But given the topic "Jim" and the string "34", how do
I establish the age property without a type. How do I establish that my
statement is only valid in the context of "my best guess from looking at
Jim" ? I would need scope to do that.

Both type and scope are optional. So if your model of the world does not
need the "overhead", then don't use those parts of the topic maps model.

> * XTM is just a single format for representing topic map information,
>   I don't think it is wise to use XTM as a base for arguing. 

That XTM is a single format for representing topic map information is
true, but all that I have said above applies equally to the Topic Maps
Data Model.

> IOW: if
>   we allow XTM to dictate that any abstract model for topic maps does
>   not have a property facility we impose unneccessary complexity on
>   interpretations of other formats. Consider processing RDF represented
>   Dublin Core into a topic map....is it really clever to insist that all
>   attributes of a resource are to be represented as occurrences? Just
>   because XTM lacks a property facility?

What would a property facility provide that is not provided by
occurrences ? 

AFAIK RDF statements *are* resources and *do* have identity, so the
assignment of "34" to "Jim" is something that can be identified in the
RDF model, just as an occurrence of the topic "Jim" is something that
can be identified in the XTM model, so I don't see the divide that you
imply here. 

>  
> * Introducing a new element does not harm existing XTM documents, they
>   can easily be transformed into instances of the new DTD.
> 

Just because it can be done doesn't mean it should be ;-) What is the
real objection here ? 

Is it that you want simpler syntax? I guess not from your comment about
XTM

Is it that you want a simpler data model ? Well you would still need to
type your properties so you only lose the scope, and thats optional
anyway.

Is it that you want a clearer semantic distinction between the use of a
literal string or resource as a subject meta data value and the use of
the literal string or resource as a piece of information that is not
meta data ? If so, then what is wrong with defining PSIs for this
distinction (e.g. as a meta-type: type the "Age" topic as "Subject
Property Type", using a PSI for "Subject Property Type")

Or is it something else that I haven't understood from the foregoing ?

Cheers,

Kal