"Geodata Discovery" crosslinks and capabilities

Wed Sep 20 03:10:27 EDT 2006

> Who is going to populate all
> these cross-references from data to services to metadata?

And why do people link there web pages to other people web pages?
Isn't this the only way that scales: Make it possible for everyone to
publish and to link to other published things.

> What information is available, what can we
> discover? Capabilities documents.

I agree. But some users have to define, what they require in the
capabilities documents. And service providers should listen, because they
want users to buy there services.

Claude

----- Original Message -----
From: "Paul Ramsey" <pramsey at refractions.net>
To: "Panagiotis A. Vretanos (Peter)" <pvretano at cubewerx.com>
Cc: "Kralidis,Tom [Burlington]" <Tom.Kralidis at ec.gc.ca>; "Jo Walsh"
<jo at frot.org>; <sfkeller at hsr.ch>; "Jody Garnett" <jgarnett at refractions.net>;
"Raj Singh" <raj at rajsingh.org>; "Jeroen Ticheler" <Jeroen.Ticheler at fao.org>;
"Allan Doyle" <adoyle at eogeo.org>; "Josh" <josh at oklieb.net>;
<rob at socialchange.net.au>; "Frank Warmerdam" <warmerdam at pobox.com>;
"Sampson, David" <dsampson at NRCan.gc.ca>; "Chris Holmes"
<cholmes at openplans.org>; "Markus Neteler" <neteler.osgeo at gmail.com>; "Claude
Eisenhut" <ce at eisenhutinformatik.ch>
Sent: Wednesday, September 20, 2006 5:26 AM
Subject: Re: "Geodata Discovery" at FOSS4G2006 BOF

