Re: [office-metadata] Metadata text fields

["Bruce D'Arcus" <bdarcus@gmail.com>]

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.

> 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.

> 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.

> 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>

> 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