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

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-metadata message

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


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


Elias,

I do understand that one may need an opaque (or whatever you may call 
it) IRI that is independent of the physical location of a document to 
use metadata in practice. That's why I have suggested that a package may 
specify a base IRI.  Isn't it sufficient to say there could be such a 
base IRI, and to leave it up to the application to set it, if they want?

Doesn't HTML have the same issues, and is RDFa specifying which base IRI 
have to be used?

Michael

Elias Torres wrote:
> 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
>>
>>


-- 
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]