Re: [office-metadata] summarizing recent suggestions

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

On Feb 27, 2007, at 2:18 PM, Svante Schubert wrote:

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

Ouch, no; sorry, my mistake.

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

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.

I personally think the field should be typed in some way. E.g.  
something like:

<meta:field xml:id="0874801373 field:type="http://ex.net/ 
Contact">foo</meta:field>

I think Elias proposed that be encoded in the RDF/XML.

I have to say for my citation field I'm a little nervous about  
leaving all of the logic for the RDF/XML.

My alternative would be sometning like:

<field:field field:type="http://ex.net/Citation"; xml:id="0874801373">
   <field:source>
     <meta:link meta:resource="urn:isbn:98239809" cite:pages="23"/>
     <meta:link meta:resource="http://ex.net/1"/>
   </field:source>
   <field:body>
     (Doe, 1999: 23; Smith, 2004)
   </field:body>
</field:field>

I think it's just a practical matter how much the field should  
contain to best enable document portability, including across file  
formats (say OOXML; which looks more like the above).

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

Correct.

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

Yes, I left that out, but agree it should be in, and would support  
Elias' suggestion on the datatyping.

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

True, except that the display/editing application needs to know how  
to display the element content, right?

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

I think your word choice of "sensible" here is not quite right. Am  
not quite sure what you're trying to say here.

Bruce