OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-metadata message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office-metadata] Document Design and metadata


Svante,

Apologies for the delayed response!

Svante Schubert wrote:

> Hi Patrick, Hi Bruce,
>
> concerning the statement of Patrick, I am not sure if I understand his 
> position completely. (Maybe it is simply a Monday phenomenon..):

Probably not. I get that fairly often. ;-)

>
> How can any chosen meta design help a bad written user document to 
> become well - or even better - written?

Not a question of making a document well or better written but of being 
able to capture/document why particular metadata was used. If you think 
of styles for example as being metadata.

>
> Where are the obstacles in saying there should be no indirection of 
> metadata by having metadata on metadata in a document?
>
More abstraction I am afraid. ;-)

First obstacle: To say that metadata on metadata is "indirection" is a 
mis-characterization of what is being requested.

First case: I want to attach metadata to metadata to make a statement 
about the oriignal metadata itself. Such as resonsibility for the 
metadata. May or may not have any impact on the processing of the 
original metadata or its impact upon the data to which the original 
metadata applies. (This is not indirection as I understand you to be 
using the term.)

Second case: I want to attach metadata to metadata to change how the 
original metadata is processed. The original metadata is still being 
applied directly to the data so there is still no indirection as you use 
the term.

Third case: I want to attach metadata to metadata and that "indirect" 
metadata is being applied to the original data. That is the 
"indirection" case that you are seeking to exclude by saying no 
"indirection."

Aside to Bruce: You see, abstraction can be useful in terms of making 
clear what is being assumed or simply overlooked even by apparently 
legitimate positions such as no indirection of metadata.

What the "no indirection" position assumes is that if one wants 
different metadata on data, one simply changes the metadata.

But that would be like programming without version control. You want the 
program to be different, then simply change the code. What's the 
problem? ;-)

Well, the problem is that one cannot go back to a previously (hopefully) 
working version of the code.

If I cannot attach metadata to metadata, then I cannot make statements 
about the metadata *as it existed* which may be very important in 
evaluation of the content of the document.

We have heard Rob's spell checker example, but consider that security 
metadata has been applied to a document and I think it is incorrect. 
What do I do? Do I simply change it? Or should I attach metadata to the 
security metadata that flags it for review?

To be blunt, the "no indirection" position presumes fairly simplistic 
document flow where all that matters is the final document. In a modern 
enterprise environment I think that is probably more the exception than 
the rule, particularly in work flows where multiple parties may wish to 
comment not only on the "data" but also upon the metadata itself.

Such as Rob's example where we have asymmetric metadata such as legal 
comments on a contract and one of the parties to one side of that 
asymmetric metadata wishes to make comments on a portion of the 
metadata. I don't see any legitimate reason to prohibit such metadata. 
The comment/metadata is about the metadata and not the data per se.

Second obstacle: A no metadata on metadata rule locks ODF into a static 
document model, unnecessarily.

Recall that our use cases include asymmetric metadata, medical metadata 
(which by its very nature is going to change and yet preservation of 
prior metadata is essential), searching metadata which by its very 
nature may change over time and/or for various audiences.

Yes, at one point in document creation/processing it may have been 
common or even useful to think of a document as a dead thing that was 
issued from an author for storage and publication. But, I think that 
view of documents, particularly in increasingly dynamic environments, is 
clearly out-dated.

Perhaps the "data" of a document will not change but that is not a 
reason to suspect that the metadata of that document and moreover 
metadata about the metadata will not.

I don't think this is a throw-away issue as it has a great deal of 
impact on the nature of an ODF document and as you can tell, I favor 
enabling ODF documents to be able to take advantage of a dynamic view of 
documents.

Hope everyone is having a great day!

Patrick







> Bruce D'Arcus wrote:
>
>> My hunch is to be in favor of allowing the same attribute we would 
>> allow on content nodes to be allowed on styles, and to use that as 
>> one mechanism to associate metadata with content.
>>
>> But as my language ("the same attribute") suggests, I think if we 
>> design this right, this question ultimately becomes a trivial one 
>> from the standpoint of the schema.
>>
>> So I'd suggest we leave it aside for now. It is not the most 
>> important thing we need to resolve.
>
> I am curious, what is the most important thing for you right now?
>
>>
>> It also emphasizes the need for a few use cases to design around. I 
>> already have a few on the brain-storming page, but we could use a 
>> couple/few more.
>>
>>
> Best regards,
> Svante
>
>
>

-- 
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! 




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]