Re: [office-metadata] Re: {spam?} Re: [office-metadata] clarifying fieldsand metadata

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

"Bruce D'Arcus" <bruce.darcus@OpenDocument.us> wrote on 03/13/2007 12:15:21
PM:

>
> On Mar 13, 2007, at 10:48 AM, Svante Schubert wrote:
>
> > Bruce D'Arcus wrote:
> >>
> >> Svante Schubert wrote:
> >>
> >>> Why not take 'meta:property' to describe the label you are using?
> >>
> >> Because it's semantics are different. It encodes a predicate, while
> >> here you want to say which predicate to use for display.
> > Isn't this only a difference in RDF vocabulary?
> > Does it makes any difference if meta:property describes the element
> > content to be a vCard:FamilyName or citation:FullQuote? Both times
> > metadata is being attached to the ODF element.
>
> Tell you what: if Elias is fine with this, I won't protest. It's up to
> him as far as I'm concerned.


Wait a minute. I'm not agreeing to that.... at least I have not followed
this aspect too closely. At the end of the day a plugin can do what it
wants and decide to use the meta:property to look up a display property
when using a text:field but we shouldn't specify that. I think we need to
have a clear specification (no dual-purposes) of what do the attributes
generate e.g. triples and let the implementors show us the rest once we
have some real-world experience.

In Svante's example, he uses the property to explain what the text value of
the element means, the rest he's pushing to the RDF/XML. If you really want
to be specific about what does your triple mean take it to the RDF/XML then
would something like this work for you?

<text:p xml:id="foo">bar</text:p>

in RDF/XML

<content.xml#foo> rdf:type cite:Citation ;
      cite:displayProperty vCard:FamilyName .

I think that overloading too many meta:attributes on our first pass is very
dangerous. Let's meet the requirements of extraction, extensibility,
naming, in-content metadata, etc. but not over do it.

-Elias

>
> ....
>
> >> I'm not sure. Would you advocate *requiring* this?
> >>
> >> <text:meta-label
> >> meta:classification="http://opendocument.xml.org/meta/fields/
> >> citation">
> >> (
> >> <text:meta:label
> >>     meta:about="urn:isbn:98347823"
> >>
> >> text:display-property="http://opendocument.xml.org/meta/fields/
> >> citation#citation-full">Doe 1999</text:label>,
> >> <text:meta:label
> >>     meta:about="http://ex.net/1";
> >>
> >> text:display-property="http://opendocument.xml.org/meta/fields/
> >> citation#citation-short">1999</text:label>
> >> )
> >> </text:meta:label>
> > Your example seems valid to me,
>
> Right, but I'm saying a plug-in (or other code) might assume a default
> display property. So would you require it be explicit in the content?
>
> > but might as well been written as (still using the discussed xml:id):
> >
> > <text:meta-label xml:id="myID"
> > meta:classification="http://opendocument.xml.org/meta/fields/
> > citation">
> > (Doe 1999, 1999)</text:meta:label>
> >
> > Providing similar RDF triple in RDF/XML without giving detailed
> > information about the subparts of the label as we won't specify the
> > subparts of the string "14th of December", neither.
>
> Let me tell you my worry about this for my use case. I don't know if
> this worry is based on sound engineering principles, but it's a worry
> nevertheless.
>
> To me, I really have the impulse to want the URIs that identify the
> source(s) and the optional parameters for the citation in content,
> since it's of critical importance to the logic of the field. In fact,
> the RDF/XML data can always be re-gathered if it gets lost somehow, so
> long as those URIs are there.
>
> So I get really nervous with the idea of leaving the label in text as a
> completely dumb container.
>
> To generalize my citation field (the one already approved) though,
> would mean a somewhat more complex field; something like:
>
> text:meta-field
>    text:field-source
>    text:field-body
>
> That way I could put multiple references to RDF subjects in the
> text:field-source element.
>
> One of the reasons I floated this idea earlier is that it's also
> structurally similar one of the field structure in OOXML.
>
> Now, no flames please: I just raise this issue because I want us to
> clarify the details. This gets into bigger principles, of course, like
> when the URIs and such should be in content, and when in RDF/XML.
>
> Bruce
>