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 non ODFapplications]


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
>


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