FW: J McClure RDF proposal for structural markup

[Peter Meyer <pmeyer@elkera.com.au>]

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.