Svante Schubert wrote:

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