Re: [office] Please put this discussion

["Florian Reuter" <freuter@novell.com>]

Hi Bruce,

Automatic mapping does really makes no sense IMHO.
Your sample is bad designed from an RDF point of view IMHO. What you really want is
<rdf:Description rdf:about="[some-uri-the-maps-to-id]">
  <rdf:type rdf:resource="ecma.office-open-xml.field:FORMTEXT"/>
  <dc:description>Just a sample field.</dc:description>
</rdf:Description>
(or something like this..  need to think about this) and this can't be done purely automatically.

I understand your desire to map everything to RDF. But I think it its not a good idea. We have bookmarks and an API for this. All I'm trying to do to seperate real "user" bookmarks from "script generated" bookmarks adding some syntactic suggar like (name, value) pairs instead of a generic string. The API for fieldmarks is the existing API as for bookmarks with just an additional flag...

~Florian


>>> "Bruce D'Arcus" <bdarcus@gmail.com> 05/06/08 3:33 PM >>>
On Mon, May 5, 2008 at 5:28 PM, Florian Reuter <freuter@novell.com> wrote:
> Hi Bruce,
>
>
>  > define the function and semantics of fields,
>
>  I guess here is the misunderstanding. Field-marks --- as well as bookmarks --- do not have a semantic like e.g. RDF with the underlying triple model etc. They just provide scripts a way to mark parts of the document. As bookmarks provide a way for users to mark parts of the document.

I'm not asking for RDF-like formal semantics; just asking for a
description of what this field would do. A user bookmarks a section of
a document so that they can easily go to it. It provides a
user-defined anchor.

What you are asking for is different, though (which is indeed your
point, I think; that devs are abusing bookmarks, so we need something
else).

>  And here is --- I guess --- a main difference between field-marks and meta-data fields. Meta-data field have a semantic defined by the underlying RDF-based framework. Field-marks as well as bookmarks don't.

But at a higher level, what does the "RDF-based framework" provide? it
provides extensible metadata support. What is an arbitrary key-value
in a field but a simple example of that?

>  > OK, fine, but I'm just asking you to explain the "clear difference" you note above.
>
>  As I tried to explain. My view of the "clear difference" is that when you use metadata-fields then you use the power of an RDF-based framework and thus imposing a special semantic. When using field-marks you do not have a formal model behind.
>
>
>  > If it's clear, then surely you can say more about than that it's a compatibility mechanism for OOXML?
>
>  Since OOXML fields are just bookmarks for scripts [in difference as bookmarks for users] they don't have an underlying framework or meaning.
>
>  I guess the question is then can we map OOXML fields to our RDF-model and the answer is yes. RDF is pretty powerfull and I really believe you can express every OOXML field and script-controlled bookmark in the RDF framework. [Despite the fact of not properly nested bookmarks and OOXML fields spanning paragraphs.. ;-].
>  *BUT* the transformation can't be done automatically in a converter or import filter. Designing RDF triples and RDF schemeta is a complex process and when you do it wrong you can't really gain the full power of RDF. So my "yes" to "mapping from  OOXML fields and OOXML/ODF script controlled bookmark" can be done under the condition that a qualified human does it in a manual process.

OK, I've not been thinking about these details for awhile, and am
really busy with other things, but it seems to me that if we take your
example on the wiki:

<text:p>Title: <field:fieldmark-start text:name="Text1"
field:type="ecma.office-open-xml.field.FORMTEXT"><field:param
field:name="Description" field:value="Just a sample
field."/></field:fieldmark-start>A sample
input.<field:fieldmark-end/></text:p>

.. I *think* this *could* (not saying it should ATM) be expressed like
this using RDF and the text:meta-field:

<text:p>Title: <text:meta-field id="1">A sample
input.</text:meta-field></text:p>

... with the logic described like:

<rdf:Description rdf:about="[some-uri-the-maps-to-id]">
  <rdf:type rdf:resource="ecma.office-open-xml.field:FORMTEXT"/>
  <field:name>Description</field:name>
  <field:value>Just a sample field.</field:value>
</rdf:Description>

... or probably more technically-correct:

<rdf:Description rdf:about="[some-uri-the-maps-to-id]">
  <rdf:type rdf:resource="ecma.office-open-xml.field:FORMTEXT"/>
  <dummy:Description>Just a sample field.</dummy:Description>
</rdf:Description>

That's easy to automate (though mapping the token to a full URI in the
second case is of course a little awkward), isn't it? No need for
schemas or anything.

Again, maybe I'm being a little dim, but I'm just wanting to
understand how we relate these two fields. Is it really enough to just
say that, in essence, one is for simple key-values, and the other is
for (optionally) more complex custom data?

>  As a similar example: XML and RDF. My guess would be that you can transform every information encoded in XML documents to RDF. However I'm not aware that this process can be done automatically nor that anybody is trying this. It requires an understanding of the data and involves some tough thinking and good design, right?
>  When you just replace XML with field-marks I hope you better understand my point.
>
>  Field-marks are designed to provide a way to preserve the information in an automatically convertion process between OOXML and ODF without mixing up user-bookmark and non-user-bookmarks. Meta-fields are designed to give parts of the documents a semantic/meaning by empowering the RDF-based framework. Mapping field-marks to RDF is a really good idea --- but its not a good idea to try to do it automatically IMHO.
>
>  But I understand you concerns. Clearly we want people to use the RDF-based framework and but some thinking into good RDF design. So having a way round is risky;-) However having bad and meaningless RDF tuples generated by an automatic conversion process is not a good idea too.

Sure, we want whatever approach is appropriate.

>  So how can we leverade the RDF-framework? And here is a very innovative idea;-) Why not remove the text:field-mark from the proposal and only allow text:fied-mark-start and text:-field-mark-end. This would make dealing with field-marks harder for XML-processing apps and thus developers might softly be forces to take a look at the text:meta-field?? [Really don't know whether this is a good idea --- so please consider it as a statement made in a brainstorming session].

I think ideally that making things harder with one approach to
encourage another is not a good idea. Am just wondering if we can't
have our cake and eat it too (easier for all, and more powerful)?

I would expect that as implementors add support for RDF and
text:meta-field, one would work with these (text:meta-field) fields
using a really simply API. I guess the question is whether there ought
to be two custom field APIs.

And, yes, using the text:meta-field is harder if you're just using XML
tools and APIs than your example.

There are really two issues here it might be useful to break apart:

1) the in-document field marking (element containment in
text:meta-field vs. the start/end pattern you want)

2) (meta)data encoding (RDF triples in text:meta-field vs. simple
key-value in your's)

Bruce