Re: [office-metadata] Metadata text fields

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

"Bruce D'Arcus" <bdarcus@gmail.com> wrote on 02/22/2007 11:22:24 AM:

> Svante,
>
> On Feb 22, 2007, at 10:02 AM, Svante Schubert wrote:
>
> > Scenario 1 - meta:text-set
> > This field sets a text as meta data (literal) and was named analog to
> > other ODF fields consisting of a 'set' postfix. There could be
> > certainly other names for this field being proposed.
> >
> > It is used, when in-content metadata should be attached to text, in
> > other words when a text in the content is equal to the literal in
> > the metadata. This text might be editable or read-only - that's an
> > Office implementation detail.
>
> It is, though I think part of the point of allowing in-content
> literals is precisely because they are user-editable. That's the point.

+1

>
> > However, there might be a plug-in that provides a user interface
> > that is customized for the mata data that shall be added.
>
> Try to be specific: you mean properties, yes? And "added" to what?
> Subject-predicate-object is useful for natural language too ;-)
>
> > This plug-in has furthermore the responsibility to keep the literal
> > consistent with further metadata in the document (e.g. RDF/XML).
>
> This is where the confusion keeps coming in. There's no need to be
> "consistent" here because the in-content text *is* the literal.
> There's nothing to be consistent with.

+1

>
> > The text can be formatted in various ways, e.g. in a text "Patrick
> > Durusau" the capital letter might have a different color and therefore
> > the text might consist of various ODF elements.
> > The RDF object literal would be created by concatenating all text
> > nodes
> > together.
>
> So you mean, what is the content of the literal, where you have a
> situation like ...
>
> <span
>      about="http://ex.net/1"; property="foaf:name">Patrick <span
> style="italic">Durusau</span></span>
>
> ...?
>
> You are proposing simply that it be the string "Patrick Durusau". So
> we define the content of in-content literals as a string, rather than
> an XML literal say.
>
> This is indeed something we need to decide.

Right. In RDFa, currently, when you get the element's content as a literal,
it's an XMLLiteral. However, there's this poorly defined
datatype="plaintext" that does what you want: to get just the text content
all of the element. We might need to improve on RDFa, but that's a better
way than forcing everything to a single element to get that behavior as
opposed to adding just an attribute.

>
> > Furthermore there might be different nested meta:text-set fields. The
> > example above might consist of three fields for name "Patrick",
> > "Durusau" and "Patrick Durusau".
>
> I think for the case of *literals* this raises the question -- which
> Elias asked -- of whether we really want to constrain the attribues
> to some new field, since the problem here will be more of a UI
> problem than an XML one.
>
> E.g. I'm not sure what constraining the attributes to a new field
> gives us that allowing them on spans (or, say, table cells) would not?
>
> > The new meta text field makes it easy for an ODF application to
> > distinguish text portion, which have to be kept consistent with
> > other metadata and should be made read-only, if no RDF application
> > is available to guarantee consistency.
>
> As I mentioned above, I think the read-only possibility would only
> likely accompany cases of object resources, and "consistency" isn't
> really relevant here (nor in our requirements anywhere).
>
> So I wonder why we don't forget about this field, and just allow the
> literal pattern to appear on some specific list of elements? We
> might, then ....
>
> > Scenario 2 - meta:text-get
> > This field displays a label generated from a RDF application (plug-
> > in) based on existing metadata in the content.
>
> ... have one new field whose job it is to display information about
> *resources*.
>
> I want to say in my document that Patrick is the author, but I have
> Patrick vCard record already in RDF/XML in the package, so I do
> something like:
>
> <meta:field
>    meta:about="urn:uuid:8134713815475740574" <!-- document URI -->
>    meta:property="dc:creator"
>    meta:resource="http://ex.net/people#patrick";>Patrick Durusau</
> mta:field>

+1. From what I gather from Svante's email we definitely need a read-only
solution for both ODF applications and plug-ins to have space in the
content to render content. But that's very different from *actually*
encoding information. I'd would go as far as suggestion that all we need
is:

<meta:field
    meta:id="foo">Patrick Durusau
</meta:field>

If the plugin is not present, then ODF application renders the content of
the field, else the plug-in(s) can find their metadata in the RDF/XML
files.

>
> > The field was named analog to other ODF fields consisting of a
> > 'get' postfix. There could be certainly other names for this field
> > being proposed.
> >
> > An example for this field are citation fields, which might
> > be expressed in different ways as a 'long' or 'short' citation field.
> > The user could configure the layout of this field, which would be
> > created based on metadata. Furthermore, could the user exchange the
> > layout for all fields by the plug-in, which would exchanged the fields
> > for all occurrences in the text.
>
> Right, because the citation use case involves users choosing one or
> more resources, and formatting is generated based on that source
> metadata.
>
> > The mapping of metadata to label is based on a algorithm known by the
> > plug-in. This algorithm might be quite complex, e.g. the label 'last
> > Friday of the year' might be based on a date and created by a plug-in.
> > In case the plug-in is not available to handle this field, the label
> > should be made read-only, although this might be implementation
> > specific.
>
> Sounds fine to me.
>
> Bruce