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

[John Madden <john.madden@mac.com>]

Guys,

I'm trying to understand both Bruce & Svante's points, and to the  
extent I *think* I can understand, I think both have good points here.

If I understand correctly, Svante is alluding to the fact that  RDF  
resources are "transparent"; that is that in the RDF world, as in  
linguistics in general, the connection between the signifier  
(resource URI) and the signified ("the resource") is totally  
arbitrary. And he's emphasizing correctly that this lack of  
concreteness is absolutely key to why RDF support is such a desirable  
feature for an application that wants to support generalized  
metadata: unlike concrete xml, with RDF you aren't limited to using a  
domain-specific languages when you talk. (In this sense RDF is like  
natural language--you can use English to talk about stars and teacups  
and sales taxes. How much worse it world be if we could talk about  
stars only in English, teacups only in French, sales taxes only in  
Lithuanian.)

So therefore, if I understand Svante correctly, he's arguing that ODF  
itself should not be in the business of creating RDF vocabularies for  
specific purposes, because that's not ODF's job. ODF/OASIS should  
enthusiastically support people who want to create specialized RDF  
vocabularies and to publish them, but OASIS/ODF should not itself put  
forward specialized RDF vocabularies -- not vocabularies about zebra  
breeds, nor about quarks and leptons --- nor *even* vocabularies  
about document structures. We should provide an RDF framework, others  
should fill it with content.

Bruce (if I understand) is saying: hold on here!  I (Bruce speaking)  
certainly agree that ODF should not be in the business of supplying  
e.g. RDF vocabularies about orchid varietals just because an author  
of a book on orchids wants to prepare his manuscript using ODF marked  
up with metadata.

BUT, on the other hand (says Bruce), we're the "Open ****Document****  
Format" people !! We're supposed to be the ****document****  
experts !! We know a lot about documents, and we know a lot about  
RDF, so let's make it our business to create at least ONE specialized  
RDF vocabulary: namely, an RDF vocabulary about (drum roll here...)  
document structures.

I tend to side somewhat with Bruce on this one, but I also agree with  
Svante (or what I think Svante might say), in that if do such a  
vocabulary, it should not be done in such a way as to constrain/limit  
ODF, but to highlight its interoperabllity with other docuemnt  
sturcture conceptualizations.

I've often thought that we should open a dialog with DocBook folks,  
who *also* know a lot about document structures, and see whether ODF  
and DocBook together can grok some high level abstractions about  
documents that could be turned into a very perspicuous, robust, high  
level RDF vocabulary that could interrelate the two OASIS document  
conceptualizations (including their conceptualizations of  
bibliopgraphic references).

John



On Aug 27, 2007, at 8:38 AM, Patrick Durusau wrote:

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