One of the regular 2-monthly meetings of the technical comittee, subcommittees and working groups.
About 140 members of the OGC and invitees.
From JRC: Sargent (SAI)
Continuation of technical work devising and agreeing interface standards within the remit of the OGC.
The OpenGIS Consortium (OGC) convenes its technical committee six times a year. The last half-day overlaps with the OGC Management Committee meeting which then takes another day after the Technical Committee finishes. I attended all three and a half days of the Technical Committee.
Full reports and current technical papers, attendee lists and policy statements can be found on: http://www.opengis.org
The technical committee meets together only for scheduling, conclusion/reporting and new generic "technology awareness" presentations. Most of the time is spent in smaller meetings of Special Interest Groups (SIGs), Working Groups (WGs) or ad hoc groups of three or four people and one Task Force (TF). The ad hoc groups are generally where the innovative thinking is done. There were two generic software technology talks: RFC/XML from Netscape and DNA from Microsoft; each for an hour.
The following groups met, some several times:
· Catalog WG
· Feature SIG
· Metadata SIG
· Coverage WG
· Revision TF
· Transport SIG*
· Defense and Intelligence SIG*
· Core Service Architectures discussion
· Transfer Technology WG
· Telecommunications SIG
· WWW Mapping SIG
· Feature Identity for Relationships (informal)
I attended at least one working meeting of every group except those asterisked (*) which only met once at the same time as I was in another meeting. However, I was present at the plenary conclusions of these groups.
How the OGC works
The Technical Committee exists to issue RFP (Requests for Proposals) documents. These identify a small, achievable need and request companies to propose a detailed software specification. Out of those proposed, the TC will approve and adopt at most one. To help set a context for this work, the TC continually edits a set of documents called "The Abstract Specification".
Central Results
Each group produced new work, but the major new thinking which affected many groups were:
· The absolute need for Relationships to be formally described before any of the industry-specific groups (Transport, Telco etc.) or Advanced Features group (topology, constraints, complex geometries) could make any further progress whatsoever.
· The absolute dependence of Relationship description on Feature identity.
· That minimal feature identity is possible without dataset identity, but that dataset identity is extremely desirable.
· A greater understanding of precisely how metadata technologies and their development into semantic repositories aids real-time interoperability, not just dataset identification. This is closely related to the central issue widely agreed at the NCGIA Conference the previous week.
· OGC formally adopted the language and definitions of the ISO TC211 Metadata Standard (draft 3.1 which will become Part 15 of ISO 15046 eventually).
· Display architecture and interfaces for Web-enabled GIS clarified a confused area.
Display and WWW Mapping
Discussion of Web-enabled interoperable GIS was thrust in a new direction by a discussion paper by Adrian Cuthbert (Laser-Scan, Cambridge) describing a "display stack" architecture for vector geographic data. This showed how GIS features were distinct from their representation styles which then in turn had to be rendered into some visible picture on screen or paper.
For example, a wood is a polygon feature, it can be styled either as a fill pattern of trees pictures or a green shading; when rendered onto a display the green colour may have to match an available colour palette, or the tree pictures would have to be scaled to be visible to the eye.
One key insight is that the style selection has to be done knowing what display devices are available. This is exactly analogous to font-selection in a word-processor (style) having to be conscious of what fonts are available on a printer driver (rendering).
Transmission over the Internet WWW can either be Features, Features+Style, or Rendered Image. The software applying the style or doing the rendering can be normally stored on the client or server machines, and executed on either. All those options multiply to produce the entire range of Internet GIS architectures (some combinations are impossible or pointless). If features are transmitted, then this is the existing OpenGIS Simple Features Interface architecture.
Further discussion produced the agreement that OpenGIS could not mandate architectures, so the various APIs (application programming interfaces) present in the display-stack architecture were collapsed into an "architecture neutral" diagram. The OGC is only allowed to standardise interfaces not architectures so this was the only legal course of action.
Telecom Conclusions (Tom S.)
· First priority is to do feature-relationships and feature identity.
· Do further decomposition of use-cases so that specific-telecom features can be identified.
· The presentation of the data is important; work must continue with WWW SIG so that the next level of requirements can be identified.
Coverages Conclusions (John Herring)
· For the first Coverages RFP the 15 types must be reduced to 3: Grids, Images and Digital Matrices. These will all be georectified: a regular pixel grid in the space which it represents.
· The RFP will be issued on 15 March 1998 and will include updates to the Abstract SPecification to be done in February at Munich.
Transfer Technology Conclusions (Shel Sutton)
· The RFP will be adjusted to allow proposals based on RDF to be allowable.
· It is intended to issue the RFP in March 1998.
Services Architecture Conclusions (Shel Sutton)
· The Abstract Spec. will be adopted pending the changes agreed.
· The Object Model part of the Abstract Spec. will be finished at the next meeting, then the Services Architecture SIG will form WGs and disband.
Metadata Conclusions (Kathleen)
· OGC has agreed to adopt ISO TC211's metadata draft pro tem. The Draft International STandard (DIS) is expected in October 1998.
· OGC's standards must allow any standard's body's metadata, OGC exists to produce standard interfaces to read and write metadata, not the terms and definitions themselves.
Transport Conclusions
· 18 people met for 1 hour. A draft document for setting up a SIG at Munich in February 1998 was agreed.
· Iguana and TeleAtlas companies were represented.
Features Conclusions
· Relationships and Feature Identifiers were discussed.
· Feature IDs in relationship references can be null.
· Feature IDs are visibly persistent at least for the current "session".
· Complex geometry features and dimensioning were agreed to be things that the abstract spec. should cover naturally, not by making special allowances.
· Changes to the abstract spec. agreed by extensive discussion will be made by January 18th, 1998. Sam Bacharach will draft some APIs.
Catalog Conclusions (John B.)
· The RFP could not be completed as planned. It will be released after the February meeting in Munich.
· The RFP will be platform-neutral, i.e. only one RFP will be issued for SQL, COM and CORBA instead of the usual three. Proposals in response to the RFP will have to produce both ISO and Microsoft IDL (Interface Description Language) descriptions.
WWW Mapping Conclusions
· The FGDC CORBA-based demonstration using OpenGIS wrappers was reviewed.
· What "assemblers" do was discussed.
· The information transformations in the "display stack" was discussed and a diagram ("cartoon") proposed for the Abstract Spec. (to be drawn up by Cliff Kottman).
· Adam G-T (Cadcorp, UK) will draw up some API examples.
· . Features "know" how to present themselves in a way that users can override to suit their display technology.
· The concept os a "session" during display is important as it determines context, and context determines the display characteristics.
Defense and Intelligence Conclusions
· Agreed that a demonstration similar to FGDC's, but "militarized", was needed.
· Lewis Heck will produce development timelines for this.
· TEM's proposed transfer technology APIs will beobtained and revied by the OGC.
Other Conclusions
· All diagrams in the Abstract Specification will be redone in UML (Unified Modelling Language) using Rational Rose.
· The draft COnfromance Testing procedures have been posted to the OGC website.
· CORBA and Microsoft COM have defined different standard utilities and services, so even if the IDLs could be equivalent, the designs should not be. Even if the designs are equivalent, they will not interoperate between CORBA and COM. Experience with RFP1 (Simple Features) supports this conclusion. OGC is only attempting interoperability within any one of three distributed computing platforms: SQL, CORBA or COM.
Attendees
These people attended but their names were not on the first official lists:
Katsunori Harashima NSDIPA National Spatial Data Infrastructure Promoting Association
www02.so-net.or.jp/~nsdipa/index.html
Simon Cottingham Space Dept., Arthur C Clarke Building, DERA, GU14 0LX, UK
S_L_Cottingham@scs.dera.gov.uk
Adam Gawne-Cain Cadcorp
Dipl.-Inform Uwe Henze Tele Atlas
Peter Southwood Autodesk Inc.
Peter Ladstaetter Siemens Nixdorf
New Generic Technology: RDF/XML (RV Guha, Netscape)
This is a radical and potentially revolutionary technology: Research Description Framework (RDF). It is very simple: RDF is an encoding method for a node/link data model in XML. XML is the next generation HTML which will allow new sub-dialects (i.e. new sets of tags) to be used without having to go through an international standardisation activity, e.g. dialects for mathematics, electronics circuit diagrams, expenses claim forms etc. XML is not the important innovation here, it's simply a transport so that RDF can be sent over the WWW.
RDF data models can reference a URL for any link or node, so metadata repositories can be shared worldwide. Hopefully, new software systems written from scratch using RDF will thus have a much greater semantic homogeneity than separately-developed systems. As was seen in the NCGIA Conference, semantic mismatch is the central, major issue in GIS interoperability today.
One problem of pre-existing GISs is that their semantics are only implicitly defined in their operations: there is no separate definition of what the detailed, deep metadata is or means. (As distinct from the superficial, summary metadata which is covered by existing metadata standardisation activities.) RDF can help pre-existing GISs by providing a standard notation for describing those semantics such that RDF wrappers can be written around such legacy systems.
RDF "statements" are also queries: "match this". So a full query language is available with no further specification work.
Producing RDF wrappers for existing GISs would be a huge undertaking. The previous week at NCGIA Interop'97, David Schell (President of OGC) suggested that the only reason that Federated GISs hadn't been developed was that no-one had yet spent a billion dollars on the problem. RDF would appear to be the core technology on which it might be sensible to begin to think of spending that billion dollars.
The use of XML has one great advantage: people using standard web browsers will at least be able to read and navigate any RDF data model. Writing software to use an RDF data model automatically will also be easier than if a binary encoding were used since XML parsers will be available as standard software components.
RDF documents are available at:
http://www.w3.org/Metadata/RDF/
New Generic Technology: DNA (Mark Ryland, Microsoft)
Digital interNetwork Architecture is Microsoft's new name for the incremental development of its existing technologies. Since Microsoft's technology controls 95% of machines that people now work at, it is important to know what will become easier to do and what will remain hard. Any standardisation body should aim at using as much techology developed by other people as possible to reduce overlap and speed standards development.
Existing technologies are NT services, Message Queue, Web-enabled desktop, PC management and Dynamic HTML offerings. The Microsoft presenter himself called it a "marketecture" meaning that it is a collection of whatever is to hand. A copy of the presentation will be downloadable from ftp://ftp.microsoft.com/developr/drg/com/ The major new elements within the next 12 months are:
· The completely new Kerberos access-control in NT 5 - for easier secure management.
· A centralised "Class Store" on NT 5 servers replacing the registry (which is currently on every machine, not just servers) - for easier management.
· Extensions to ODBC, ADO and OLE/DB (using XML) to enhance ease of use by programmers.
· Multiple, simultaneous interfaces for COM objects to enhance versioning and shared use by separately-developed applications, reference counting across the network and unified exception handling - for robustness.
· Custom marshalling to support non-RPC wire protocols and better multi-threading - for speed.
· 64bit support for COM objects, but not for DLLs - for the Intel Merced chip (prototyped on Alpha).
A little more than 12 months away will be:
· Another completely new Internet-based public-key infrastructure (PKI) access-control system in NT 6 to replace Kerberos in NT 5.
· COM+ will include Microsoft Transaction Server as standard. (Presumably this means that standalone NT workstations will disappear: every workstation may have to be attached to a server, if only intermittently ?)
· Dynamic skeleton server (copied from CORBA)
· Standard cross-language elemental datatypes, auto-marshalling, auto-persistance, declarative event model, declarative transaction service in COM+. Extensions to the C++ language. All to make it easier for C++ programmers to produce these new sophisticated, but slightly slower COM+ objects.
All these initiatives are intended to make COM even easier to use by a wider range of programmers and to spread Microsoft COM-based operating systems onto a wider variety of computer types. If Microsoft succeeds there is one major side-effect that could affect OGC: CORBA could be left behind and lose support.
Philip Sargent
TP 950
21020 Ispra (VA)
Italia