RE: [tm-pubsubj-comment] ISSUE 4 - Relationships between subjects

["Mason, James David (MXM) " <mxm@ornl.gov>]

I certainly agree with Lars. We don't know what use people will make of
things we publish; they're likely to do things we never dreamed of and might
not even agree with. Best not to build in too much structure, unless we wrap
it with all sorts of warnings. I am reminded of some of John Sowa's
complaints against SUMO: they've tried to build a big, complex ontology, and
you can't just dip into it for some piece you need without getting entangled
in their web.

(I think of a discussion that's going on in the Mac world: someone put up
what purported to be a fundamentalist Christian site attacking Macs and Mac
OS X in particular because it's based on something called Darwin, which the
site took to mean Darwinism
(http://207.67.219.101/objective/propaganda.html). The most recent opinion
is that the site is a hoax, right down to the concocted name of the
purported author
(http://www.applelinks.com/articles/2002/04/20020425135747.shtml#11). But
the site is filled with working links to real sites of apparently complete
sincerity. Do the folks whose sites have been snared by the hoax approve or
even know about it?)


Jim Mason

> -----Original Message-----
> From:	Lars Marius Garshol [SMTP:larsga@garshol.priv.no]
> Sent:	Thursday, April 25, 2002 8:59 AM
> To:	tm-pubsubj-comment@lists.oasis-open.org
> Subject:	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>