Re: [office-metadata] fields proposal

[Svante Schubert <Svante.Schubert@Sun.COM>]

Hi Bruce,

thanks for this posting, keeping us up to speed.

Bruce D'Arcus wrote:
> To preview the point of view I've come to on fields so that we 
> hopefully can be fairly efficient with discussing it next week, my 
> position is:
>
> 1) even if I have a dedicated citation field, the generic field should 
> still be adequate to implement my use case
Yes, that is my understanding as well. Your citation field is a metadata 
scenario commonly used by the office and therefore gifted by it's own 
elements and attributes.
>
> 2) a new generic metadata field -- what we now call text:meta-field -- 
> should not use the xml:id + RDF/XML approach to encoding the basic 
> logic of fields; rather, the URI(s) for the subject(s) it references 
> should be included in the field (in content).
Other elements receive a xml:id to be linked / referenced at - not only 
by metadata- but in general. I doubt you would like to miss this nice 
feature for your citation field (and the metadata fields).
>
> 3) if we require a URI (and allow optional parameters), we should 
> allow multiple URIs
The usage of multiple URIs - (as required by your example later) -  is 
not the only way to solve the problem, nesting text:meta-fields could be 
a different solution.
A further more generic solution could be the usage of RDF/XML. All the 
required further information as the URIs and the later mentioned 
parameters could be expressed by it. But you want to disallow this. Why? 
I do not see any problem in using RDF/XML.

Although it could be nice to have always similar design between citation 
fields and other metadata fields, this does not weight so much as to 
restrict all plug-in vendors using metadata fields to use a metadata 
design similar to the citation field. Especially when you run easily 
into problems expanding the element set of the metadata/citation field 
for further informations (RDF statements).
Could it be that RDF/XML was not chosen for the design of citation 
fields as the fields were created before we agreed on using RDF/XML?
Now you are able to specify a RDF vocabulary for the parameter that are 
still missing instead using an ODF element/attribute.

The main question you triggered is: What kind of RDF statements of a 
metadata field have to be in the content?
To answer this question, we have to figure out  when we have to put 
metadata into the content and when to put it into RDF/XML.

I assume there is only one rule:
All ODF application that do not want to support metadata should be able 
to display a document with metadata similar to any other ODF application.

Due to this, whenever a string is similar to a RDF literal and being 
edited in the viewed content, the string and the RDF statement have to 
be in-content (the RDFa approach).
For any other metadata there exist no rule nor a guideline. The choice 
is completely up to the RDF application.
For example, the content created from a RDF application based on 
metadata - viewed in the document - is placed in a text:meta-field. But 
how the RDF statements are attached to the field (in-content vs. 
RDF/XML) is irrelevant.
Moreover if the field had been generated by some algorithm, the 
description of this process does not have to be part of the document. 
For example, when a plugin would offer the relation between "Last  
Tuesday of the year" to a xsd:date.

Hope this helps!
Svante