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:
> > 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."

Murray:
>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)


>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.

Mary:
How about this, or maybe it is too verbose perhaps?
"A published subject is any subject for which at least one stable subject
definition document or  addressable resource has been made available for 
public use
by the publisher identified within the published subject documentation."

We may want to call it published subject documentation package as Lars 
Marius suggests.


> > 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?

Murray:
>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

Mary:
Thanks Murray. It is very helpful. I think that we need to go slowly on this.

>
> > 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.

Murray:
>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")

Mary:
I don't have strong feelings one way or the other.

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

Murray:
>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.


Mary:
I agree with you completely here and  have expressed  a similar sentiment 
to Bernard.

For example, if Schlumberger were to implement topic maps, I do not think 
that we would go through the trouble and expense to create specialized xml 
documents to provide addressable resources for the same reasons you pointed 
out. There are generic PSIs that we would use though.

Murray, what I understood from the Orlando meeting was,  html resources 
containing fragment identifiers for subjects could also be used as an SDD. 
The requirements can also encourage the use of additional metadata  within 
the html file or an html or xml metadata file linked to that resource or 
visa versa. The SDD could also be used as a standalone resource for 
defining subjects. Is my understanding correct?

I would guess that the most common general use case would be PSI sets 
created with one or more SDD documents in html with fragment identifiers 
for each subject in the resource. So I think that I agree with you here.
I think that another interesting use case is how subjects in html, xhtml, 
or xml files are "annotated"  in W3C's Annotea. I wondered how this would 
fit in with our recommendations.

We do need a thorough interchange to get the recommendations done. Please 
stay in the loop.

Cheers,
Mary
**************************************
Mary Y. Nishikawa, Technical Editor & EDMS Support
XML Evangelist
Technique/ InTouch Documentation
Schlumberger K. K.
2-2-1 Fuchinobe
Sagamihara, Kanagawa 229-0006

Tel: +81-42-759-5376
Fax: +81-42-759-3563
**************************************



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


Powered by eList eXpress LLC