Re: [Fwd: Re: [office-metadata] Reuse of metadata proposal for nonODF applications]

[Patrick Durusau <patrick@durusau.net>]

Svante,

On the whole I am with Bruce on this one. I don't think specifying a bit 
more of the base ontology in any way impairs what people may choose to 
do on their own and it does provide a common infrastructure upon which 
they can build if they so choose. We are about 'standards' after all 
although it isn't always clear where one wants to draw the line in terms 
of standardizing today knowing that we will learn more tomorrow.

But learning more tomorrow about what we should have said today is too 
commonplace to delay adopting what appears to me to be a very good 
suggestion from Bruce. His suggestion does not limit us in any 
significant way and provides a degree of uniformity for those who want 
to run with our work in its present form.

Hope you are having a great day!

Patrick



Svante Schubert wrote:
> I would like to know how others from the Metadata SC think about this.
>
> Svante
>
> Bruce D'Arcus wrote:
>> Svante Schubert wrote:
>>
>> ...
>>
>>>> We know -- by only looking at the RDF -- that foo:Bar is a kind of 
>>>> field. This is not "syntactic sugar"; it's formal definition.
>>> We might name the type similar to the ODF element, why inventing new 
>>> names?
>>
>> That's unimportant to me. There might be some awkwardness in doing so 
>> practically, though. We already invented odf:Element so I don't see 
>> the issue with another new class or two.
>>
>>>> We can then also say that prefix and suffix for the field is common, 
>>> Do we know that prefix and suffix will be used for all 
>>> text:meta-fields or is it just one possible way to represent the 
>>> format of a text field when used with citation - one possible 
>>> implementation.
>>> I wonder what the others saying about this, to me prefix / suffix is 
>>> part of the user RDF/XML supposed to be handled by an extension not 
>>> an Office.
>>
>> You're thinking like an office suite developer. For one thing, you 
>> don't know that an office implementation won't be processing this. 
>> Your assumption that it will all be left to "an extension" is thus 
>> just that: an assumption without basis.
>>
>> It seems highly likely to me, in fact, that an editor might well 
>> handle interpreting certain core properties and classes for 
>> rendering. Prefix and suffix are in fact a perfect example of that.
>>
>> Moreover, even if this is handled in extension code, it's still 
>> valuable to use common means to represent common concepts. A field 
>> has a set of very basic concepts that are general: prefix, suffix, 
>> target object, etc.
>
>>> The metadata SC could suggest how to solve such common problems, but 
>>> as the metadata is used by an extension I see no reason to restrict 
>>> this in the ODF spec.
>>
>> Again, you're making implementation assumptions that I don't think 
>> are reasonable.
>>
>>>> and we can do this:
>>>>
>>>> field:prefix a owl:DatatypeProperty ;
>>>>     rdfs:domain odf:Field .
>>>>
>>>> So inference can also realize that anytime someone is using a 
>>>> field:prefix property, it is with reference to a resource of type 
>>>> odf:Field (in addition to any other type, like foo:Bar). An RDF 
>>>> library that supports inferencing can actually generate that triple 
>>>> so that, for example, if you search for all resources of type 
>>>> odf:Field, you also get all that use field:prefix, *even if they 
>>>> are untyped* in the RDF/XML.
>>> If you can figure out that field prefixes are being found in the 
>>> RDF/XML by various metadata extensions, what advantage are you 
>>> taking of it?
>>> It seemed more reasonable to collect all prefix/suffixes of one 
>>> domain, e.g. for citations.
>>
>> As above, what if the editing application -- not the extension -- is 
>> responsible for that rendering. And what if every different field 
>> uses different properties to represent the same thing?
>>
>> If you want, I can submit a full proposal for the citation stuff. I'm 
>> trying not to do that because I'm busy and I don't think it should be 
>> critical with some baseline stuff, but you're putting me in an 
>> awkward situation.
>>
>> Bruce
>>
>
>

-- 
Patrick Durusau
patrick@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Acting Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)
Co-Editor, OpenDocument Format (OASIS, ISO/IEC 26300)