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

[Bruce D'Arcus <bdarcus@gmail.com>]

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 can then also say that prefix and suffix for the field is common, 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.

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.

We can then later add other generic properties as they become clear.

Is this making more sense?

Bruce