"Geodata Discovery" at FOSS4G2006 BOF

Wed Sep 20 02:51:44 EDT 2006

Peter

> 1) Object (or Catalog Record) entity
> 2) Association entity
> 3) Classification entity. [see note ***]

I agree, this is a very simple model. But it's to abstract, to dynamic.
(But it's a powerfull pattern for an implementation!)

> 4) Extensibility
> can easily be accomplished by defining a simple structure with three
> properties:  name, type and value.

I agree, this is a nice way to get (lightweight) extensibility without the
burden of a new schema.
It also reduces the pressure to a base spec for adding new features!

Claude

----- Original Message -----
From: "Panagiotis (Peter) A. Vretanos" <pvretano at cubewerx.com>
To: "Kralidis,Tom [Burlington]" <Tom.Kralidis at ec.gc.ca>
Cc: "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>;
"Paul Ramsey" <pramsey at refractions.net>; "Claude Eisenhut"
<ce at eisenhutinformatik.ch>
Sent: Wednesday, September 20, 2006 2:50 AM
Subject: Re: "Geodata Discovery" at FOSS4G2006 BOF

> 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."