On Sun, 2007-11-04 at 22:00 +1100, Rob Atkinson wrote:
> Ah - now you're entering my world!
Congratulations on your new job, sounds perfect for you, and thanks for
the summary of your world. I'll agree to drop the term 'repository' from
my notes and use 'register/y' instead to describe the storage system
capable of handling any 'element;' choosing the preferred term between
the two was going to be a coin toss anyhow. But could you answer my
question?
Do any of the specifications consider the creation, access, management
and storage of 'local metainfo' (i.e. 'stuff that only I can generate
and that I will accumulate from my experience') as something distinct
from the more general metadata?
>From the user point of view this kind of data is distinct:
1) it must be accumulated automagically and provided as feedback
for decision making: "hey that dataset you just downloaded
overnight onto your external disk took 8.32 hours to transfer,
takes up 6.32 GB of space and has checksum xxx.yyyy.zzz ."
~means~> "I'll have to think about how many copies of that thing
I end up making." This kind of data slowly grows and evolves as
well: "today it's correct, yesterday it was broken in ...this...
way".
2) it the first and perhaps only thing that requires local
creation. In the eventual nirvana where services are simply
provided on the network and the client merely connects and uses
those services, the local experience must none the less be
generated. This looks to be true from all the Geotools /
Geoserver / uDig points of view. Geoserver needs to store 'that
bounds is wrong' kind of data. Geotools needed to generate a
PostGRID database simply to efficiently access nD data (although
this is a guess on my part since I've learned neither what
PostGRID really does nor how it actually works). uDig, for now,
is still trying to pretend that it can avoid having a 'register'
of any kind but I'm starting to distinguish all the issues with
that strategy: while uDig, more or less, can punt on the storage
of data, it is still going to need both to provide storage info
(size) on the objects and to log info on the experience of
obtaining data from the services ('that service is dog slow').
3. Realistically, it will require local storage. We are not
going to cascade the info out, certainly not to begin with as we
figure out what is needed and probably never.
Perhaps the question doesn't make sense to you. I'm keeping it in mind
for now regardless. I will see where it leads me as I
read/ponder/draw/avoid these other specifications.
--adrian
> 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
> >
> >
>
-------------------------------------------------------------------------
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
