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