<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=ProgId content=Word.Document><meta name=Generator content="Microsoft Word 14"><meta name=Originator content="Microsoft Word 14"><link rel=File-List href="cid:filelist.xml@01CEEE9C.02EB3180"><style></style></head><body lang=EN-US link=blue vlink=purple style='tab-interval:.5in'><div class=WordSection1>Hello all,<o:p></o:p><o:p> </o:p>I propose that we start a comprehensive ‘tagged’ section of the Wiki, perhaps “Jrf*” (or “Jrs*”, see next paragraph) which would aim to unify, centralize, and coordinate documentation pertaining to standards and compliance within the DELPH-IN ‘joint reference formalism.’ <o:p></o:p><o:p> </o:p>(For those who feel that this type of information constitutes engineering “specifications” rather than declarations of our formal axioms, I am agnostic to the naming of this meta-section. In fact, I suggest we distinguish “joint reference formalism” from “joint reference specification.” A start at a conflation of the two seems to be here: <a href="http://moin.delph-in.net/DelphinRfcs">http://moin.delph-in.net/DelphinRfcs</a> )<o:p></o:p><o:p> </o:p>Anyway, this occurred to me when I went looking for a page on our so-called “Lkb morphology.” This technology, although pioneered and developed in the context of the Lkb, is now a standardized part of our specification, uniformly supported by four processing engines, so creating a new page titled ‘LkbMorphology’ seemed regressive. The page I sought doesn’t exist, but if it did, it could have peers (including existing pages renamed) such as:<o:p></o:p><o:p> </o:p>JrsTop – index to the following pages<o:p></o:p>JrsTdl<o:p></o:p>JrsRepp<o:p></o:p>JrsTokenMapping<o:p></o:p>JrsMorphology<o:p></o:p>JrsLexicalFiltering<o:p></o:p>JrsChartDependencies<o:p></o:p>JrsParsing<o:p></o:p>JrsGeneration<o:p></o:p>JrsTransfer<o:p></o:p>etc.<o:p></o:p><o:p> </o:p>Deprecated technologies would not be admitted or maintained under this tag, so the meta-tag itself serves to document our notions of contemporary, modular, and supported NLP processing steps. If separating out the truly formal, that umbrella might include only direct relatives of the formal grammar tuple, e.g.<o:p></o:p><o:p> </o:p>JrfHpsg<o:p></o:p>JrfMrs<o:p></o:p>JrfRootSymbols<o:p></o:p>JrfLexicon<o:p></o:p>JrfSyntaxRules<o:p></o:p>JrfWellFormedness (or JrfUnification)<o:p></o:p>etc.<o:p></o:p><o:p> </o:p>Thoughts welcome,<o:p></o:p><o:p> </o:p>Glenn<o:p></o:p><o:p> </o:p></div></body></html>