Hi Joe, thanks for your thoughts; some immediate comments follow. I will
also be thinking about these ideas and may have more to say later.
----- Original Message -----
Sent: Tuesday, June 04, 2002 3:45 PM
> Benno, John,
> As I am currently immersed in Web-service-think (particularly WSDL,
> which seems to basically be a more generalized version of what THREDDS
> catalog is attempting for scientific data services) I would propose that
> the principle of orthogonality might be a useful tool for deciding on
> these issues.
> For an XML design, orthogonality means whether or not a given tag or
> attribute represents a distinct concept that is in no case expressible
> using existing tags and attributes.
> While a completely orthogonal tag set results in somewhat less succinct
> documents than an approach which defines a number of "special case"
> tags, the advantage is that it yields the maximum ratio of
> expressiveness to schema complexity.
> WSDL is an extreme example of this approach. Unlike them, we may want to
> define special-case tags for very common cases to make the
> actual documents less unwieldly.
> The purpose of this message is not to suggest exactly which cases these
> might be; rather, I am just suggesting we take a look the current and
> proposed DTD down from this perspective.
I agree that orthogonality is a very important motivation. Related
motivation is simplicity (small number of concepts) and concept independence
(same meaning wherever a concept is used).
The other motivation I have had is:
"Make common cases simple and human-readable"
For me, attributes are a bit easier to read then contained elements, so this
motivation orients me towards the use of attributes, all else being equal.
This has also motivated factoring out common information, which reduces
repeated information. This has led to:
1) allowing properties to be placed at collection elements which become
the defaults for contained datasets.
2) factoring out server/service elements.
These are more qualitative and aesthetic judgements, and are rather
subjective. None of these can be judged completeley independently, you have
to look at the overall effect on readers, writers, APIs, tutorials, etc.
> A summary of the completely orthogonal concepts I believe we have
> introduced thus far (not necessarily named the same as the tags that
> currently express the concept):
> service type - a named mechanism for accessing scientific data
> access - a (named?) binding of a URI to a specific service type
> metadata type - a named convention for description of scientific data
> metadata - a (named?) binding of a text fragment to a specific metadata
> metadata reference - a (named?) binding of a URI to a specific metadata
> dataset - a named collection of access objects and metadata
> collection - a named collection of datasets
> collection reference - the URI of a THREDDS XML document containing a
> In contrast, the following concepts are not clearly orthogonal to me:
> service path, server path, collection path, dataset path, suffix - since
> they are only used in the context of the access object, they don't
> really add meaning - any catalog using these attributes is equivalent to
> one without them, which uses absolute uri's for all of its access objects
> compound service / service list - this also doesn't strictly speaking
> add meaning since services are only used in the context of access
> objects - thus, one access with a compound service type is functionally
> equivalent to n access objects with simple service types.
> service subtype - unless the values for this attribute are given
> standard meanings, this is equivalent to a named access object. even if
> the values do have standard meanings, there still seems to be some
> overlap with metadata type.
> catalog, server - if you factor out the path attribute, these are
> equivalent to collections
> documentation - equivalent to metadata with a human-readable metadata type
> document - same as documentation, except with the connotation that it is
> not critical to interpreting the dataset
I think its interesting and important what the ontology is, and I notice
some subtle differences in your conceptualization and mine (and also between
Benno's and mine). If we can converge on that a bit more, then some of these
other issues may be clarified. I think your description above is good, but
here are some different perspectives on some of it:
I would say the basic objects are datasets and services. Therefore, an
access element is a binding of a dataset to a service. The base, path,
suffix are first attempts to specify the binding. Metadata are properties of
Its true that a catalog is just a collection. Its also a container for
service elements, but I dont really like that. Even if we keep service
elements factored out, it seems better to allow collections to contain
service elements, so service elements can be near where they are used. This
will probably be useful for large synthetic catalogs. OTOH, a catalog is
very much a user-visible object in a way that perhaps an arbitrary
collection should not be. So while I am inclined to make a catalog even more
like a collection by putting service into collection, I am still inclined to
a seperate top-level catalog element at the moment.
Ive tried making documentation a metadata subtype. It felt slightly wrong,
and I think its because documentation has to do with presentation, while
metadata is really properties of the dataset itself. Adding more of the
XLink "show" semantics to documentation seem to make it diverge more from
metadata. At the cost of adding an extra element, it seems easier to explain
with them seperate.
Much harder question is the distinction between a dataset and a collection,
since a dataset is a collection of data. I have conceptualized it as
follows: a dataset is something that can be selected, and then it is
processed in a protocol-dependent way. A collection is a
protocol-independent mechanism for grouping datasets.
> One that I am not sure about is the "attribute" tag, since I am not
> clear on how this is intended to be used. Is it for the THREDDS parser,
> or passed directly to the user? Will there be standardized names and
> values for attributes?
Im open to suggestions on how it should be used. Right now, Id say it is
made available to the client, to the protocol-aware dataset processing, and
optionally to the end-user. Therefore it could be the mechanism to make
standard extensions in the future without having to change the XML format.
> A reminder, I am not trying to say specifically whether any of these
> tags should be kept or dropped. I am merely suggesting that we might
> want to focus on tags and attributes that represent orthogonal concepts,
> and be a bit more choosy about the rest.
> Also, I would suggest that any proposed extensions that *are* genuinely
> orthogonal to the original tag set (although I'm not sure we've had any
> thus far) be given special consideration, since by definition, there is
> no workaround if they are not included.
agree, do yu have anything in mind?
> John, hope this is useful input.
very useful, thanks much
> - Joe