[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [tm-pubsubj] Deliverables: Conversation starter
Lars, 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 -- Patrick Durusau Director of Research and Development Society of Biblical Literature Patrick.Durusau@sbl-site.org 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!