Re: [office-metadata] summarizing recent suggestions

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

Svante.Schubert@Sun.COM wrote on 02/27/2007 02:18:57 PM:

> Hi Bruce, Hi Elias,
>
> Thank you for the summary, Bruce and both of you for your comments.
> Sorry for the delay, but I had to discuss these things, before I wanted
> to go back on the list.
> Find my comments in line:
>
> Bruce D'Arcus wrote:
> >
> > So based on recent discussion and comments from Elias, this is what I
> > see we need:
> >
> > 1) xml:id to identify ODF elements. Suggested schema:
> >
> >   xml-id = attribute xml:id { xsd:anyURI }
> Did you require on purpose only IRI for xml:id? We would change xml:id
> against it's W3C specification.
> If we require IRI, we won't need relative IRIs and would no longer be in
> need of base URLs, which you mention later in this mail.
>
> I understood that we would use xml:id as it had been standardized (using
> a "NCName" as value).

I believe you are correct. It might have been a typo in Bruce's rng, but
let's see what he has to say.

> RDF/XML might reference to those IDs using relative IRIs, which would be
> resolved to an absolute IRI according to the RDF/XML xml:base attribute
> or the ODF resolution mechanism for relative URL already descriped in
> chapter 17 of our ODF spec.

Yes, something like this, except we need to discuss a meta matter on
whether we can generate unique base-URIs for the documents.

> I further suggest to provide an informative note in our proposal of the
> possibility to use the W3C owl:sameAs attribute in RDF/XML to set RDF
> resources in ODF as equal even across document borders.

Very good. I like it.

>
> >
> > 2) Get rid of the get and set field ideas, and instead just add a
> > single metadata field to display content and associate it with
> > resource descriptions. Suggested schema:
> >
> >   meta-field = element meta:field { xml-id, [insert generic ODF
> > content pattern] }
> >
> > Note: in this approach all of the field logic would be encoded in
> > RDF/XML. Let's call this option A.
> >
> > An alternative (let's call this option B) would be to encode some of
> > it in the field (what I had been thinking, though I have no strong
> > opinion either way).
> You suggest to rename the earlier called "meta:text-get" to "meta:field"
> and you do not necessarily require RDFa to be specified for this field,
> correct?
>
> How does the ODF application 'knows', who is 'responsible' for creating
> the content based on metadata for this field? In our case, how do we
> find the responsible plug-in?

Via RDF/XML metadata.

> The parsing of all RDF/XML streams seems not a good option from sight of
> an ODF application.

If an ODF application will support ODF Metadata they'll have to parse it
one way or another. We should expect that metadata is always available to
the application and plugins and to think that parts of our spec could work
with just the content.xml might not be a good idea IMHO.

> But RDFa or even better a further optional attribute (specifying the
> implementation) might give us a hint about the responsible plug-in and
> would be helpful.

I also mentioned the issue of multiple plug-ins. Why just one attribute?

>
> >
> > 3) metadata attributes on certain content elements to encode their
> > content as object literals. Those attributes are (I am ignoring the
> > value and type stuff, but not deliberately excluding them):
> >
> >   meta-about = attribute meta:about { xsd:anyURI }
> >   meta-property = attribute meta:property { xsd:anyURI }
> >
> > # not sure if we need this now, or how to use it
> >   meta-resource = attribute meta:resource { xsd:anyURI }
> >
> > ... and the pattern would be:
> >
> >   meta-literal = meta-about, meta-property
> You suggest we should allow the usage of RDFa on our earlier set of
> xml:id elements. In contrary to the usage of an own element - we called
> it 'meta:text-set' - for those cases where the RDF vocabulary refers to
> the contained string as a RDF Literal instead of the ODF element.
>
> In this context, you forgot to mention Elias comment about the datatype
> attribute. RDFa gets the content as a XMLLiteral not as a string. Elais
> offered the datatype="plaintext" to be able to receive only text from
> the ODF element. Any link on this, Elias?

http://www.w3.org/2006/07/SWD/RDFa/syntax/#id0x03f5b7b8

>
>
> In theory, someone might say we do not even need a meta:field. For
> example, if there is a citation field generated by a citation plug-in,
> this RDF application could give it's text portion (the citation) some
> certain RDFa values and in theory this is well enough defined.

That's correct.

>
> In practice we have several kinds of text portions with metadata in the
> content, which are differently handled by an Office application.
> For instance, if a text portion is generated from a RDF application, it
> makes sense to clarify this, offering an own element. You proposed
> meta:field aligned to the ODF field mechanism.
> By an own element the ODF application can easily address this certain
> scenario.

I proposed meta:field with the intention of minimizing the number of
field-xxx elements we have, but in reality, I don't think we need them.
That's why I want RDFa attributes on most ODF elements so we can do what
you said.

>
> And now I believe there is a further differentiation helpful for the
Office:
>
> Take a look at the following example:
>
> ||<text:p rdf:about="http:/sun.employee/svanteschubert"
> rdf:property="http:/ex.creditcard-no">5268 3851 2144 9898</text:p>
>
> and
>
> <text:p rdf:about="http:/ex.chapter" rdf:property="ex:introduction">It
> was dark and stormy night.........many informations more.....</text:p>
>
> The first is some high sensible data, that will be most likely scanned
> by further RDF applications for further process.
> The latter on the other hand is simply a flag on the paragraph.
> Categorizing the embedded text, which seems to me different.
>
> Usually we offered in the specification an own element to emphasize such
> a scenario, therefore I still suggest an own element for the first
scenario.
> Although we would not define how an Office should handle such sensible
> data, but we would at least give the ODF application a chance to do it.
>
> Best regards,
> Svante
>

I'm not sure really what the difference is between those fields. The
"sensible" categorization is a bit subjective and we don't have
requirements for it. However, I'm happy by the fact that you were able to
express two different types of data according to your personal ontologies
using RDFa and didn't need an extra element to do so. This is the kind of
benefit that I see from the metadata proposal. I proposed meta:field (but
if there's already an ODF field element, let's use that) in the case where
we really need read-only data (edited via the ODF application or plug-in).

-Elias

>
>
> >
> > 4) to decide on base-URIs and such
> >
> > I think if we agree on the above -- and decide on the field approach
> > -- we're pretty much done with the core of the proposal, absent some
> > minor details and editing.
> >
> > Bruce
> >