[Ebxmlrr-tech] [Geodata] ebRIM storyboard

Thu Mar 29 12:17:15 EDT 2007

Jo,

The reasons for ISO19119 similarity are lost in the depths of the German work on this - although its a bit daft that they appear to have been unaware of the ISO15000 spec's - I won't speculate why on all that.

We have seen quite a bit of "re-use" of spec's over in the ISO - in part thru overlap of some of the players.

Anyway - be that as that may - I think your assessment that ISO19119 is just a spec' while ISO15000 is an implementation pretty much hits that nail.

Let's move on - seems what you are looking to do is highly attainable here - and fits well with the use case needs et al.

I'm wondering if the US Geo folks have something already that is regrep based - since again - several active folks in the Geo space were also keenly aware of the potential of regrep too.

DW

From: Jo Walsh
Sent: Sun 3/25/2007 2:07 PM
To: Norman Barker
Cc: geodata at lists.osgeo.org; ebxmlrr-tech at lists.sourceforge.net
Subject: Re: [Ebxmlrr-tech] [Geodata] ebRIM storyboard

dear Norman, please excuse the response lag, it made sense to me to
try to get my head around the ebRIM spec before responding. 

dear ebxmlrr people, please excuse this live-action exploration of my
own ignorance. I am reluctant to start a lot of mailing list back and forth,
let's argue in code, not words ... :) 
I am definitely interested in trying out omar as an experimental service
catalog running on the OSGeo geodata repository system at telascience.

On Wed, Mar 21, 2007 at 03:58:33AM -0000, Norman Barker wrote:
> in an effort to explain how an ebRIM catalog can 'work for us', I have story boarded the main use case of searching a catalog from a user perspective here;
> http://wiki.osgeo.org/index.php/EbRIM

I have a mixture of really general reflections, and specific
questions which are below the level of detail you cover here.
And having another look at the XML sample you sent the other day 
http://lists.osgeo.org/pipermail/geodata/attachments/20070315/438f538e/iceds_wcs-0001.xml

1/ Service Description

In your demo there are several WCS interfaces modelled in ebRIM as
Service objects with ServiceBindings. From where I am sitting, what
the ebRIM model lets you describe is "this is a kind of Service, and here
is a URI for the protocol/interface it uses which will allow some
other, higher level service description language to describe the
interface, and the bindings to it, more fully." So i see a clear way
to describe the existence of services and annotate them with
attributes. But to do the SOA dance you'd still need something like
OWL-S to describe the interface details, and WSDL2 to 'orchestrate'.

I don't see what is ebRIM giving you that, for example ISO19119 isn't? 
(apart from running code and a spec you don't have to pay for ;) ) 

2/ Data Description

The wiki writeup states that a Dataset is modelled as an
ExtrinsicObject. I look at the spec for clarification and it tells me, 
"ExtrinsicObjects provide metadata that describes submitted content
whose type is not intrinsically known to the Registry & therefore MUST
be described by means of additional attributes... e.g. Business
Process descriptions, schemas". On the basis of what i have read, i
would expect a dataset to be a plain old RegistryObject / RegistryEntry

In the example the Dataset is being extended by a lot of Slots for
different attributes it has anyway, just as a regular RegistryEntry
would be. Why is it Extrinsic? does that make a difference in the
application internals?

Trying to relate this to the minimal abstract model at 
http://wiki.osgeo.org/index.php/DCLite4G
Each property here would get a rim:Slot whose 'name' attribute is the
URL of the property e.g. http://purl.org/dc/elements/1.1/subject 

You've been able to type a custom slot that you created
(gml:EnvelopeType) and on the basis of a custom type, run a custom
query (in this case a bounding box query in PostGIS)
How much did you wind up having to extend omar to do this?

For all the Audit Trail classes in the ebRIM model, this is
personal-contact, organisational-contact for the *entry in the ebRIM
registry*, not for the data set or service itself? And here the
semantics of GetCapabilities are blurry, they tell you about who is
running the service but not about who to contact for the data. 
If i want to use ebRIM to convey originator/maintainer info about the
data, i'd define more rim:Slots that mapped to FOAF or SIOC
descriptions of people and organisations?

I've got an OWL description to hand for DCLite4G i could update.
So i *still* don't see what is ebRIM giving me that OWL isn't?

> The discover use case is nearly identical to the search use.

I'm definitely unclear about this: *is* there any difference between
'search' and 'discovery' that makes the terms non-interchangeable?
Is there an implicit "search is for humans, discovery for machines"?

> Of most interest to me is the potential for processing services to register processing metadata with the catalog, find input and register outputs!!  I will add more to this wiki discussion when I get it working.

I really look forward to seeing more of this, getting a glimpse into
where or if the discourse of "service chaining" is becoming real. 

> http://ebxmlrr.sourceforge.net/wiki/index.php/Community/ogc

> I register as much metadata as I have!!

How easy is it to register a new resource? 
Does omar's RESTful interface allow you to do this? 
E.g., gvSIG developers are interested in being able to POST a metadata
summary of a service or data set back to a catalog service, and
GeoNetwork has a non 'standard' internal interface to do this?
How 'standard' is omar's equivalent interface?  

It's still my (naive) theory that it's the combination of ebRIM with CSW2
that has been so problematic for the geospatial standards community.

I could complain a bit more about apparent of over-reliance on
standardised taxonomies, and the difficulty of relying on a
unix-style permissions model for distributed systems, but i think 
i have rambled on long enough for one day :)

yours in confusion,

jo

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
ebxmlrr-tech mailing list
ebxmlrr-tech at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ebxmlrr-tech
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/geodata/attachments/20070329/9dc07db3/attachment-0001.html