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

[Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM>]

Hi Bruce,

Bruce D'Arcus wrote:
> 
> On Mar 6, 2007, at 2:44 AM, Michael Brauer - Sun Germany - ham02 - 
> Hamburg wrote:
> 
>> Bruce D'Arcus wrote:
>>> Michael,
>>> I think we need to separate the question of document URI (the 
>>> rdf:about value for the document per se) from formal XML base URI. I 
>>> am saying we need the former, and that it needs to be unique and stable.
>>
>> Yes, we should. But isn't a document URI assigned to documents from 
>> the outside? I do understand that documents need a stable and unique 
>> URI for certain metadata applications, but my impression is that 
>> defining that is outside the scope of our TC. We are defining a 
>> document format for office applications. We are not defining mechanism 
>> to identify documents. So, all we can do in my opinion is to assume 
>> that there may be a stable unique IRI, but we should not try to define 
>> what it looks like.
> 
> I have never said we should define "what it looks like." I have said a) 
> documents needs stable and unique URIs, and b) we should not rely on 
> file paths as some kind of fallback. I am thus suggesting we require a 
> document URI, and that we remove the language of "or the file path" or 
> whatever it was.

You are right, requiring a stable IRI and defining what it looks like 
are two different things. I should have been clearer about this, but 
actually have concerns with both.

> 
> ...
> 
>>> Example 2:
>>> I want to represent the relations between different documents. I want 
>>> to say file x.odf is a draft of file y.odf.
>>> Triples, if there is no stable full URI:
>>> <file:///y.odf> dcterms:isVersionOf <file:///x.odf> .
>>> Again, what happens if the document moves? What happens if it moves 
>>> to a desktop where a user has the exact same file name and path, but 
>>> it is actually a different file?
>>
>> For this use case you can use the IRI "." (that denotes the current 
>> document) as subject,
> 
> Actually, you'd have an empty attribute.

The empty attribute value denotes the current file. In a package, this 
is the file that contains the empty attribute value. The "." denotes the 
directory of that file, and this is exactly the package.

> 
>> but in fact you need a stable IRI for the object.
> 
> Yes!
> 
>> But as I said above. It is my opinion not within the scope of our TC 
>> to define that. That's something that in my opinion operating system 
>> vendors, content management system vendors etc. have to define, but 
>> not us.
> 
> As I said, we should not define the URI scheme (though we should 
> definitely give examples), but we should certainly define the goals of 
> being globally unique and persistent, and the implications of them not 
> being so.

I don't think we can guarantee uniqueness on the file format level. In 
you other reply you say:

 > Oh, and no, it would be stored within the document, and assigned by
 > either a user or (more commonly) an application.

If you do so, then you only have to copy the document using a "cp" 
command, and you have already broken the uniqueness.

> 
>>> Example 3:
>>> Rob wants to enable his use case of external annotation of files. 
>>> Same problem as above.
>>
>> Yes and no. As for the location of the file itself, it is the same 
>> problem (Rob, what's your point of view: Is it within the scope of our 
>> TC to define stable IRIs for documents?) But I assume Rob does not 
>> only wants to annotate the document itself, but also objects within 
>> it. And that's where the relative IRIs of your first example could be 
>> used again.
> 
> But the point is if you don't have a stable document URI, the relative 
> URIs don't help you; your object URIs are still wrong.
> 
> I don't understand what's so controversial about saying a document ought 
> to have a stable ID.

Its not controversial to say that a document should have a stable URI, 
if this is guideline for authors and implementors. But because we cannot 
guarantee the uniqueness, and because it is not under our control what 
happens to document, but also because there may be cases where the 
location of the IRI is sufficient, we should not make this mandatory.

Is that clearer?

Michael

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