[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]