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

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

Bruce,

Bruce D'Arcus wrote:
>
> 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 the demo the user edited a calc document in OOo. On what kind of 
inline do you refer?

>>> 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. 
This is exactly a problem that will occur for the ODF implementation for 
which we are suggesting the metadata ODF model.
If the problem is solvable by some types of metadata ODF model we have 
to consider this, otherwise we act careless.

>>>> 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.
You might have missed that I wrote that it is an ODF application 
implementation detail, which does not have to be RDF related.
If the ODF package provides RDF XML and the API of an ODF application 
provides RDF related terms, you should not be afraid of what is used 
behind the scenes to solve problems for the users, which might be 
unsolvable with RDFa.
>
> 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.
The RDF XML is the persistence unit of your package, it represents the 
RDF triple(s) to the next URI notated subject to the time it is being saved.
XForms uses XPath expressions to reference to content similar the ODF 
application relate internally here to metadata.
The structure won't brake as it is organized by the same unit, which 
does the references.
>
> 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!
See the different layers. We have the users - you are referring to, 
which will in both cases RDF XML (not the mapping table with XPointer) 
and a RDF related API and we have the ODF Application organizing 
internally the metadata, which might use XPointer or any XML related, 
standard base utility.

There is a difference..

Svante