Re: [office-metadata] Our discussion on the Wiki example

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

Hi Bruce,

thanks for your feed-back, find my comments in line.


Bruce D'Arcus wrote:

On Dec 1, 2006, at 1:53 PM, Svante Schubert wrote:

Instead of "meta:about="urn:uuid:fe107eb0-7704-11db-9fe1-0800200c9a66", we might use in our case meta:id="citation". It's mnemonic and the value of the meta:id (which is not a xml:id as it does not have to be unique, when expressing a type) would be offered during meta data creation by the ODF application component, which is responsible for this type of meta data.

But how is that it's "mnemonic" intrinsically valuable? I don't think it is.

For the same reason as for naming ODF elements for instance "office:body" instead of "107eb0:7704". It is simply the human readability of ODF.
As well, easier to edit by human. You would recognize easier copy&paste errors, for instance when there is a different URI in meta:about and in the manifest, like even you did in the example. ;-)

By this it is imaginable that even the implementation of metadata is being exchanged in meta.xml, without a byte changing in the content.xml. Imagine implementations like vcard vs. hcard.

Am not following here. Can you restate?

Sure.
There are always different ways to state the same semantic, like informations about persons using vcard or hcard.
And certainly there are descriptions how to transform grammar into the other.
This might be transformed in the metadata folder without touching the content.xml.

Second someone would like to link to meta data.

I still don't know what this means.

I have in a document some meta data expressing a name as employee of my company.
If I want to link to these employees, I don't want to define the document structure(s), where they are embedded, but simply want to link to the semantic of 'employee'.

Instead of referencing to a certain structure (e.g. third paragraph of the body) a link to the type of meta data in the package is closer on the desired.

Sorry, again, am not understanding. Been a long day I guess.

No problem, I wrote the email on the end of day as well, so I play my part in this, Don't blame yourself ;-)

Your question is related to the earlier mentioning to link the semantic not to the structure

Although I have no fool proof implementation by hand (XPointer?), would such approach solve the problem of changing structure.

Can you explain what you mean by "changing structure"? Is this is the split-paragraph example?

The structure like the number of paragraphs you used before the desired information might change frequently or be uncertain. Therefore it is a bad idea to link to to the Xth paragraph where once the semantic was in.

This approach might exist aside of new introduced xml:id, which could be generated by the user when the document is ready to publish. xml:id should be stable similar to the API / interface of a software and therefore handled with care.

And finally, when our goal is to weave arbitrary metadata into ODF in a most simple, generic way, I was distracted by @content - as Bernd as well before <meta property="cal:dtstart" content="20060508T1000-0500"> May 8th at 10am </meta> There is detailed redundant information in the attribute and as well there is a blob of data.

Why is this a problem? One is for machines, and one for people.

Redundancy is the problem. Human work on with the document, changing only the human viewable parts. The copy for machine & the copy of human information become inconsistent. And even if they are staying mainly the same. No way for the machine to validate if the information to be still consistent. If you can not trust the information, it is lost.

In general I would rather prefer something like:

<text:p meta:id="date">
    <text:span meta:id="month">May</text:span>
    <text:span meta:id="day">8th</text:span> at
    <text:span meta:id="time">10am</text:span>
</text:p>

No, Svante. That's certainly not how you'd do it in RDFa. The ID is just that: an id that allows one to then associate something else with it (a link, metadata descriptions, etc.). It indicates no semantics at all. Using dumb strings of text for semantics is no more useful than just using styles.

Closing the circle, we are back at mnemonic ids.
There is no rule that the id's should express any semantic, but it can help a lot when the XML is reviewed by a human and that is one advantage of XML.
If as these ids are offered/given by the component/plug-in, which takes care of the meta data, there is no human interaction required to bring in the semantic into the IDs, either.

or shorter using default namespace (and none for the attribute) as

<text:p s="date">
    <a s="month">May</a>
    <a s="day">8th</a> at
    <a s="time">10am</a>
</text:p>

By doing so, other software aside of the correct plugin, would have a chance to interpret the data.

OK, I think you need to step back and ask what problem are you trying to solve here? It seems to me you want to be able to bind a GUI to data, and then to particular application behavior (which could be a plug-in). E.g. say someone wants to add custom content processing; how do you do that? How does a plug-in know which content and which metadata to deal with?

Now it is my turn to ask. What do you mean?
Different vendors implement different plug-ins for different meta-data. Like various vendors for citation.
Aside of this, there should be one default installed plug-in, which take care of meta data if there is no certain plug-in installed.
All these questions for the big picture: how to get the correct plug-in - questioned by the ODF application - or is there already a grammar (and plug-in) for my semantic - questioned by an ODF editor -, are not asked, yet. These application problems might need some help from the ODF as well.

Is that right?

If yes, the manifest can also be used for this, as well as some similar typing on custom fields.

For example the fall-back plugin of an ODF application (which assist the user in showing / editing meta data, when the correct plugin is not installed / found), would be able to assist the user.
Even more when the the possible set of data (e.g. all month) is defined in an embedded grammar,

OK, remember, what you are calling an "embedded grammar" is exactly what RDFa provides.

I see RDFa as a very good opportunity to learn from, but as HTML has one plain document and we are a compound package we have certain advantages we should use.

further features would be possible. For instance 'auto completion' or 'drop down list' for the content of such a field are thinkable for the future even for the fall-back plugin ( but most likely not in it's first version).

Sure, though where the metadata is is not significant; is it?

Just a use case how the end user might benefit from meta data.

Bruce

Keep on enjoying your week-end,
Svante