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


Murray

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

Agreed. Our recommendations should enable publishers to make their legacy available as
Published Subjects with the less possible hassle, and that is the intention of 3.1. Is not
it clear enough about it?

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

What is clearly your proposition on that?

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

Agreed. I think we should avoid any kind of acronym.

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

Agreed. There again, it's the sense of 3.1.

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

I'm completely tuned with that. But the difficulty is to figure how to express the
recommendation with, on one hand sufficiently generic terms, so that it does not constrain
a specific format, structure and syntax, but OTOH in a sufficiently accurate way, so that
any publisher/author/user can figure if any existing documentation is conformant, and if
is not, what would be the minimal modifications(s) to achieve conformance.

Are we able to express the requirements without specifying a syntax or format, but by
defining necessary features of recommended structures/formats in such a way that we could
declare clearly : this is conformant, that is not? Otherwise, defining the recommendation
for published subject documentation in terms of *semantic content* only is a very
dangerous slope ...

Challenging indeed ...

Bernard




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


Powered by eList eXpress LLC