[topicmapmail] Are Facets Really Simple After All?

[Kal Ahmed]

On Mon, 2003-12-01 at 15:31, Murray Altheim wrote:
> Kal Ahmed wrote:
>  > On Mon, 2003-12-01 at 14:31, Murray Altheim wrote:
> [...]
>  >>No, not the first time. The first message of the thread I started
>  >>on facets outlined two forms, Model A (the "RDF" model) and Model
>  >>T (the "facet" model). Metadata about a topic is what I've been
>  >>talking about all along. That's what RDF is: metadata about a
>  >>single thing, a simple triple. The differentiation between "metadata
>  >>about a Topic" and "metadata about a subject" I'm not making.
>  >
>  > I think you have to make that distinction. You talk about the colour or
>  > time of creation of a topic, none of those things are properties of the
>  > subject, they are properties of the topic that represents the subject.
>  > You would not mean that "The time of creation of Paris is
>  > 2003-11-23T11:34:55", regardless of how you expressed it you would mean
>  > that "The time of creation of the topic who's subject is Paris is
>  > 2003-11-23T11:34:55".
> 
> Okay, yes, I'm just getting lost in the thread here. Yes, there is
> a distinction that must be made between subject and Topic. I'm just
> not sure where to go from there.
> 
>  >>I'm
>  >>going to have to answer Bernard, but in my first glance he mentioned
>  >>that Topics are binding points. I agree with that. The triples in
>  >>Model A are properties attached to the Topic. I consider those
>  >>different than occurrences attached to the Topic. Occurrences are
>  >>a specialized Association in the model that have their own special
>  >>semantics and a special syntax in XTM, the <occurrence> element. We
>  >>never created a <facet> element, nor did we a <property> element.
>  >
>  > I thought I had understood you to say that the values of these
>  > properties apply to the topic, not the subject, but now I'm not at all
>  > clear on that.
> 
> No, you're correct.
> 
>  > Is your <property> actually meta data about the topic (e.g. time of
>  > creation of the topic, UI representation of the topic etc.)? If so, then
>  > I agree with you that occurrences of the topic itself is not the way to
>  > express this. If you're property is meta data regarding the subject
>  > (i.e. meta data about Paris, not meta data about the topic representing
>  > Paris), then I see no need for anything beyond occurrences and
>  > associations to express this information. If you are saying that a
>  > <property> is both of these things, then how do you propose to tell the
>  > difference (how do I distinguish the creation date of the topic from the
>  > creation date of the subject that the topic represents ?)
> 
> I think my hesitancy is about the middle area. I think that the
> definition of "metadata" is really what's more in question. What is
> meta at one level isn't at another, and perhaps I'm simply trying
> to tackle more than is necessary. In my original note the idea of
> "Model A":
> 
>    http://www.infoloom.com/pipermail/topicmapmail/2003q4/005406.html
> 
> there is an attempt to "do" RDF, i.e., create a way in XTM to express
> the simple triples of RDF. What *is* metadata? I dunno.

You are absolutely right, of course. What is meta data for some is
information for others, its a matter of perspective. To my mind we use
meta data to assist in searching, describing and classifying the
information that we really care about. Meta data is just information
that helps us work with the information that we want to work with.
Transferring that view to the topic map world. I would suggest that for
the most part, the information that we really care about (within the
domain of the topic map - I'm not discussing the resources that the
topic map links to as occurrences here) are topics, and has to be topics
because if we care about this information we are going to want to say
something about it. Then what ever we consider to be meta data can be
treated as either topics or occurrences - depending on whether or not we
believe this information to be something that someone else using the
same topic map will care about enough to want to say something about.

>  But the idea
> of being able to express simple triples about a Topic without invoking
> the whole Topic machinery is what I have heard people yearn for since
> we did XTM (and during its development). 

Thats true. But I think that the occurrences mechanism we have is much
more generally useful than simple triples.

> It's what we dropped when we
> decided not to implement facets in XTM. 

Careful here. Facets in ISO 13250:2000 that did not make it into XTM 1.0
are not properties of topics, they are properties of resources. You
point to a resource and apply property value pairs to it. Sure, it could
be a mechanism for providing topic meta data (by pointing to the topic
element as the resource), but it was not principally created for that
purpose. The reason facets didn't make it into XTM was that it was felt
that if this resource is something you care about enough to want to
attribute  property/value pairs to it, then you should create a topic
that represents that resource and use occurrences. In other words, ISO
13250:2000 facets are a short cut for reification and using occurrences.


> I think it might be dangerous
> to attempt to distinguish between metadata about a Topic and metadata
> about a subject for the same reasons that what is metadata at one level
> isn't at another.

I have to disagree here. This is not a question of levels of detail in
one domain, but two orthogonal domains. The domain being described by
the topic map and the domain of topic map constructs. If you are not
clear about that distinction, you end up assigning a DC:Creator property
value to Paris meaning that you created the topic "Paris" but read by
someone else to mean that you created the city of Paris.


>  All of this is likely very application-dependent, and
> the approach taken in ISO 13250 (i.e., be very vague) could either be
> considered a weakness or a strength.
> 

I would be very interested to see what kind of application could
function properly without making a distinction between the domain being
described (the territory) and the mechanics of its description (the
map). Fortunately I think that ISO 13250 is abundantly clear that you
cannot force those two things together in the occurrences construct -
they are not for  information related to the topic construct, they are
for information relevant to the subject.

> I've been going back and forth on this partly because the discussion
> warrants it, and partly because I am somewhat sitting on the fence,
> trying to figure which side would hurt the least if I fell off.
> 

The only advice I can offer is to keep a strict separation between the
map and the territory.

Cheers,

Kal
-- 
Kal Ahmed, Techquila
Standards-based Information Management
e: kal@techquila.com
w: www.techquila.com
p: +44 7968 529531