[topicmapmail] Are Facets Really Simple After All?

[Thomas B. Passin]

Murray Altheim wrote:

> Thomas B. Passin wrote:
> 
>> Murray Altheim wrote:
> 
> But Tom, it's really more than that. It's not just UI stuff, but
> any meta-information that might be considered about the Topic,
> but not sharing the subject of the Topic. So, in addition to the
> UI stuff in my example (of which 'created date' is not really UI),
> there'd be any of the relevant Dublin Core-style metadata such as
> creator, contact person, contributor, resource type, identifier,
> source, rights, medium, version number, etc.
> 

How did we get from looking at representing facets to capturing all 
possible metadata about a topic?  I do not look at them as the same 
thing.  Now personally, I would have no problem with creating a topic to 
or association hold certain meta data if it was all related and coherent 
and if I cared  to distinguish the collection from other meta data about 
the topic. That would be similar to using a bnode in RDF.

This does not mean that I advocate overwhelming my topic maps with lots 
and lots of collection topics, but sometimes they may be useful.

Anyway, there is a fine line between data and meta data.  Some would say 
it is so fine as to be non-existent.  I think a more interesting 
distinction is between (meta) data that is about a single subject (like 
author, date of publication, etc.), and data that inherently involves 
two subjects, such as annotations one may make about published works. 
Annotations arise from an interaction between the work and the person, 
and thereby are - in my mind, at least - inherently different from data 
that "belongs" to a particular topic.  Associations vs occurrences, perhaps?

> If you generalize from a "UI proxy" to simply a "proxy", you're
> basically suggesting a container for any kind of Topic metadata
> that is connected to but not contained within the Topic. If for
> each Topic we wanted to store ten kinds of metadata, 

But Murray, in the past you have said you would be delighted to make 
large numbers of "properties" into topics so they could become the 
targets of any number of associations.  So why do you suddenly have a 
problem with these containers?  Anyway, whether to use containers like 
this will depend entirely on the data you want to model, how you wish to 
think about it, and possibly what you want to do with it as well.  I am 
not avocating them for all meta data or all facets. I simply responded 
to your well-grounded statement that certain UI properties were "not 
right" for the topic itself.  Presumably there would be many other 
properties that are "right", and the proxy topic would not make sense 
for them.

Cheers,

Tom P