Bryan Lawrence : Bryan's Blog 2006/04/06

Bryan Lawrence

... personal wiki, blog and notes

Bryan's Blog 2006/04/06

Curating metadata aka XML documents

Andy Roberts (via Sam Ruby) has defined a markup language for describing changes to xml documents.

One of the things that has worried me for a long time about relational systems for storing metadata is that it is non-trivial to reliably maintain metadata provenance. I don't want relational integrity, I want historical integrity (and don't give me rollback as an answer). One of the reasons why I like XML as a way of dealing with our scientific metadata as it is much more intuitively obvious how one deals with provenance (one keeps old records), but differencing xml documents is tedious and in the long run keeping multiple copies of large documents with minor changes is expensive.

I'll be interested to see if the delta web gains any traction.

by Bryan Lawrence : 2006/04/06 : Categories metadata ndg curation (permalink)

Standard Invention

Allan Doyle's blog introduced me to the SurveyOS project. These guys purport to be

sponsoring the development of Geospatial Standards For Free Software. These standards will provide a way to share geospatial data between oepn (sic) source applications in a vendor-neutral, XML based format.

Sound like dejavu? Well these folks recognise this up front:

Many GIS users will be critical of setting up an additional set of open standards for geospatial technology, when the OGC already maintains a set of similar standards. While we recognize the benefits of a unified approach to standards design, we believe there are some serious and fundamental flaws in the approach OGC takes to standards development.

Well, I'm not a GIS user (yet), but I'm sure critical of this. What we don't need is even more nugatory effort reinventing wheels. Anyway, they their reasons why they don't like OGC, so let's see if we can make some sense of their reasons:

  1. The OGC is about geospatial standards, but it is not about free and open source software.

    • True, but as the SurveyOS guys admit: OGC promotes the development and use of consensus-derived publicly available and open specifications that enable different geospatial systems (commercial or public domain or open source) to interoperate. So this might be a good case for folk to build open source implementations of OGC standards, not a good case for creating new standards.

  2. Membership to the OGC is expensive and exclusive.

    • True. But it's not hard to get involved, even without investing money. The issue would appear to be that the surveyOS folks want to influence the standards without paying to sit at the table. I understand the motivation. We've paid the minimum we can to sit close, and we don't have a vote, but I've seen no evidence that the OGC community ignore good technical advice.

  3. The OGC focus a great deal of its efforts on GIS for the web. Some of us still use GIS on the desktop. GIS and the internet are a powerful combination, but they are not the solution to every problem. The GSFS will also focus its efforts on GIS for the desktop.

    • This might be valid, but frankly what sits under the hood of a gui can have the same engine as something that sits under the hood of a browser. But even if we believe this point, it's an argument to develop a complementary set of protocols not a competing set.

  4. OGC specifications are difficult to read and understand.

    • True. And there are a lot of them as well. But why not get involved in documenting what exists, rather than developing new things? The SurveyOS web page says: We will give explanations, go into details, provide examples, and explain technical jargon. Our specifications will be designed to read like a book or tutorial, not like a specification. So why not write a book or a tutorial for the OGC specs?

  5. The OGC Provides A Standard But No Implementation. There are a few open source projects that implement the OGC standards ... Every standard adopted as a part of GSFS will be developed in conjuction with an open source implementation that can be used as an example for other developers.

    • This is the worst of the lot. Let's rephrase this to tell it like it is: Because some folk have spent years developing some technically excellent standards and have done the initial implementations in the commercial world, and not built us an open source implementation, we will take a few months (years?) to develop our own standards, and build our own implementations which wont interoperate with the others. How does that help anyone? There is nothing to stop the surveyOS guys from building their own open source implementations of any OGC spec.

They conclude with this statement:

The SurveyOS will make an effort to learn from and adopt portions of the OGC standards, but believes the problems listed above require a separate effort at creating geospatial standards.

What a waste of effort. I agree that the OGC standards are daunting in their complexity and volume, and agree that they depend heavily on the ISO standards which are expensive to obtain, but in my experience they have covered sucha lot of ground that repeating the effort will be really nugatory.

I'm a big fan of open source developments. Indeed the NDG is open source, and building on OGC protocols. I recognise the advantages of competition in developing implementations, but if one wants to repeat the standards work, one should base the argument for doing so around where the standards are deficient, not whether or not there are open source implementations of the standards!

Is the bottom line that these people too lazy to read the specs properly?

by Bryan Lawrence : 2006/04/06 : Categories ndg : 5 comments (permalink)

Schedule Chicken

I found Jim Carson's write up on schedule chicken via Dare Obasanjo.

Food for thought in the software industry, or any industry actually!

by Bryan Lawrence : 2006/04/06 : Categories management (permalink)


DISCLAIMER: This is a personal blog. Nothing written here reflects an official opinion of my employer or any funding agency.