Print representation of data

Tom Morris
  • Tom Morris

    Tom Morris - 2004-02-23

    I was going to add this to the place comments, but it's really more general.

    For some researchers, generating publishable output, whether the format is HTML, PDF or dead trees, is a critical function.

    To support this function, additional representations of the data are often needed in the database.  There are some things that can be taken care of on a global basis like my home country is "United States of America" so omit when printing any locations from there, but other things need to be stored on a per record basis such as "MA" and "Mass." being alternate representations of "Massachusetts" that might be used for output.

    This stuff doesn't really show up in the data modelling view of the world, but it's critical from the point of view of a usable implementation.

    • Ed Ridpath

      Ed Ridpath - 2004-02-24

      I see the GDM as flexible - again my take is that is could have:

      Place-Part-Type: State
      Place-Part: Massachusetts
      Place-Part-Type: StateAbbr2Char
      Place-Part: MA
      Place-Part-Type: StateAbbr4char
      Place-Part: Mass.

      Now granted that is cumbersome, but I also think this is meant to be an "expert" function - which by definition means alot of data we do not have mapped out yet, such as a mapping of States to common abbreviations.

      • Tom Morris

        Tom Morris - 2004-02-24

        I think based on this and some of your other examples that we're interpreting the GDM 1.1 spec differently.  My reading (and I'll admit to not being completely facile with the notation they use) is that a place consists of an ID, a date, and either a sequence (Ascending/Descending) or a set (None) of place parts.

        If you use a sequence, which I think is how they intended you to figure out what order to print things in, there's no place for multiple values at the same level.

        If you use a set, you need external logic to decide which parts to print and in what order.

        I see no way to represent that the three place parts that you defined actually refer to the same place.

        Lastly, the two places "Boston, Mass." and "Boston, MA" will get different Place-IDs because they are composed of different Place-Part elements.

        I can see lots of ways to extend what's there to do something useful, but I don't think a literal reading of what's currently spec'd works unless I'm missing something.



Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks