Re: [office-metadata] naming schema

[Patrick Durusau <patrick@durusau.net>]

Florian,

Remember, I had to push the meeting back to 1:30 PM Eastern. Sorry.

More responses below:

Florian Reuter wrote:

>Hi Bruce,
>
>thanks for the resonse. But I don't get your point :-) Luckily we have a phone conference later the day ...
>
>When I understood you correctly you prefer the ID way. 
>
>What I tried to do is to present a ways to "generate unique IDs". Sure, we can simply say the a ID is a URI. But why not
>use a naming schema to generate unique IDs?
>
>I understand that using the "opaque identifiers" identifiers give you a simply direct relationsship:
>
>ODF entity + URI id   <====> RDF statement about URI id
>
>My goal is to establish relationships differently:
>
>ODF enitity + style name <====> naming schema which maps between style names and URI <===> RDF statement about URI
>
>I understand that this is no longer an "opaque identifier". What I don't get is why this is soooo bad :-) In fact I
>thought that would be particulary clever :-)
>
>  
>
Err, well you are clever Florian! Have we forgotten to say that 
recently? ;-)

My question is do we really care how the URI is generated? In other 
words, does the method have an impact on its "opaqueness?"

If RDF can see it as "opaque" and Florian, being clever and at his own 
risk, want to see it as "non-opaque" is that a problem?

Serious question. Must we define URIs as opaque for all purposes? Or is 
that up to the application using the URI?

I don't know if that would be a problem or not.

Hope everyone is having a great day!

Patrick

>~Florian
>
>
>
>  
>
>>>>Bruce D'Arcus <bdarcus@gmail.com> 02/21/07 2:01 PM >>>
>>>>        
>>>>
>
>On Feb 21, 2007, at 6:37 AM, Florian Reuter wrote:
>
>  
>
>>What do you think?
>>    
>>
>
>Well, there's really two proposals here: one for naming (URI)  
>conventions, and one for styles.
>
>On the first, you say in the document:
>
>  
>
>>In order to make metadata statements about parts of an OpenDocument  
>>you need to have a naming schema.
>>    
>>
>
>True. But we have one one: the URI. Elias made the point very early  
>on -- which is a point I think we need to live by -- that we do not  
>want to treat these URIs as anything but opaque identifiers. Their  
>only purpose is to uniquely and consistently identify resources.
>
> From that perspective, worrying about whether the string "table"  
>shows up in an ID for a table is not only not our job, but is  
>counterproductive.
>
>This is such an important point I think it should go in the proposal  
>we present to the TC.
>
>Styles as mechanism to apply metadata:
>
>As I've mentioned before, I think your use case here really wants to  
>treat the paragraph as a resource and to annotate it with properties.
>
>One way to achieve that without using explicit ids on the paragraph  
>node is to treat it as a blank node, and one way to do that with an  
>RDFa-like appraoch is to use meta:class. If we allow that, then we  
>could allow such an attribute optionally on styles.
>
>But I think if we do this, it has to be fully based on and consistent  
>with the core proposal. I'd like us to settle that first (we still  
>have details to work out there), and if we have time to then consider  
>this.
>
>Bruce
>
>
>
>
>  
>

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