[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@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