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: [Fwd: Re: [office-metadata] Reuse of metadata proposal for nonODF applications]


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]