OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tm-pubsubj message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [tm-pubsubj] Re: TC Website reorganization, and drafts update


Mary Nishikawa wrote:
> 
> Bernard,
> 
> Thanks for putting this together. I have a few comments about the
> Recommendations:
> 
> For the new definition proposal for published subject we now have, "A
> published subject is any subject for which at least one subject definition
> document has been made available by an identified publisher."
> 
> How about this instead if we need to be more explicit:
> 
> "A published subject is any subject for which at least one subject
> definition document at a stable URI has been made available for public use
> by the publisher identified within the published subject documentation."

It might not be an entire document, but rather a document node, such as

    http://www.topicmaps.org/xtm/1.0/core.xtm#occurrence
or
    http://www.topicmaps.org/xtm/1.0/index.html#psi-occurrence
 
(in the XTM spec, the former points to the latter, and vice-versa)

> This is only for clarification, but for the subject indicator definition,
> the sentence that Lars Marius recommended is in addition to the first
> sentence and does not  replace it completely?
> 
>   "A subject indicator is a resource that is intended by the topic map
> author to provide a positive, unambiguous indication of the identity of the
> subject. A resource can become a subject indicator by being referred to as
> such by some topic in  some topic map."

I've been so swamped lately that I've not had enough time to comment in
any detail, but perhaps a few words are in order.

I think it's obvious that we need to do whatever it is to assist people
in providing unambiguous, stable, and well-defined subject indicators. To
this end we should avoid anything that makes it difficult for people to
publish PSI sets. 
 
> For 3.2, in addition to the abbreviated list that Lars Marius proposed, can
> we also recommend to add dc:date with a comment that this is the date of
> publication? Is version information really needed or would this date suffice?

The real question is whether or not we should *require* that the publication
date be machine-readable, and if so, how the date(s) should be provided and
maintained. DC includes ways of establishing more specialized date semantics,
and we'd probably be wanting initial date of publication as well as extent of 
validity and last update (or "revision date"). This may be asking a lot of
our audience, esp. when the PSIs are part of a database or code base from
which the PSI publisher is unclear or unable to discern the date information.
For example, the ITIS database has an XML publication of content (as a snap-
shot), but the individual records are also available as subject indicators.
This is a complicated subject, in my experience.

Note that I've published a proposal on how to include DC content within
XHTML documents, if that's any help.

  http://www.doctypes.org/meta/NOTE-xhtml-augmeta.html
 
> Can we also add the acronyms in parenthesis to the published subject
> documentation (PSD)  and the subject definition document (SDD) definitions?
> There are no acronyms used for the other definitions in ISO 13250, so this
> may not be good to have acronyms for some but not for others. I just wanted
> to put this on the table to be thought about.

Unless the acronyms are necessary or have good reason to exist, I'd rather
we avoid creating any new ones. There's too many floating around now
to keep track of, and just getting "PSI" across everyone's radar has
been hard enough. The concepts aren't tough so we ought avoid turning
anyone off with unneeded complexity of terminology (which acronyms
create, IMO). (yes, I'm guilty of that "IMO")

> It would be nice to have at least one  example of the PSD and the
> individual SDDs.

I'd started to reply to Bernard regarding having one type of PSI 
documentation or definition and ran out of time. I'm doing so again
right now.

Suffice it to say that the sources of definitions for PSIs are not
always going to be put into a specialized XML markup language, and 
I think it's a mistake to require that. Most will be in XHTML or
HTML (as in Cyc), or as addressable resources online (perhaps as a
database query, as in ITIS). Requiring a specialized markup creates
a big expenditure of resources that seems unnecessary given that
the XTM design was to allow pointing to any addressable resource,
especially since it's been the XTM documents themselves that in my
experience have served as the subject "anchors."
 
I for example can't go to the Smithsonian and tell them that their
continually-changing ITIS database must be transformed into an online,
specialized XML document to provide addressable resources to provide 
subject access points for each database record when they've already 
gone to the trouble of allowing direct database access to each record 
through a URL query string. They'd first think I was daft, then tell
me they didn't have the interest or the resources to create such a
document. It's be additional, unnecessary maintenance for them. 

Since I've been a bit out of the loop on some of the conversations, 
perhaps I'm misinterpreting what is going on here.

Murray

...........................................................................
Murray Altheim, Staff Engineer          <mailto:murray.altheim&#64;sun.com>
Java and XML Software
Sun Microsystems, 1601 Willow Rd., MS UMPK17-102, Menlo Park, CA 94025

       Ernst Martin comments in 1949, "A certain degree of noise in 
       writing is required for confidence. Without such noise, the 
       writer would not know whether the type was actually printing 
       or not, so he would lose control."


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC