Run-Time behavior for Metadata

[Svante Schubert <svante.schubert@gmail.com>]

Hi,

seems I have left the IRC chat too early to see the metadata comment from Michael after discussing the ODF FOSDEM presentation https://fosdem.org/2014/schedule/event/simplifying_reuse_with_metadata_support_in_odf_and_plugin_apis/

[16:20] Michael Stahl: Svante: interesting that somebody actually uses that - did they complain about the missing metadata features like copy/paste etc too? 

[16:21] Oliver-Rainer Wittmann: Michael: as far as I remember, they did not complain. But the talks were only 15min. and we had not much time for discussions

[16:22] Michael Stahl: Oliver: oh there wasn't time for complaints - isn't that the most important part of talks 

I have contacted them (see http://commonsmachinery.se/author/peter/ for more details) for more problem details earlier today, but AFAIK they have talked about having problems when copying metadata where the xml:id can only exist once in an XML file.

Editing metadata is indeed problematic, but IMHO that was not solvable with the ODF 1.2 metadata spec, but might be when describing change (run-time XML changes). The xml:id is just an implementation detail without semantic value (which should neverless be stable - different topic). If the metadata is moved it would be kept, if the metdata is being copied a new xml:id would be created as object (target) of the same metadata.

Without knowing the exact use case of them, yet, I still remember the discussion of the general problems of move and copy "document parts" with metadata. In general I suggest that metadata is only being kept when it can be seen/viewed by the user or is controlled by a plugin.
Still there are different types of metadata that have to be handled different. It seems we need meta-meta data (types). The following three types important to us come to my mind at once:

1. Metadata that marks a document part similar to "important", "top secret", etc.
   
2. Metadata that describe a special text entity such as phone#, address, name, which might require a certain representation. Changing one representation should (perhaps after questioning) result in changing all the others.
   
3. Metadata that is directly related to ODF properties of the document part, therefore can be influence and controlled of the office and should be altered when changed:
   Their should be subtypes as for
1. Position in document (a move would require an update of the metdata)
   
2. Seize/length of document part
   
3. Creator
4. Creation Date
5. Being green, the font..
   
6. ...
   
   

What do you think? Does it make sense and if so, does such a topology exist already somewhere in a standard?

Regards,
Svante