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]


Bruce,

Bruce D'Arcus wrote:
> Svante Schubert wrote:
>
>> Obviously I have not understand what you have been trying to tell me.
>> On my questions in my previous mail you might see were I was not 
>> certain what you have been explaining.
>>
>> Please try again, believe me I am willing to listen.
>
> The question is: how do we create the technical and the 
> social/informational infrastructure for rational-but-flexible 
> implementation of text:meta-field in ODF 1.2?
>
> If some developer creates a custom field called foo:Bar, how do we 
> know it is a field only by looking at the RDF?
>
> Can we define some common properties that developers can use so they 
> don't have to invent their own?
>
> My answer to the first question is, you create a base class from which 
> formally -- in RDF Schema and/or OWL -- you can extend. So if we do:
>
> odf:Field a owl:Class.
>
> foo:Bar rdfs:subclassOf odf:Field .
>
> 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?
>
> 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.
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.

> 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.
>
> So there are technical reasons to do this I believe. It provides both 
> building blocks (properties) and extension points (generic classes) 
> that developers can use to implement custom fields. In using this, one 
> gets the flexibility we want, but also machine-oriented predictability.
>
> But there are also more social or informational reasons. If a 
> developer wants to know "what the hell do I do with text:meta-field?" 
> having these few classes and properties gives them some hints.
Yes, we should give hints by examples, but be careful already to 
restrict by introducing it as part of the standard.
>
> We can then later add other generic properties as they become clear.
>
> Is this making more sense?
Yes, thank you.

Svante


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