Re: [office-metadata] Multiple content nodes representing on RDFsubject

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

Happy new year 2007!

Recuperated let's continue to find a solution for the handling of our 
latest problem scenario:
"The content of multiple ODF nodes are represented by the content of a 
single RDF XML node".
The examples later given will clarify this scenario.

(I ignored Bernd's recent example as I received it after I finished this 
mail).

Bruce D'Arcus wrote:
> On Dec 28, 2006, at 12:09 PM, Michael Brauer wrote:
>
>> the intention behind Svante's example was to show that there is no
>> one-to-one relation between XML elements and RDF subjects. An RDF 
>> subject actually may be composed of several XML elements. This is at 
>> least the case if the subject is a text fragment. That's the reason 
>> why Svante proposed to add something like a <content> element that 
>> combines the individual <text:span> elements into a single RDF subject.
>
> Yes, I understand the problem (I think). I just don't agree with the 
> solution :-)
>
> The way that one binds statements to a subject in RDF is through the 
> names you give the subjects; the URIs.
>
> For example, from the RDF perspective, this ....
>
> <rdf:Description rdf:about="x">
>   <ex:foo>one</ex:foo>
> </rdf:Description>
>
> <rdf:Description rdf:about="x">
>   <ex:bar>two</ex:bar>
> </rdf:Description>
>
> ... is fully equilalent to this:
>
> <rdf:Description rdf:about="x">
>   <ex:foo>one</ex:foo>
>   <ex:bar>two</ex:bar>
> </rdf:Description>
>
> The reason is because you're using the name/URI to do the association, 
> and each property is -- from the model standpoint -- a discrete 
> statement about that resource. It doesn't matter where it is.
>
> Svante was wanting to use a completely different mechanism (XPointer) 
> to do association that will not mix well here.
Just to be sure that are talking about the same scenario:
The RDF/XML example given above is a valid example about abbreviations 
for RDF subjects using multiple property elements, it does not reflect 
the problematic scenario I intended to show, when I started this thread.
A renaming of the predicates will clarify it: If ex:foo is the 
ex:forename "one", and ex:bar is the ex:surname "two", there is no real 
problem to be solved. But if one of those string literals is split into 
various ODF elements - possibly scattered over the document - our 
problem scenario arises.

A example earlier in this thread showed it, where I split the name 
"Bruce D' Arcus" by a table element. In the end of the mail, I picked it 
up again and improved this example.

>> I agree that in his example it would be valid to interpret the three 
>> <text:span> elements as individual subjects, but I don't think this 
>> is valid in all cases. If the meta data is for instance a description 
>> of some text (for instance for accessibility purposes), then you must 
>> not break the text into pieces, because this changes the meaning.
>
> I think the practical use case examples here are useful. Can you 
> explain this a bit more?
>
> When I wrote the accessibility use case, I was thinking of fairly 
> simple examples, like an embedded image includes a fuller RDF/XML 
> description in the package that can be used to present further 
> information to the user.
>
> An analog for the in-content case might be if a document has a link to 
> a client resource. So maybe we have:
>
> <text:p xml:id="1">Some client <text:link 
> meta:resource="http://ex.net/people/1"; meta:property="ex:client">Jane 
> Doe</text:link>
>
> There might be further metadata in the package that can be useful for 
> accessibility purposes to present further information about the 
> resource named <http://ex.net/people/1> (and labeled "Jane Doe").
>
> So the question is, how to identify the subject, such that one can 
> make further statements about that subject elsewhere in the document.
>
> One answer is meta:about.
>
>> Other cases are annotations that may be added to arbitrary text the 
>> user selects, and which may include paragraph breaks. And I'm sure 
>> there are other use cases where an RDF subject must consists of 
>> several XML elements. Please let me know if you would like to have 
>> more detailed examples for this, and I will provide them next year.
>
> See above. Some more detailed examples of the problem would be helpful.
>
> On annotations, for example, I would expect to do:
>
> <text:p xml:id="1">...</text:p>
>
> ... and:
>
> <rdf:Description rdf:about="content.xml#x">
>   <ex:foo>one</ex:foo>
> </rdf:Description>
>
> IF we want to allow the user to select text that spans paragraphs and 
> then to annotate THOSE (do we??), 
In the opposite we might ask ourselves how shall the application 
disallow it? How does an ODF metadata application should handle these cases?
A solution embraces these scenarios, it will certain ease the life of 
ODF application developers and enlarge the feature set of the end user.
Furthermore, imagine if someone receives a ODF document containing 
metadata, but he has no plug-in for the contained metadata.
If there is a fall-back instance for handling unkown metadata, how 
should a default plug-in be aware, if the metadata is similar to the 
content (e.g. surname) or something as an 'important' flag? We can not 
ignore this cases.
> then I agree we might have to do some gymnastics. But I'd prefer to 
> keep them standard RDF (and get some feedback from the RDF experts on it).
I completely agree on this. Only standard RDF should be used.
Let us assume that to solve this scenario, the ODF application (or it's 
metadata extension) would handle the scattering of a single metadata by 
ODF elements as an ODF implementation detail. Splitting and 
concatenation of the scattered metadata would be encapsulated by the ODF 
application and shielded from RDF aware implementation, which are only 
interested in the concatenated literal.

Here a modification of the earlier used example in the thread, which 
shows a draft a first design using xml:id to solve this specific scenario:

In the content.xml something similar to this is used :

<text:p xml:id="_foo1">Dave </text:p>
<table:table>...</table:table>
<text:p xml:id="_foo2">Beckett</text:p>

We have the literal "Dave Beckett" splitted by a table, which is 
equivalent to the content of a metadata RDF XML node.
(Obviously there are more realistic scenarios for this problem, for 
simplicity I stick on this.)

We have in RDF XML metadata the following
<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar";>
  <ex:editor>
    <rdf:Description>
      <ex:fullName>Dave Beckett</ex:fullName>
    </rdf:Description>
  </ex:editor>
</rdf:Description>

And as an implementation detail the following - not aware for RDF 
applications - a relation between the XML snipplets above:
Representing the relation of the metadata and content:
<meta:relation xml:id="_fooA">   
    <content>
        <part xlink:href="content.xml#_foo1"/>
        <part xlink:href="content.xml#_foo2"/>
     </content>
    <metadata 
xlink:href="mymeta.xml#xpointer(rdf:Description[rdf:about='http://www.w3.org/TR/rdf-syntax-grammar']/ex:editor/rdf:Description/ex:fullName)"/> 

</meta:relation>

In this first design step several problems and simplifications have been 
neglected (e.g. content duplication). It should only show the 
possibility of using such a design to solve this problem scenario.

Regards,
Svante