Re: [office-metadata] Metadata text fields

[Svante Schubert <Svante.Schubert@Sun.COM>]

Bruce,

Bruce D'Arcus wrote:
> 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.
Correct, but it is application specific how you set the value, by a 
additional pop-up window or even in the text.
>
>> 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 ;-)
The plug-in might provide a special user interface, e.g. like a pop-up 
window and takes care about the content of the meta text field.
The metadata is usually "added" using RDFa as the plug-in has a certain 
view on the given text, but further RDF statements might relate by using 
the (currently) meta:id attribute of the field.
Does this answer your question?
>
>> 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.
Unfortunately there is no guarantee that the RDF statement - where the 
literal is part as the RDF object - is unique in-content only.
Aside of an usage in RDF/XML, there might be even the same in-content 
RDF statement a couple of times in the document. I would optimistically 
assume that if you change one, you change them all.
>
>> 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.
Yes, we might want to keep it simple and avoid these problems by 
introducing a meta text field, from where we assume that text meta data 
is being 'attached' to.
>
>> 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?
It gives us a good start for an implementation.

>
>> 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 ....
Possibly his has clarified as your opinion about consistency might have 
changed.
>
>> 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>
Can you give me the RDF triples you are telling here and do you refer to 
the RDF/XML spec when you talk about a resource? Any link?
Would not be one triple sufficient for the beginning?
>
>> 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