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] | [List Home]

Subject: Re: [tm-pubsubj] Deliverables: Conversation starter


Lars Marius Garshol wrote:
> * Patrick Durusau
> | 
> | Seems to me that we need to get some deliverables, i.e., examples of
> | how to do PSI out sooner rather than later.
> That's for GeoLang to do, I think, and it's pretty close to being done.
> This page is very close to what we want:
>   <URL: http://psi.oasis-open.org/iso/639/ > 

Note that the charter of GeoLang says:

This Technical Committee will define sets of published subjects for 
language, country, and region subjects, in accordance with the 
guidelines for published subjects to be laid down by the Published 
Subjects TC.

I have not seen any guidelines for published subjects, much less that 
they should be expressed in XTM syntax.

> In any case, the first thing we need to do is to agree on what the
> content of the remaining deliverables should be. Then we can talk
> about what it should be.
> | While my examples were "sub-optimal" even as HTML based PSIs, I
> | think it is the case that PSIs that are published using topic maps
> | will certainly have more capabilities than those that written as
> | HTML pages. Same is the case for PSIs that use the OAI mechanism for
> | storage will have advantages over static HTML PSIs.
> Well, for all of this stuff I'd like to start with requirements. What
> is it we actually want to enable people to do? Let's consider that
> before we run off in all kinds of directions trying to satisfy demands
> we don't even know what are.
Seems odd to me that requirements become an issue after GeoLang has 
already run off in one direction but I can live with that.

In any case, let me sketch (mind you a sketch only) of the conversation 
the SBL is having with a vendor of electronic texts.

What is of interest to the vendor is having a uniform set of identifiers 
for use in electronic files (separate from the actual displayed 
identifier in a text) for personal/geographic names, citations, etc., so 
that when they are creating indexes, links, etc., they have one set of 
identifiers, whatever is displayed to the user. The vendor is really 
agnostic in terms of how the identifiers are created/maintained/ or 
communicated to the creators of texts so long as the set is unique and 
stable. It is also the case that the vendor is not interested in 
"resolving" the identifiers, at least in the sense of accessing a 
resource to obtain further information.

So, in one sense, the vendor really doesn't care how creators of 
electronic texts become aware of the unique identifiers, but on the 
other hand, if they are not effectively communicated, then the vendor 
loses the widespread use that makes the unique identifiers useful. 
Doesn't really help to create yet another set of identifiers that are 
used by a segment of the population.

I don't have a list in front of me but I suspect that even divided up by 
by categories such as personal vs. geographic names, that the lists are 
going to be too long to easily consult as single webpages.

So, to effectively communicate these unique identifiers, they need to be 
delivered as separate HTML pages.

No argument that at the same time an XTM syntax version should be made 
available for those who can use it, but that is a separate issue.

Does that help?


Patrick Durusau
Director of Research and Development
Society of Biblical Literature
Chair, V1 - Text Processing: Office and Publishing Systems Interface
Co-Editor, ISO 13250, Topic Maps -- Reference Model

Topic Maps: Human, not artificial, intelligence at work!

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