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

[Bruce D'Arcus <bruce.darcus@OpenDocument.us>]

On Jan 3, 2007, at 6:48 AM, Svante Schubert wrote:

> First, metadata can be stored as RDF XML that should be no problem at  
> all, second it is an often used scenario that data will be created  
> outside the ODF and than imported. Think of the sport team salaries,  
> which might be given as a RDF XML database dump.

If the user must be able to edit the content inline (the whole point of  
Elias' demo!), then it makes sense to me that the data would be  
converted to in-content metadata.

>> In general, I do not accept your presumption that this problem (a  
>> user splitting a property literal across nodes) is our problem, and  
>> that it should drive the design.
>>
>> Repeat: I reject this example.
> Sorry, the causality of your argumentation is not completely clear to  
> me.

That it is not something specific to our work. It is a GUI and  
implementation issue.

>>> 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.
>>
>> I am going to keep repeating this, since you seem not to be listening  
>> to me: this is not an acceptable solution. Your solution will break  
>> (you CANNOT use XPointer to bind to an RDF property with ANY kind of  
>> reliability), and is a needlessly complicated approach to a  
>> non-existent problem.
>>
> Certainly we can, and it is only a different design approach. Could  
> you please be more specific in your argumentation.

I explained this in detail off-list. In short, RDF does association by  
URI, and XPointer and XPath are all about XML trees.

To quote that mail with details:

The reason why RDF is such an extensible and scalable technology is  
because it has the simple data model, based on using URIs as  
identifiers. Those URIs serve the same function as foreign keys in  
relational databases.

RDFa is simple and elegant because it recognizes that. The attributes  
one adds to content nodes are pretty much just URIs.

So you get the seamless mergeability of data precisely because, for  
example, when you come across two subjects with the same URI, you just  
merge the statements.

By adding the non-RDF, non-standard (ODF specific) linking mechanism,  
you throw most of that away. You use a mechanism based on document  
location, rather than (URI-based names).

I didn't even talk about how much of a mess things become if you assume  
XML as a way to reference RDF. This example you gave  
"xmeta.xml##xpointer(id('Bruce')/v:fn)" will totally break in a lot of  
circumstances.

For example, say the name is a resource:

<v:VCard rdf:about="...">
   <v:n rdf:parseType="Resource">
     <v:given-name>Bruce</v:given-name>
     <v:family-name>D'Arcus</v:family-name>
   </v:n>
<v:VCard>

You can't rely on the XML structure to reference the properties. The  
above can also be represented as:

<v:VCard rdf:about="...">
   <v:n>
     <rdf:Description>
       <v:given-name>Bruce</v:given-name>
       <v:family-name>D'Arcus</v:family-name>
     </rdf:Description>
   </v:n>
<v:VCard>

... or:

<v:VCard rdf:about="...">
   <v:n rdf:resource="#name-1"/>
<v:VCard>
<rdf:Description rdf:resource="name-1">
   <v:given-name>Bruce</v:given-name>
   <v:family-name>D'Arcus</v:family-name>
</rdf:Description>

They're pretty much equivalent from an RDF standpoint (though in the  
first case the name resource is blank node, as opposed to one  
identified with a URI), and XPointer or XPath expressions will break in  
that context.

If you just use the triples and their component URIs, stuff won't break.

In sum, you keep thinking in terms of XML. Stop!

Bruce