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

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

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.

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

> Second someone would like to link to meta data.

I still don't know what this means.

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

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

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

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

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

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.

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

Bruce