[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: J McClure RDF proposal for structural markup
Dear TC members, Earlier in the week I posted a message to John and the TC leadership group regarding John's RDF proposal for the structural markup. Daniel Greenwood asked me to post it to the TC list. I also think this is necessary to clarify some points that may be lost in the discussion: 1. I do not oppose the use of RDF per se. I oppose its use for the core structural markup because it is highly inconvenient for authors to create and unnecessary at that level. 2. I have not and do not in any way oppose support for linking. Clearly it will be required. I don't quite know what that support requires or means but that is another question. RDF may or may not be part of the solution. I don't have any preferences in that regard. The Harrop/Meyer structural markup proposals deliberately did not address the issue as part of structural markup. We defined structural markup as a basic layer of markup that is needed whether or not you are interested in adding linking facilities or many other markup requirements. Its the simplest skeleton to provide a platform for everything else. Linking was not part of the requirements adopted by the TC for structural markup many months ago. John now appears to be saying that the structural markup must use RDF in order to support linking. 3. The issue to be determined at this point is not whether RDF is a good thing for linking and other purposes but whether it is needed or even useful in the basic structural markup of clause level objects in terms of the clause model requirements. Separate discussions on the list attempt to understand John's assertions and address this question. Regards Peter Meyer ------------------------------------------- Original message sent on 22 October. ------------------------------------------- Dear John, Last week Jason proposed that we should resolve the issue of RDF or not RDF for the structural clause model before moving to resolve the comparatively minor differences between us in the Harrop/Meyer clause model proposal. Personally, I don't claim to be an expert on RDF so I asked one of our developers who has done some work with it to review the materials you submitted and advise me on the merits of the proposal so I could better appreciate the issues involved. After also reviewing your materials, the following is our findings (written by me in a rather non technical way). 1. In the clause model requirements, we broke the process down into stages in an attempt to try to focus on discrete issues at each stage so that we could try to reach a consensus on each point before moving to the next. It is extremely difficult to discuss proposals that attempt to cover a lot of issues because its hard to pick out the good from the not so good. I think that is part of the issue with your proposal. Your objectives regarding linking and so forth are fine but its trying to impose an approach that does not fit the overall problem. 2. The objectives of structural markup as we perceive it are: (a) Define the most basic markup that supports the widest needs without burdening the majority of users with markup that they do not need. Structural markup as we propose, on its own, will support all the basic authoring, data management and publishing needs of most users. Most will need to add only a very modest amount of additional metadata to support quite powerful automated processes. It is also worth noting that the structural markup is intended to be generic for a wide range of legal and business documents so that common systems can be used, rather than separate systems for each of a range of DTDs or Schema. (b) Markup content so that the author's conceptual model for the document can be rendered accurately in print and online. (c) Define basic objects that can be easily reused (in a markup sense) in different contexts regardless of the foibles of the authors. In this respect, we are trying to develop a model that allows authors to flexibly create their content but in a way that maintains simple and consistent markup structures. (d) Define objects onto which additional semantic or other information (metadata) can be added to support more sophisticated processing, where its required. The structural model should be a foundation for all the uses you envisage and more. 3. To achieve these objectives: (a) The clause model defines a small number of objects that can be used in different contexts to clearly define common grammatical constructs such as clause, subclause, paragraph etc. Even though these terms are fuzzy, the structure we have used in the clause model requirements are clear and that model demonstrates the basic concepts that are important. (b) It relies on the strict hierarchical and sequential relationship of these objects to determine structure. Except, possibly, in some edge cases which are not relevant to the initial proposal, nothing more needs to be added to the markup to determine the generic document structure. (c) It relies on fairly strict relationship between objects to limit the different ways authors may achieve a particular desired outcome. [Just how strict this needs to be is a matter to be resolved.] The key point is that an author can insert a few elements and move them around the draft document without renaming them and without adding any other information. They can create a highly structured document from which a human and a processing system can infer the generic structure of the document using whatever terminology of clauses, subclauses, paragraphs, lists etc they choose. You don't need to call it a clause to know its a clause in a contract document. However, if it is important to someone to actually call it a clause rather than an article or something else, that information could be added via metadata. That is beyond the scope of the initial proposal but I am sure it needs to be addressed in a later stage. 4. We expect specialist content writers who create standard form documents and templates or precedents to create documents in XML. We hope that others will also the standard in their document authoring if its benefits are to be fully realised. To overcome the current barriers to the use of XML we have to create a DTD or Schema that is REALLY simple, flexible and reliable. It has to be easy for authors and provide the consistent structure needed by developers. 5. We believe that your proposal confuses the issue of what is structural markup and its function. It mixes a loose element model and a metadata model at all levels of the document. As far as we can see, without the metadata, the collection of objects in the document would not tell a human reader or a processing system the information they require to know its generic structure. You would not know which objects are intended to be clauses and are to be numbered etc. The metadata is hardly optional. The problem this raises is discussed in more detail later. 6. We believe that the metadata should be separated from the basic structural markup so that the application does not burden users with markup they don't require. See point 2(a) above. 7. I am also confused about what you really see as the basic authoring environment for XML in law firms etc. You appear to say that XHTML will be adequate and that the structural model is unnecessary. If so, why propose another model? You may be right that many will not bother with a structural model. We do not oppose the use of XHTML if that is what people want to use. We agree that the TC should develop a semantic layer that can be mapped to XHTML if that is what is considered necessary.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]