[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-metadata] Binding proposal
Svante, Svante Schubert wrote: > Hello group! > > After several discussions here at Sun and a week-end of > reconsideration, one thing seems clear now: > It makes little sense to trust on an identification mechanism, that > can be so easily annulled as by a file copy. > We doubt that any company would rely their data on such fragile > mechanism, unless a special work-flow is being used for documents in > the company. > Sorry, that went by a little fast. What do you mean the identification mechanism is "annuled as by a file copy."? I attach metadata in an ODF document. I then copy the document. How has that "annuled" my metadata? Actually I was thinking that metadata would continue to be valid in a document until someone changed it. Which would mean that documents would get "richer" with metadata as they are process in a work flow. The mechanism isn't "fragile" at all but robust and therefore inconsistent with processing models meant for truly "fragile" metadata as we have today. > Taking into account our lack of time and the seizable unclarity on > this list, I suggest to drop sophisticated identification mechanisms, > especially as no other document standard has entered before something > similar to it's format. > Someone has to be first and I would like for it to be us. Provided there isn't some fairly clear explanation that will convince me that copying is going to "annul" metadata. > What can we simplify to come to a solution? > > Do we need a world-wide scope of identification? > For example, when a content mgmt system (cms) holds data, the data > will be kept unique for it's system, in a second (cms) the data might > be duplicated, as the scope is only for one system. > Metadata is being created for one document, the scope of reliability > is the document itself. Yes, present processing systems are built on this assumption. It is, if we use more robust metadata, a false assumption. I don't think we need to limit ODF to current models for processing metadata. > > As any ID mechanism between documents can be overthrown by file copy, > the only trustworthy identification of the document can be made from > outside the document. > For instance, the access of a document makes a document unique for the > accessors or documents received by mail might be identified by sender > and time. > > Nevertheless to aid above scenarios of controlled work-flows, it still > seems useful to specify in the meta manifest two attributes for a > document ID and revision. > I would not request UUID as uniqueness is known to be fragile. I would > rather suggest any IRI for the ID as they are easier to create from > the scratch and can be used to reference to further information and an > integer for the reversion. Aside of this even the introduction of a > base URL makes sense. > > Regarding the binding: > If we agree on the simplification, that the scope of identification is > the document itself, we still have a different option than to use > relative URLs: > As we have already discussed to create our own URL from various IDs > and we still want to avoid problems with relative URLs, I suggest to > relate to ODF resources by a ODF URL pointing to a resource: > "odf:/content.xml#myID" > As odf:/ references to the root of the package, followed by the > reference to the resource, the uniqueness of this ID is guaranteed for > the package. > As I noted above, this is limiting ODF metadata to current (and I think passe) metadata processing models. Given the opportunity, I think people are going to write better metadata processing models and software. Hope you are having a great day! Patrick > Regards, > Svante > > > -- Patrick Durusau Patrick@Durusau.net Chair, V1 - Text Processing: Office and Publishing Systems Interface Co-Editor, ISO 13250, Topic Maps -- Reference Model Member, Text Encoding Initiative Board of Directors, 2003-2005 Topic Maps: Human, not artificial, intelligence at work!
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]