Re: [office-metadata] summarizing recent suggestions

[Elias Torres <eliast@us.ibm.com>]

Michael.Brauer@Sun.COM wrote on 02/28/2007 08:44:11 AM:

> Hi Bruce,
>
> Bruce D'Arcus wrote:
> > Hi Michael,
> >
> > On Feb 28, 2007, at 4:04 AM, Michael Brauer - Sun Germany - ham02 -
> > Hamburg wrote:
> >
> >>
> >> What about calling the field just "text:meta", or "text:metadata", or
> >> "text:metadata-label" (I think the term label was suggested by Bruce)?

> >> If the name shall contain the term "field", then "text:meta-field"
> >> would be an option.
> >>
> >> My personal favorite actually is "text:metadata" or
> >> "text:metadata-label".
> >
> > I really have no strong opinion on this. I just chose the element names

> > to have something concrete to discuss. Does anyone else have any
> > opinions on the matter?
>
> I also have no strong opinion on this. So just take this as some
> suggestions, except that we should style with the "text" namespace for
> consistency reasons.

I'll ask again, isn't there already a field element in the text:namespace
that we can re-use instead of creating a new one? All we need to do is
either add an xml:id or RDFa-like attributes to it.

>
> >>
> >> "Typing" it somehow is a good idea. The concept we have for this
> >> already is to use namespaced names (see for instance chart:class
> >> attribute described in section 10.2):
> >>
> >> This would look like:
> >>
> >> <meta:field xml:id="0874801373 xmlns:contact="http://ex.net";
> >> field:type="contact:Contact">foo</meta:field>
> >>
> >> For consistency reason I suggest that we reuse this concept, unless it

> >> would be inconsistent with other metadata standards, or otherwise
> >> inappropriate.
> >
> > I didn't realize ODF already supported using shortened names for
> > attribute content.
> >
> > In any case, that's merely a shorthand, after all.
http://ex.net/Contact
> > == contact:Contact in your example. In that sense, we probably
shouldn't
> > care whether it's a full URI or a namespace-prefixed one?
>
> Yes, it's some kind of shorthand. But is is the notation we are using
> already, so I would prefer to stay with it, if there are no strong
> reasons not to do so.

It's exactly how RDFa uses and depends on QNames.

>
> >> In any case, a solution that requires that all RDF/XML streams are
> >> read to be able to update a field has the high risk that it introduces

> >> performance issues. Office applications for instance for performance
> >> reasons read images and embedded objects on demand only (that is, when

> >> they are displayed or edited). We should allow a similar behavior for
> >> metadata, too. A type plus maybe an IRI should allow that, but
> >> probably is not the only solution to this problem.
> >>
> >>> My alternative would be sometning like:
> >>> <field:field field:type="http://ex.net/Citation"; xml:id="0874801373">
> >>>   <field:source>
> >>>     <meta:link meta:resource="urn:isbn:98239809" cite:pages="23"/>
> >>>     <meta:link meta:resource="http://ex.net/1"/>
> >>>   </field:source>
> >>>   <field:body>
> >>>     (Doe, 1999: 23; Smith, 2004)
> >>>   </field:body>
> >>> </field:field>
> >>> I think it's just a practical matter how much the field should
> >>> contain to best enable document portability, including across file
> >>> formats (say OOXML; which looks more like the above).
> >>
> >> It's an interesting idea. For other text fields, the field description

> >> itself contains all data that describes what is displayed, but not the

> >> value that is displayed. Your idea seems to go into that direction. On

> >> the other hand, for metadata we assume that specialized implementation

> >> provide that string that is displayed. The data that describes what is

> >> displayed therefore is of value only for this specialized
> >> implementation. I therefore could also image that we actually move it
> >> to the RDF/XML streams that contain the actual metadata. The only
> >> thing we have to make sure is that it is easy to actually locate that
> >> data (see my comment above).
> >
> > The above is a generalization of the citation field, adapted for the
new
> > metadata support. It is also similar to how MS does this, BTW. What I
> > encode in two meta:link elements, they encode in a single dumb
attribute
> > (which would be really ugly to process with XML tools, BTW).
>
> Yes, I do understand that, and I have no objections to providing
> additional information in the content. But since we have the option to
> specify that as meta data, too, I would suggest that we look deeper into
> that idea if we agreed on the remaining issues. BTW: Section 11.7
> defines generic properties for form controls. Maybe we can reuse that.
>
> >
> >>>> In this context, you forgot to mention Elias comment about the
> >>>> datatype attribute. RDFa gets the content as a XMLLiteral not as a
> >>>> string. Elais offered the datatype="plaintext" to be able to receive

> >>>> only text from the ODF element. Any link on this, Elias?
> >>> Yes, I left that out, but agree it should be in, and would support
> >>> Elias' suggestion on the datatyping.
> >>
> >> ODF has already a (limited) type support for strings, doubles,
> >> date/times and durations. See section 6.7.1. This support is based on
> >> xsd datatypes and already provides a support for data styles. If we
> >> add type support for metadata, I suggest that we define them based on
> >> what we have already (the current metadata draft actually says so
> >> already).
> >
> > Yes, makes sense. But do we need to add a plaintext type then?
>
> I don't know. My concern is more about those data types, that usually
> are not displayed literally, like dates and durations.
>
> >>
> >> This would be different if we add metadata attributes to <text:span>
> >> element. When doing so, we would alter the way <text:span> element are

> >> used. For this reason (and only for this reason), I would prefer to
> >> introduce a new element.
> >
> > So, for example, putting the attributes on table cells would be fine?
>
> If it is reasonable from the metadata perspective that a table cell has
> a "meta:about" and an "meta:property", and maybe also an
> "meta:resource", and if these attributes must appear simultaneously,
> then this would be okay for me. Where I would have concerns is if would
> allow table cell elements that have only a "meta:about", and where we
> assume nested elements take the "meta:property" attributes, because this
> would cause issues when editing such documents with a WYSIWIG
application.
> > Bruce
> >
>
> Michael
>
> --
> Michael Brauer, Technical Architect Software Engineering
> StarOffice/OpenOffice.org
> Sun Microsystems GmbH             Nagelsweg 55
> D-20097 Hamburg, Germany          michael.brauer@sun.com
> http://sun.com/staroffice         +49 40 23646 500
> http://blogs.sun.com/GullFOSS
>