OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [Fwd: request for comments on OpenDocument RDF]


In my view, there are roughly three aspects under which the meta-data
topic is to viewed. I view them as kind of stages or levels...
I am of the strong opinion, that each of these topics should be
discussed seperatly, in order to keep some structure in the debate.

1. Mapping of what is currently in OpenDocument:
As Bruce and other have pointed out, there is nothing that prevents
anyone from interpreting meta.xml as RDF. Meta.xml is not in RDF/XML
syntax, but that doesn't matter, as long as there is a clearly defined
way to map meta.xml into the RDF data model. Anybody, who whishes to get
RDF about an OpenDocument file can use meta.xml and interpret it in this
way.

2. Putting more information in (and getting int out again in a
meaningful way)
This is where the debate is getting most confusing at the time I belive.
  There are a lot of opinions on where that information should be putand
what syntax it should use. There are a lot of opinions out there whether
it should just support RDF or use RDF/XML syntax. Whether it should be
interleaved with document content and so on...

Meta.xml is the place to put metadata, and I belive that this should
stay that way. I don't think we should start interleaving metadata with
actual content. If you want to make metadata statements about specific
things in the content, see (3).

So what should the processing model be for RDF applications using
meta.xml? Should we just say "put all your statements in there and let
the application worry abou it."? I don't think so.
I think of a new container element for meta.xml, which has some
attributes, that tell the application, what kind of metadata is stored
in that element. The element can even be used to link to metatdata that
is stored elswere (inside or outside of the packe).

The process model also needs to be defined, when a statement from
additional data is in conflict with what the original metadata said. In
my opinion, the original metadata should always be regarded
authoritative here. Otherwise, applications can add their own metadata,
while breaking everything, that uses the original OpenDocument 1.0 meta
data schema.

3. Making Statements about parts of the Content
To make statements about something in RDF, that something (i.e subject)
needs to have a URL. This means, that in order, to make express in
metadata the zodiac sign of the author's poodle, which might be
mentioned in the text (I think Stefano Mazzocchi brought this one up) I
would need a URL, that points to the place (or places) of the document,
where the poodle is mentioned.
This requirement isn't even restricted to metadata.

(side note:)
An intersting discovery I have made while pondering this is, that this
isn't much different from the way styles work. (More like CSS though,
since it uses a selector to apply a style to parts of a document. RDF
uses URLs as selectors, to apply meta-information to resources. In CSS,
this information happens to be styles, so the prefix is always implied)

XPointer comes to mind here, but only a subset, since schema based
location of resources in OpenDocument would be a complicated requirement
for applications, since schema persitence through editing cycles
wouldn't make much sense. When I add a paragraph in front of the one
mentioning the poodle, schema based pointers to the poodle might become
invalid, because it's another paragraph now.
Some sort of ID mechanism seems to be called for here...

All the best...
-Lars


-- 
Lars Oppermann <lars.oppermann@sun.com>               Sun Microsystems
Software Engineer - StarOffice                           Sachsenfeld 4
Phone: +49 40 23646 959                                D-20097 Hamburg
Fax:   +49 40 23646 550                  http://www.sun.com/staroffice



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]