Re: [office-metadata] summarizing recent suggestions

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

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

>
> 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?
The parsing of all RDF/XML streams seems not a good option from sight of 
an ODF application.
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.

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


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.

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.

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



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