ISSUE 4 bis - Re: [tm-pubsubj-comment] ISSUE 4 - Relationships betweensubjects

[Bernard Vatant <bernard.vatant@mondeca.com>]

Lars Marius

I don't think this issue is *soup* to be pushed on the backburner. My view is at the
opposite that it is a concrete use case on which we can think and procede efficiently
about structure of PS Doc and/or individual PSIs, out of the fuzzy and complex land of
generalities.

The class/subclass (or BT-NT) example is typical and important, because most potential PS
Docs will consist of, or contain some kind of, classification, taxonomy, ontology ...
thesaurus. Maybe focusing on recommendations for those specific use cases would avoid
rambling for ever in very conceptual debates. As Suellen pointed lately, our "target
market" preoccupation is : "What do I do with my existing
classification/headings/thesaurus/ontology subjects". Those have existing specific
structure, defined by well-identified relationships, huge legacy, and if we could deliver
a first recommendation that address correctly that issue, if nothing else, I think we'd
hit at least 90% of potential users. I guess we would cover the scope of GeoLang and
XMLvoc too.

So back to the frontburner - Say we have a botanical taxonomy for trees

Dicotyledones > Fagales > Fagaceae > Fagus

The "definition" (description?) of subject "Fagaceae" includes, for a botanist, two
fundamental kinds of information.

1. The relationships of class Fagaceae with its upperclass Fagales and subclasses (Fagus,
...)
2. The specific characteristics distinguishing Fagaceae among other Fagales

A (PS Doc) topic map representation of this taxonomy could be structured as:

-- either a "flat" set of topics, each one providing all the above information in
"description" occurrences using <resourceData>.
This solution has the advantage to include the whole definition inside a <topic> element,
making it easy to declare the subject indicator as being this <topic> element

-- or a set of topics providing information 2 in "description" occurrences, linked by a
set of class/subclass associations providing information 1. That makes more sense as a
topic map, and will allow to import the hierarchical structure in any topic map engine or
any kind of XTM-conformant "ontology broker", provide search and navigation facilities etc
... But in any case, the subject indicator should provide information 1. And if this
information is not given inside the topic element, the subject indicator has to include
some associations in which the topic plays a role, which leads to a heap of questions ...

-- or both. Information 1 and 2 inside the topics for standalone use, and Information 1
replicated in associations.

The choice will lead to different PS Doc structures. So I suggest we figure the PS Doc
structure recommendation in that use case, and see how it is extensible to other cases
where e.g. more complicated relationships between classes and individual instances are
involved. If we give up because of complexity of the generalisation, at least we would
have something available.

Of course, that would mean split the first deliverable into two parts at least:

1. Recommendations for classifications, taxonomies, thesaurus and similar hierarchical
sets of subjects.
2, 3, ...n ... everything else.

Say what?

Bernard

----- Message d'origine -----
De : "Lars Marius Garshol" <larsga@garshol.priv.no>
À : <tm-pubsubj-comment@lists.oasis-open.org>
Envoyé : jeudi 25 avril 2002 14:59
Objet : Re: [tm-pubsubj-comment] ISSUE 4 - Relationships between subjects


>
> * Bernard (in issues.htm)
> |
> | -- Do the relationships between subjects, e.g. class/subclass,
> | belong to each PSI?
>
> Here we're again swimming in soup, because we're so far ahead of
> ourselves that we don't know what it is we are discussing. What is a
> PSI?
>
> Don't you really mean to say:
>
>   "do class-instance and class-subclass statements belong in the core
>   metadata about published subjects, should they be in additional
>   metadata, or should they no be asserted at all?"
>
>   "do general relationship statements belong in the core metadata
>   about published subjects, should they be in additional metadata, or
>   should they no be asserted at all?"
>
> In any case, I feel that this is way too early to discuss. It depends
> on the appropriate structure of PS Doc sets, and therefore we should
> try to get some clarity on that before we move on.
>
> Does the PS Doc set contain only formal metadata? Does it contain a
> human-readable description + formal metadata? Can the formal metadata
> be broken up into several parts? And so on. Once we know this we can
> return to this issue, rephrase it much more clearly, and settle it in
> a way that it is much less likely that we will have to revisit later
> on.
>
> | -- Or should they be declared outside individual PSIs, in the
> | general PS Doc structure?
>
> Again, what does this mean? We don't know yet. It seems to be related
> to what I am saying above, but it's difficult to tell.
>
> | -- Should they be declared at all?
>
> Ditto.
>
> | Proposal:
> |
> | When relationships with other subjects are inherent to the
> | definition of a subject (ex: taxonomy, thesaurus) they should
> | be declared inside each individual Subject Indicator.
>
> What is "the definition of a subject"? It seems to me that there's a
> need for a term that identifies the notion your trying to get across
> here, and that we should define it before moving on.
>
> * Steve Pepper
> |
> | It seems to me that this is really only a problem when PSI
> | sets are being published in some machine processable knowledge
> | representation like topic maps (or RDF).
>
> Yes, and we don't yet know what we think about that, nor do we have
> any precise terms for discussing those issues.
>
> --
> Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
> ISO SC34/WG3, OASIS GeoLang TC        <URL: http://www.garshol.priv.no >
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>