[Ebxmlrr-tech] [Geodata] ebRIM storyboard

Farrukh S. Najmi farrukh at wellfleetsoftware.com
Mon Mar 26 10:34:02 EDT 2007


Hi Jo,

First please accept a warm welcome to the freebXML Registry community.
More inline below...

Jo Walsh wrote:
> 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 ... :) 
>   

+1

I am sure none of us have a lot of excess time on our hands :-)

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

The registry also may store the WSDL and XML Schema for a Service. A
WSDL and XML Profile spec of ebXML Registry
describe how to manage these artifacts in the registry. An
implementation of the WSDL Profile ships with omar.
OMAR does nothing at present towards service invocation / orchestration.
That would be the job of a specialized registry client that is
responsible for "brokered" service invocation.

> 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 ;) ) 
>   

Sorry I am not familiar with that spec but by its title ("Geographic
Information - Services") I am guessing that i6t is specific to GIS info.
regrep obviously is a lower level and more generic spec that is being
used in GIS, Healthcare, Teleco, Automotive, Government etc.
Perhaps this is something Norman can address better.

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

RegistryObject is not a concrete type. Its abstract. RegistryEntry no
onger exists as of regrep 3.0.
ExtrinsicObject also serves as the type extensibility mechanism in
regrep spec. That is how many profiles
including OGC use it (to define new domain-specific types).

> 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?
>   

While ExtrinsicObjects are the type extensibility mechanism in regrep,
Slots are the attribute extensibility mechanism.
There is no such thing as RegistryEntry anymore. When we did have it in
the model it was abstract and could not be instantiated. Same
goes for RegistryObject.

ExtrinsicObject servers two purposes:

1. Provide a type extensibility mechanism

2. Provide metadata for optional content

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

Again I do not know above reference and Norman would be better to
comment here.

> 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?
>   

Not much I imagine since a query is just an instance of an AdhocQuery
object which is just another concrete RegistryObject
sub-type.

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

Again I do not know the OGC profile well but can say that you can
associate a Person instance with
any Service instance using an Association instance where the
associationType may be OGC specifc.

------------                     ------------------               
-------------
| Person | <-------------| Association | ----------->| Service |
------------                    -------------------               
-------------
                                             |
                                             | associationType =
"primaryContact"
                                             v
                                 ---------------------------
                                | ClassificationNode |   code =
"primaryContact"
                                ----------------------------
                                              |
                                              |  parent
                                              v
                                 ------------------------------
                                | ClassificationScheme |   id =
"urn:....:AssociationType"
                                -------------------------------


> 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?
>   

Slots or Association instances as shown above would do as needed.

> 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?
>   

>From a pure modeling power perspective OWL is more expressive and it
also supports inference.
RIM is much simpler in comparison and does not aim to compete with OWL.
BTW there is an OWL Profile for ebXML Registry available:

<http://docs.oasis-open.org/regrep/v3.0/profiles/owl/regrep-owl-profile-v1.5-cd01.pdf>

In addition to the RIM, the regrep provides a set of services for
publish, management, governnace and discovery of arbitrary content.
This is where the remaining value of regrep comes to bear. Examples of
value provides include:

-A set of standard metadata for identifying, naming, describing,
classifying, relating, grouping content

-A flexible discover mechanism based on query syntax such as SQL

-A power event subscription and notification capability

-Support for fine-grained, role-based access control and authorization
using XACML policies

-Authentication using WSS and SAML

-Federation capabilities including federated searches across multiple
registries

All of these capabilities make regrep sit somewhere between a database
and a content management system on the "information management
continuum" providing some of the best value provided by both.

In summary regrep cannot be compared to OWL but RIM can to some extent.
Today regrep is being used to manage OWL ontologies and in future it is
entirely possible that oWL may be used to define the RIM.

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

I make a distinction between "Explore" and "Search". "Search" is
basically done by invoking a stored parameterized query while
"Explore" is more analogous to browsing the file system in a File System
"Explorer" window. In regrep "Explore" also includes navigating
relationship.

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

Note sure what you meant above.

>   
>> 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? 
>   

The REST interface at present is for query only. There is a REST
sub-committee in regrep TC
working to define addition to REST interface to support publish as well.

> 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?  
>   

OMARs SOAP interface for publish is an ISO standard (ISO 15000, part 4).


> 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 cannot comment on that assertion. You and Norman would be better
positioned to do that - When you do please make sure to provide
specifics. Otherwise it remain an assertion that no one can confirm or deny.

> 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 :)
>   

regrep does not use a unix style permissions model. It uses another
standard called XACML for fine-grained, role-based access control and
authorization. It is in my experience the most powerful access control
mechanism I have ever encountered.

> yours in confusion,
>   

I hope that you find this is helpful. All the best.

-- 
Regards,
Farrukh

Web: http://www.wellfleetsoftware.com




More information about the Geodata mailing list