Re: [office-metadata] Our discussion on the Wiki example

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

Hi Bruce,

Believe me I really like to speed up things, too.
It is very good that you showed up more options for different low level 
types of scenarios.
It seems a good idea to gather more details about design decisions 
before talking about the coding (e.g. RDFa).
BTW just phoned Elias and I do not think that our ideas are such far 
away - aside of where to move the meta data.
He stated that I had a new low-level requirement to state related meta data:

<text:p meta:class="myBook">
My favorite books is from
    <text:span meta:class="AuthorSurname">Tolkien</text:span>!
It's ISBM is
    <text:span meta:class="ISBN">8th</text:span>
it has
     <text:span meta:class="pages">1154</text:span>
pages
 </text:p>

The question now, how can this this referenced and written in RDF in the 
meta package?
Are the meta:class referencing to XPATH expression similar to the XFORMs 
approach in ODF?

PS: I think we are going the right way now. I will collect the different 
low-level requirements and design scenarios for the wiki tomorrow, I 
have to leave now.

Best Regards,
Svante


Bruce D'Arcus wrote:
>
> On Dec 4, 2006, at 12:46 PM, Svante Schubert wrote:
>
>> But what really bothers me is that it was designed for XHTML being a 
>> flat format. RDFa is about embedding the meta data. ODF is compound 
>> and anybody correct me if I am wrong, I was sure everybody figured 
>> out that these should be separated (without redundancy).
>
> This is indeed the difference.
>
> But note that I think -- for all the practical reasons that Elias and 
> I demonstrated -- we can't be puritanical about the no redundancy 
> idea. At minimum, we need to be able to include presentation content 
> in content.xml.
>
> For the citation example, one worry I have about moving all the logic 
> into the metadata file is the copy-and-paste problem.
>
>> We might as well step back and define the scenarios, we would like to 
>> show in Wiki as examples:
>>  For instance:
>>     1     metadata contains/reference additional data
>>     2     metadata specifies a unique content
>>     3     metadata specifies a class of content
>>  and collect basic design decisions we agree on, like
>>     1     No redundancy (no repetition of data from the content in 
>> the meta data)
>>     2     RDF compatible
>>     3     generic solution / coverage of use cases
>>     4     simple solution
>>  And afterwards we make proposals perhaps based on implementation 
>> like RDFa.
>>  Analyzing their dis/advantages and choose one. Does not sound to 
>> complicated nor time consuming.
>>  As Bruce was so kind to start with one example, I commented it asked 
>> for changes. I see no delay with this process.
>
> It depends. Certainly I can see three options for the citation case.
>
> 1. all field logic moves to the metadata file (as the example we 
> discussed)
> 2. the field logic stays in the content.xml file in a new field, but 
> using RDFa to encode it
> 3. as above, but using using specific XML elements for the encoding
>
> Generically, I see two options:
>
> a. an all RDF/XML approach
> b. a hybrid RDFa and RDF/XML approach
>
> The a option would still rely on being able to attach URIs (local or 
> global) to content.
>
> If we get beyond that, and start considering a number of other 
> options, then we'll easily take six months to get a proposal.
>
> Remember: it took us 9 months to collect the use cases and derive the 
> requirements. We now have two more to deliver the draft proposal. That 
> is not a lot of time.

>
> ...
>
>>> <table name="table1">
>>> ...
>>> </table>
>>> </body>
>>>
>>> Also, is ODF content/source copy and paste a requirement for our 
>>> metadata
>>> proposal? I didn't think it was. I hope we are not expecting people 
>>> to hand
>>> write ODF (e.g. no need for mnemonics).
>>>
>>
>>  Mnemonic approach is helpful for the writer, should be recommended, 
>> but is and can not requested.
>
> "Helpful" for what "writer"? A user will never see these, and a 
> machine doesn't care. What is most important is that the objects be 
> uniquely identified such that they can be reliably referenced. Tha's 
> all that really matters.
>
>>  I prefer - as already stated - the approach of attribute references 
>> between content.xml and metadata, which is not one of your approaches 
>> above - not #1 nor #2.
>
> Well, the question is the direction. His second example above simple 
> gives the table a name ("table1"), and one references it in the 
> metadata file ("content.xml#table1").
>
>>  In content.xml:
>>  ============
>>  ..
>>  <text:p meta:class="date">
>>      <text:span meta:class="month">May</text:span>
>>      <text:span meta:class="day">8th</text:span> at
>>      <text:span meta:class="time">10am</text:span>
>>  </text:p>
>>  ..
>>  [NOTE:
>>  I changed meta:id to meta:class to avoid the impression, that 
>> meta:id is unique. The naming 'meta:class' is not important for now.
>>  And the value of meta:id is just an arbitrary string. But here only 
>> provided as mnemonic default string by a brave plugin programmer. ]
>>
>>
>>  In meta package:
>>  ============
>>  something RDF compatible
>>
>>  This is a very simple approach. Everything seems to be accomplished 
>> by it, what advantage have #1 or #2?
>
> The advantage of this approach (metadata --> content) is that it's 
> also the same for Rob's "extrinisic metadata" use case. It also 
> involves no change to the content, since tables already get an id (the 
> table:name attribute) that is local to the document.
>
> And the model is clear:
>
>     <content.xml#table1> a odf:Table .
>     <content.xml#table1> dc:title "Some Title" .
>
> I'm not clear what you're modeling in your example Svante.
>
> ...
>
>>  Drafted in two sentence in general is my hopeful wish in linking the 
>> following:
>>  I would like to be able to create a link to a document pointing to a 
>> certain semantic not to a structure.
>>  Like pointing to the node set of all XML nodes having a certain 
>> class of meta data like Bruce's citation.
>
> Certainly with RDF you can define any property you want; e.g.:
>
>     <ex:xpathForAllCitations>//cite:citation</ex:xpathForAllCitations>
>
> Likewise, you can have a property to represent an xpointer.
>
> That doesn't mean we create some specific structure just to do that; 
> does it?
>
> We have a focused set of requirements that the TC happily agreed to. I 
> hope you aren't proposing to add a new one?
>
> Bruce