[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-metadata] Multiple content nodes representing on RDFsubject
Hi 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.
Elias demo was impressive, and I think had several aspects. Editing the data was only one
of it.
Actually, if we consider the ability to edit the meta data inline to be the whole point,
then I personally would consider to check what we can do with XForms. XForms provides a
binding from an XML instance (which may be an RDF-XML instance) to form controls that may
be used to change the content of the XML instance.
[...]
>
> 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.
What you describe for the VCard entry actually also applies to ODF. There are several
representations of one and the same content possible in ODF, too. For this reason, it
seems to be reasonable to decouple meta data and ODF content as much as possible. That's
exactly the reason why I'm in favor of assigning meta data to ODF objects in the content
by IDs instead of adding the metadata to the content directly. However, I'm only in favor
of this solution from the office document perspective. Since I'm not a meta data expert, I
don't know whether this solution is really sufficient.
I agree that using XPointers to link metadata to the content or vice versa is not very
appropriate, unless one restricts the permitted XPath expressions to those that are known
to work even if the physical XML representation of the document changes.
Wouldn't it be an option to reference the meta data from the content by adding text fields
that make use of well defined structure of RDF? If I want to display your last name, then
I could write:
<text:meta-field meta:about="..." meta:property="v:n/v:family-name">D'Arcus</text:meta-field>
Please note that this does not define any metadata, but only references it. This means,
the semantic of this field would be display the object that you get by starting with the
node denoted by the meta:about attribute, and by following the v:n and v:family-name
predicates. The semantic of this field of course would be ODF specific. But this wouldn't
matter, because the meta data itself would be contained in the meta data stream.
This text field could also be used to display date and time values using the already
existing ODF data formats.
Just an idea.
Michael
>
> 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
>
--
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH Nagelsweg 55
D-20097 Hamburg, Germany michael.brauer@sun.com
http://sun.com/staroffice +49 40 23646 500
http://blogs.sun.com/GullFOSS
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]