From: Patrick D. <pa...@du...> - 2009-11-25 23:23:46
|
Øyvind, Øyvind Eide wrote: > I have to run for a workshop, but I enclose today's raw draft as well, > mainly in order to ask one question: Maybe writing the document as a > series of examples, where the main ideas develops through the > practical approach, is a better way to do it? The result were are > aiming at is supposed to be practical, yes? Well, I suppose in the TEI tradition, yes and no. (to both questions) ;-) Personally I would shy away from writing the document as a series of examples. At least not without first having stated what rules, guidelines, etc. are meant to be defined. Defining rules or guidelines *by* example in my experience leads to sloppy writing of the rules and/or guidelines. Mostly because of a "...see what I mean..." approach to writing. I may or may not share your assumptions about what an example means. Let me take part of this document to illustrate that point. Section 2.2 starts with: > There are silently assumed world views in the TEI, no ontology. The > most explicit world view is expressed in the TEI-header and in the > bibliographic reference module with a complete set of elements to > encode common library practice. In addition the manuscript module > represents a set of elements reflecting the normal content of > manuscript catalogues encontered by the Master project. While I would disagree with the second part of the first sentence, I would agree with the balance of this paragraph. But, then the document goes on to say: > Besides these two domain specific areas the ontological schema of TEI > consists of: > > * Actors: <person>, <org> > * Events: <event> > * Place: <place> > * Properties (linking the three above categories): <relation> > * Timespan: attributes when, notbefore, notafter, etc > * Names: <name> and other variants > * Type (taxonomy, thesauri): a large bestiarium > * References to web resources > * References to intellectual content on the manifestation level > (FRBR) via biblref > > Any ontology or datamodel which can be expressed by instances of the > above elements can be expressed in TEI. Which made me realize the importance of the second part of the first sentence, "....no ontology." Hardly. Every element in the TEI is the expression of a claim about some portion of text and that claim has some position in a larger set of claims, whether expressed or not. If you wanted to formally state, for purpose X, the ontological status of elements a ...n are useful, we can argue about what is in or out of that set of elements. But that is establishing a guideline without examples, because unless you are going to enumerate all the possible examples, we are likely to miss cases where we might agree or disagree. Enumerating all the examples sounds to me like a very difficult task to assure that we have covered all of them. I do concede that my "no example" approach to standards isn't universally shared. ;-) One recent example would be the work on OOXML. Be aware that I removed all the non-normative text from one draft and the word processing part went from over 1,800 pages to less than 500. I was unpersuasive as you will see the final version is now nearly 10,000 pages. I still plan on finding the time to produce a normative version that should run about 1,200 to 1,500 pages. Long but not unreasonably so. There are people who take a sort of middle ground approach, such as the W3C work. See XSLT 2.0 for example, http://www.w3.org/TR/2007/REC-xslt20-20070123/ But do note that they have rigorous definitions *and* examples. Personally I think the rules/guidelines need to be written first and in such a way that they can be decorated with different examples for different domains. Either we have meant what we said over the last 20 years about markup enabling customization and re-use of content or we have been lying all that time and developed a way, in addition to clay tablets, of creating fixed texts. I prefer to think that we have made some progress towards the former. Hope you are having a great day! Patrick -- Patrick Durusau pa...@du... Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) |