Ah - now you're entering my world!
FYI I've just taken a part-time position working on information
architectures, SDI design, system-of-systems - the sort of things that
underly why we might have a service in the first place.
So, whilst this may be a very brief comment, there will be much more
forthcoming and I'm very willing to collaborate further to understand
your requirements.
Essentially, a catalogue contains stuff which is useful to the community
of use, and as you point out this may be a very varied bag of stuff.
It is useful to consider the role of registrys and registers. The ISO
19135 provides (IMHO) a nice separation of concerns (in fact its the
only ISO 19000 spec I actually like!)
* register - a collection of objects owned and managed
* registry - the instructure that allows you to publish registers
(deployed instance of a Catalog if you like)
* catalog - the interface by which you interact with the registry to
access registers.
IMHO. all the service metadata stuff is horribly immature and possibly
misguided. Reconciling ISO 191119, UDDI, exBXML, OWL-S, WSDL,
capabilities is not a job for the faint hearted, and in general we dont
really know what we want our service metadata to actually achieve.
I dont believe we have many useful standardisations of the information
content available, and when we do, they should be published as a
coherent set of profiles of the registry/catalogue "meta-model" ( ahem,
ISO 11179), allowing bindings to the different nascent technologies we
have today whilst we play with them.
It all comes down, however, to the governance of the agreement about
what such metadata actually means. And, as you have alluded to, the many
aspects of the problem which will each need its separate set of
developed common understandings.
And, fundamentally, that governance has been a big vacuum... hence our
confusion and plethora of overalping partial-solutions.
Am in fact part of a team working on a profile for FeatureType
Catalogues to try to start breaking up this log jam. We should have a
draft profile for OGC consideration soon. We have a working ebRIM
implementation of the ISO models. This is an example of the lower level,
but not quite so low as abstract catalogue, building block we will need
to attack this problem without unbounded complexity as we add stuff.
Its going to be interesting to see how the UN SDI and INSPIRE
activities, with these governance issues in the frame, evolve over time.
Rob Atkinson
Adrian Custer wrote:
Hey all,
I'm slogging through the various catalog specs: it's all hard going for
little return so far (I'm in the abstract levels still). One question
arises.
We know from the geoserver/geotools/udig experience that part of what we
need to track is
'metadata about the data as we experience it'
I'm calling this 'metainfo' simply to have a quick label for it. This
stuff is inherently *not* something anyone else can provide for us. It
ranges from info about our experience of the service such as
responsiveness, throughput, error rates, correctness of the advertised
capabilities, and 'last time of successful use' to info about our
experience of the data such as 'real bounds of the data provided' or
'that data sucks, I'm never using it again.'
So far, none of the specs mention this as a different body of metadata
from that which can provided by a service. Can any of you comment about
how and where the standards process has integrated this user need? Has
this been studied and discarded? Is this under the radar screen since it
is inherently not a *service* someone can provide (i.e. once it is
shared it simply becomes metadata like any other)?
I see this as a fundamental need for any data user and, indeed, figures
in Jody's comments about the history of the various 'catalogs' batting
around the geotools world but don't see it addressed so far in any spec.
thanks for your thoughts and comments,
--adrian
begin:vcard
fn:Rob Atkinson
n:Atkinson;Rob
email;internet:[EMAIL PROTECTED]
tel;cell:+61 419 202 973
x-mozilla-html:TRUE
version:2.1
end:vcard
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
