Metadata Charter

[Patrick Durusau <patrick@durusau.net>]

Greetings!

A couple of quick comments for the discussion later today:

1. From the comments I have seen, I think there is a general feeling 
that the requirements and use case deliverables should be combined into 
one deliverable:

> 1. A list of meta data use cases for OpenDocument documents and 
> OpenDocument
> enabled applications, together with a classification of the use cases.
> 2. A list of meta data related requirements for future versions of
> OpenDocument, which will be prioritized by the OpenDocument TC. 

With just a little judicious editing those can be arranged in such a way 
as to allow the OpenDocument TC to set priorities for further deliverables.

2. On the "main" editing tool portion of the charter:

> The proposed enhancements further must consider office applications as 
> the
> main editing tool for OpenDocument documents, which means, they must not
> conflict with the processing model of OpenDocument documents for office
> applications.

a. I don't think that not being in "conflict with the processing model 
of OpenDocument documents for office applications" has any relationship 
to "consider[ing] office applications as the main editing tool for 
OpenDocument documents...."

Further, I think the suggestion has been made that levels of 
conformance, the default I suppose being the "ignore but preserve" 
strategy of the current standard, be specified for any metadata additions.

I rather like the idea of conformance levels for metadata support.

**A use case/example of non-office application editing an OpenDocument 
document follows, feel free to ignore as the main points are above.**

Background: Bankruptcy courts in the US are used by individuals and 
corporations who are unable to pay their debts as they come due. The 
filing of a bankruptcy petition (a highly stylized form) triggers 
certain legal consequences for others, even if they are unaware of the 
bankruptcy filing. The following senario is based on my memory of 
bankruptcy procedure which is almost 20 years out of date but should be 
generally valid in terms of the steps.

A bankruptcy petition is electronically filed in ODF format with the 
clerk of the bankruptcy court. That transmission is accepted by the 
Durusau-Bankruptcy module which does a number of things. It validates 
the petition according to the local rules, such as verifying that the 
attorney of record has been admitted to the local bar and more 
importantly, initiates a transfer of funds to the clerk's office to pay 
the filing fee. Assuming the petition is accepted, the petition is 
accepted and electronically signed by the module.

As a consequence of filing, bankruptcy notices have to be generated and 
delivered to all the creditors listed in the petition, any banks where 
accounts are held, etc. Those notices are automatically generated, in 
ODF format, and electronically delivered to all the creditors, banks, 
local law enforcement (who are often in charge of selling property 
seized in court proceedings), etc. As electronic acknowledgements arrive 
concerning that notice, both the delivery and acknowledgement 
information is written to the ODF doucment from the debtor that lists 
those parties.

Creditors file their claims in ODF format and the metadata in those 
documents is used to write further information to the documents 
submitted by the debtor concerning the claim of that particular 
creditor. (This is not required by ODF but suggested so that any 
creditor can obtain a copy of the appropriate document and have all the 
current information on claims and the basis for them, with links to the 
original documents.)

Note that none of the writing to the file has been done with anything 
that could be considered a traditional office application. Nor is it 
necessary that the application in question be able to engage in 
processing of the OpenDocument in any traditional sense of the word. It 
need only be able to process the portion of the metadata necessary to do 
its task and no more. Whatever processing model it uses for that task 
should be irrelevant, so long as it results in a comformant ODF document.

Actually, for security purposes, I suspect that none of the process 
could be invoked other than by the automated process.

Apologies for going on at such length but I think it is important to 
realize that ODF has the potential to enable this sort of automated and 
collaborative processing without everyone having to adopt a single 
vendor solution.

Hope everyone is at the start of a great day!

Patrick

-- 
Patrick Durusau
Patrick@Durusau.net
Chair, V1 - Text Processing: Office and Publishing Systems Interface
Co-Editor, ISO 13250, Topic Maps -- Reference Model
Member, Text Encoding Initiative Board of Directors, 2003-2005

Topic Maps: Human, not artificial, intelligence at work!