Next in thread → Next in month →

Re: [office] Run-Time behavior for Metadata

From
<>
Date
2014-02-18T16:22:30+00:00
ID
Thread
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 →