Karl Czajkowski wrote:
Perhaps I am being too informal for your liking, but I think the JSDL specificaiton is intrinsically defining an ontology of jobs already, i.e. what are the meaningful concepts of jobs that can be submitted. The semantics of the various JSDL XML bits are described in English using this implied ontology. Anyone can read the specification and write out the set of concepts into their favorite formalism. What makes it an ontology is its "job-space characterization nature", rather than it being written one way or another!
We're doing an informal ontology in any case. Formal ontologies are something else. (I work with ontologists, and at some point I need to get JSDL run past one of them. But not until we've got 1.0 shipped.)
The only question is how explicitly will the specification call out this fact? If it does nothing, there is an implicit ontology being presented.
The spec could pay a little respect to the ontology-obsessed by calling out the various concepts or tabulating them somehow. It could encourage reuse by tweaking the XML schema and discussions to emphasize the meaning of "atomic" syntaxes without being tied to the enclosing JSDL document context more than necessary (as I think Donal is suggesting?).
At the far other extreme, the specification could try to formalize the ontology using some ontology modeling language. I wholeheartedly agree that there should not be an undertaking here at this time (or ever?).
I think that the only problem at the moment is that we try to constrain the containing context that elements may be used in as well as constraining the content of those elements. If we just constrain the content, ontological use (as opposed to job-definition use) becomes much easier. I also don't think we actually lose anything; it's just a reordering of the document (and not an alteration to the schema at all). We're probably in huge agreement here :^) Donal.