Re: [office-metadata] "Logical/abstract" vs. "physical" representation

[Elias Torres <eliast@us.ibm.com>]

Florian,

This is exactly what I mean when I say we need a way to generate absolute
URIs. I say again, we should treat URIs opaquely and not read too much into
it whether they are tied to a "physical" file path.

I didn't get a chance to respond to Michael's response on IRI resolution in
ODF, but in essence, I don't think it's enough. We need a URI that'll be
stable across .zip locations and that can be reused throughout the document
and others.

For example, if we were to give a new UUID to an ODF document and upon
every save we bump a version number then we'd have a unique id stable that
we can point to in rdf:about statements all we want.

Note, I'm not promoting LSID, but it's something that has the properties I
want to show:

urn:lsid:[DOMAIN]:[PACKAGE/NS]:[ID]:[VERSION]

domain - anything we want
package - is a namespace
id - as usual
version - as expected

so we could have:

urn:lsid:odf.org:[some-doc-uuid]:[element-id]:[document-version]

The above is both a URI (for RDF purposes) and also unique and opaque
identifier that can be used both for zip files and other abstractions.

However, if we don't do a stable and absolute resolution of URIs in ODF
metadata we would end up with different subjects on different storage
abstractions.

-Elias

"Florian Reuter" <freuter@novell.com> wrote on 03/01/2007 10:07:45 AM:

> Hi,
>
> I have problems with the xml:id/rdf:about approach. I really dislike
> rdf:about="content.xml#id001" RDF statements, because these rely on
> the .ZIP structure. But the .ZIP structure is not always present. E.
> g. when the ODF is represented as FlatXML or represented in a database
etc.
>
> I believe we make a big mistake if we bind ODF to close the .ZIP
> representation. Please note that OOXML has this “abstract view of a
> package”. Here are some quotes from the OOXML packaging spec you may
> find interesting:
> <quote>
> The package provides a convenient way to distribute documents with
> all of their component pieces, such as images, fonts, and data.
> Although this Open Packaging specification defines a single-file
> package format, the package model allows for the future definition
> of other physical package representations. [Example: A package could
> be physically represented in a collection of loose files, in a
> database, or ephemerally in transit over a network connection. end
example]
> </quote>
>
> We have to find a way to identify objects which do not rely on the .
> ZIP package representation. Otherwise we limit ODF to the
> representation of a .ZIP file.
>
> Additionally please note that ODF currently has at least to views of
> a physical representation of an ODF document: stored in a .ZIP file
> and “Flat XML”. So the concept of an “logical/abstract
> representation” and a “physical representation” is not new to ODF.
>
> My problem is that our discussion is to closely bound to the .ZIP
> physical representation.
>
> I would very much like to differentiate between a “logical/abstract
> representation” and a “physical representation”.
>
> ~Florian
>
>