office message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [office] Run-Time behavior for Metadata
- From: robert_weir@us.ibm.com
- To: Svante Schubert <svante.schubert@gmail.com>
- Date: Tue, 18 Feb 2014 11:18:20 -0500
Regards,
Rob Weir
Senior Technical Staff Member
ICS Business and Technical Strategy
<office@lists.oasis-open.org> wrote on 02/03/2014
12:21:46 PM:
> From: Svante Schubert <svante.schubert@gmail.com>
> To: office <office@lists.oasis-open.org>
> Date: 02/03/2014 12:18 PM
> Subject: [office] Run-Time behavior for Metadata
> Sent by: <office@lists.oasis-open.org>
>
> 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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]