>
> I ranted at Stefan on this at FOSS4G, so it seems unfair to not rant
> about it here: pretty information models, even simple ones, are so
> much intellectual masturbation in the absence of some actual
> *information* with which to fill them!  Who is going to populate all
> these cross-references from data to services to metadata? Elves? And
> who is going to keep them up as they fall out of date, as the
> services change URLs, as the contacts referenced in the metadata
> change jobs, as the organizations change names? Gremlins?
>
> We are building library services without librarians!  There are no
> digital data librarians, no funded staff positions, and even if there
> were, they would have a job 100 times worse than their paper-pushing
> counterparts, because the things they are cataloguing are so
> insistently mutable!  Show me a state metadata archive and I'll show
> you an archive where 50% of the information is now wrong.
>
> Back it right up. Don't start with the information model.  Start with
> the information.  What information is available, what can we
> discover? Capabilities documents.  OK, model those.  Then you will
> have a very simple model, which will be easy to implement and
> optimize, and can spend your time on things like measuring quality-of-
> service, ensuring services are online, finding more services, even
> gathering "web 2.0"-style ratings and feedback from users.
>
> Paul
>
> On 19-Sep-06, at 5:50 PM, Panagiotis (Peter) A. Vretanos wrote:
>
> > Tom et al.,
> >
> > I wish I had the funds available to attend this session! :(
> >
> > Barring that, I have some comments that I hope will be useful ...
> >
> > Note that in these comments I use the term "entity" to mean a
> > structure that must be defined in the model.  In an RDBMS an
> > "entity" would be materialized as a table.  It XML an "entity"
> > could be materialized as an XML element of some complex type.
> > Ok ... moving on!
> >
> > I think that the content model of a light weight catalog should
> > include the following entities:
> >
> > 1) Object (or Catalog Record) entity
> > This entity is a list of all object that are discoverable in the
> > catalog (Data, services, etc ...).  The properties of this entity
> > should be some subset of Dublin core (e.g. the csw:Record schema is
> > a good place to start http://schemas.opengis.net/csw/2.0.1/
> > record.xsd).
> >
> > 2) Association entity
> > This a simple three-property entity that lets you associate one
> > catalog record with another catalog record.  The properties of this
> > entity would be something like "source object id" "association
> > name" "target object id".  Using this entity you can capture stuff
> > like "Dataset A" "IsServedBy" "Service B".
> >
> > 3) Classification entity. [see note ***]
> > This is a simple two-property entity that lets you classify a
> > catalog record according to some node in a classification scheme.
> > The properties of the classification entity would be something like
> > "classification node id" and "object id".
> >
> > 4) Extensibility
> > This is actually an extension to (1).  The description of an object
> > should be easily extensible without the need to redefine the schema
> > each time you wish to add one or two additional metadata elements.
> > This can easily be accomplished by defining a simple structure with
> > three properties:  name, type and value.  This is very rdf'ish I
> > think. Actually, something just occurred to me ... why not use such
> > a structure to describe the object in the first place?  I'll have
> > to ponder that some more and write back to the list later.
> >
> > So, given these entities the catalog should be able to do the
> > following:
> >
> > 1) Maintain a list of all discoverable objects in the catalog with
> > some lightweight metadata about each object.  The "lighweight"
> > metadata can include a metadataURL element to point to more
> > detailed descriptions of the object in some standardized metadata
> > format (like ANZLIC or FGDC or ISO19115/19119).
> >
> > 2) You can associate objects in the catalog with each other.  This
> > lets you do stuff like find a service offering some data or visa
> > versa.
> >
> > 3) You can classify objects so that you can do queries on
> > hierarchically aggregated sets of objects.  So, saying something
> > like "find all objects classified as "Ontario" would locate all
> > "Ontario" records as well as "Toronto", "Ottawa", "Kingston", etc.
> > records since all these nodes would be children of the "Ontario"
> > node in a geographic classification scheme.  To get real fancy we
> > can include clauses like "BROAD", "NARROW" and "EXACT" in the
> > interface to control how the classification tree is traversed
> > during a query.
> >
> > 4) You should be able to easily customize the object description by
> > adding metadata elements to the basic descriptions without having
> > to change the schema.
> >
> > I can probably whip up a modified record.xsd schema that includes
> > the additional elements I am talking about if people think this
> > would help.  I don't think that the entire information model would
> > be more than a couple of hundred lines of xmlschema.  Certainly way
> > shorter than any of the ISO models or ebRIM for that matter.
> >
> > Of course, the ebRIM schema already includes all this ... albeit in
> > a very verbose schema.
> >
> > That's my $0.25CDN worth.  Comments are welcome.
> >
> > NOTE ***:  The content model may also need to include a couple of
> > entities for encoding classification schemes.  One entity would
> > maintain a list of classification schemes that the catalog knows
> > about.  The other entity would maintain a hierarchical list of
> > nodes that belong to each classification scheme.
> >
> > Kralidis,Tom [Burlington] wrote:
> >> Agreed w/ RobA that interface is not the issue, but content model.
> >> So, I imagine our first step would be:
> >> - identify simple lightweight content model for metadata about:
> >>  - data
> >>  - services (where do OGC Capabilities XML fit into this?)
> >>  - 'resources' (i.e. WMC, SLD docs)
> >
> > Using the model I describe above all these things can be described.
> > Each would simply by a different type of cataloged object.  In
> > other words you should not need a separate metadata model for data,
> > services or other resources.
> >
> > Capabilities document are funny animals since they themselves are
> > "mini" catalogs.  I would say they should be decomposed in some
> > standard manner into the catalog's information model.  Many times,
> > the capabilities document is the only "metadata" about a service
> > and its data that is available.
> >
> >> Comments?  If this is our first step for real, let's discuss the info
> >> model at: http://wiki.osgeo.org/index.php/
> >> Geodata_Metadata_Requirements#Informatio
> >> n_model_for_metadata_exchange
> >
> > Hope this helps.
> >
> > Ciao.
> >
> > --
> > Panagiotis (Peter) A. Vretanos          CubeWerx Inc.
> > Big Kahuna (Senior Database Developer)  http://www.cubewerx.com
> > Tel. 416-701-1985 Fax. 416-701-9870     pvretano at cubewerx.com
> >
> > "Any good geek knows that Halloween and Christmas are the same "
> > "thing: OCT 31 == DEC 25."