Re: [office-metadata] Groups - Metadata SC meeting added

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

Bruce D'Arcus wrote:
>
> On Apr 3, 2007, at 7:37 PM, patrick@durusau.net wrote:
>
>> 2. Do we include suggestions for serialization? To be discussed.
>> 3. How do we deliver non-normative documentation? To be discussed.
>> 4. Deciding on the ODF RDF vocabulary. To be discussed.
>
> The most critically-important TBD is the field.
>
> The above items are pretty much covered already (we agreed to put 
> documentation at the namespace URI), or can be pretty easily outside a 
> concall (the serialization suggestions).
First we should cover the points that are "pretty much covered" before 
going to start something new.

Following nearly-covered points need our attention as well:

    * Do we require 'a hint' - similar to rdf:type in the manifest - at
      the text:meta-field to help to establish a relation between
      text:meta-field (the office) and a plug-in. Our last stand was
      adding meta:category (now m:category). More consequent would be
      the usage of rdf:type similar to the metamanifest. The difference:
      in the metamanifest we are able to have multiple rdf:types
      elements on one entry, but we can have only one rdf:type attribute
      on the element.
      But we might even neglect the type on the field, by a
      office/plug-in scenario as the following:
         1. A plug-in would register for certain rdf:types.
         2. The office would read the metadata manifest and find a
            responsible plug-in based upon the registered rdf:types for
            certain RDF/XML entries.
         3. The plug-in would read it's entries (RDF/XML files) and
            would find IRIs in it it related to odf:elements.
         4. Plug-in would announce responsibility for these IRIs
         5. Based on the binding the office would be able to map the
            IRIs to xml:ids.
    * Usage of office:value / office:value-type. This additional type
      information is added by using existing office attributes. We
      should consider to map the possible attribute values to RDF IRIs.
    * Our RDFa always consists of m:about for the RDF subject and
      m:property for the RDF predicate, the ODF element is always the
      object. As these attributes are not specified somewhere else, we
      have to specify what is being used as a value. Currently we
      specified that by default the ODF element returns as RDF object a
      string (RDF literal). By this using RDFa would avoid
      string/Literal duplication in the RDF/XML, which is a great
      benefit against RDF/XML only usage.

Svante