Next in thread →
Next in month →
Re: [office] Run-Time behavior for Metadata
Regards, Rob Weir Senior Technical Staff Member ICS Business and Technical Strategy Mobile: 1-978-467-5445 E-mail: An Antic Disposition: www.robweir.com Find me on: <> wrote on 02/03/2014 12:21:46 PM: > From: Svante Schubert <> > To: office <> > Date: 02/03/2014 12:18 PM > Subject: [office] Run-Time behavior for Metadata > Sent by: <> > > 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? [image removed] > [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 [image removed] > > 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? > It is certainly an issue. I did a presentation on the topic back in 2011: http://www.robweir.com/blog/publications/berlin-plugfest/ODFMetadata.pdf Part of it is what I called the "hidden constraint" problem where copying or editing an object with metadata can break assumptions. One way of information the application on how to handle this would be via a metadata constraint language. For example, tags like "no-copy", "no-duplicate", "no-split", etc. This could give a hint to the editor that when a given object is copied how the metadata should be treated. Regards, -Rob > Regards, > Svante
Next in thread →
Next in month →