[IGS-DCWG-103] Invitation to participate - IGS metadata exchange via XML

Markus Bradke bradke at gfz-potsdam.de
Mon Mar 2 07:32:47 PST 2015 

Dear colleagues,

Finally we had some time to think about the XML SiteLog definition. 
Sorry for the late reply.

As first draft we would like to propose the attached XML file. Actually 
it captures most of the ideas mentioned before with some additional 
features:

   * Use as less nesting as possible, e.g. in section 8.

   * We deleted some (from our point of view) unnecessary and hardly 
used fields, e.g. in section 0 and 13.

   * We would rather use the country code in section 2, e.g.
     <mi:countryCode>DEU</mi:countryCode>

   * We like the idea of using decimal degrees for latitude and 
longitude as you can already use them in the generation of maps.

   * We would like to split the block for the satellite systems into 
multiple tags, e.g.
     <equip:satelliteSystem>GPS</equip:satelliteSystem>
     <equip:satelliteSystem>GLO</equip:satelliteSystem>

   * We would like to split the effectiveDates block into start and end.

   * We would like to avoid value fields with units, the definition 
should be placed in the tag name, e.g. <markerArpUpInMeters>

   * In section 8 all available meteorological sensors (from RINEX v3) 
should be listed. As first idea we inserted the wind sensor.

   * We would like to give up the separation of the agency block in 
"responsible" and "on-site". We would like to use one block definition 
("Agency") and define an attribute, what function the agency has.

   * Further more we split the agency mail address to Street and Number, 
Postal Code, City and Country, because it does make it more consistent 
and unique to enter the data.

   * For the agency contact details we would like to use a nesting as 
you can define more than 2 contacts. One could "determine" their 
responsibility with an attribute.

   * We deleted the fax number (no one really uses fax anymore?)

   * In block 13 we would like to see the DOI (Digital Object 
Identifier) to reference station data in publications.

   * We also prefer to use multiple "Data Center" tags instead of 
primary and secondary ones.


If we implement some rules, the mentioned changes should also be 
backward-compatible (except for some deleted blocks that would be empty 
or filled automatically).

This is something we shouldn't lose sight of as there are users abroad 
from the IGS community. Therefore we would like to keep the schema 
definition files (xsd) and namespaces as described by SOPAC.

We are looking forward to your comments.

Kind regards,
Markus


On 02/26/2015 07:24 PM, Fran Boler wrote:
> Dear Colleagues-
>
> As we hoped, there has been a lot of interest in this topic, from many
> individuals and groups.  I have some comments on the XML schema (below)
> to add to what others have offered. If anyone else has thoughts before
> we start the next round of discussion, please send them to this list in
> the next few days. We will be assembling comments into  a folder on
> Google drive and sharing with active participants. There are several
> proposals on the table and we will be requesting comments on all of the
> proposals in this next round.
>
> My comments on the XML:
> I would like to suggest that we add change tracking to the XML in the
> form of date elements, e.g.:
>
> *
>
> <dateInserted></dateInserted>
>
> <dateDeleted></dateDeleted>
>
> <deleteReason></deleteReason>*
>
> The dateInserted field is self-explanatory. This would apply to all
> blocks. For a new site, multiple blocks will have the same insertDate.
> Except for cases of inadvertent errors in metadata publically presented
> by any system, the dateDeleted element would not be populated (and
> similarly deleteReason), and should be rarely used. However, if a
> mistake happened and incorrect metadata was publically available, this
> addition would allow the error to be documented, not simply replaced
> with the correct metadata. Further, the dateInserted/Deleted elements
> could be used for replacing the Modified/Added sections of the
> formInformation block, rather than separately storing that information.
> Since the XML schema does not explicitly use block numbering, the
> handling of the modified/added sections becomes ambiguous anyway.
>
> For discussion on use of elements:
> In the formInformation block, datePrepared should be dynamically
> generated. preparedBy should be the Agency/system that produces the XML.
> One could infer that if preparedBy is different than the agency in
> responsibleAgency, then the information could be one step or more
> removed from its authoritative source, and therefore potentially less
> reliable. This assumes that responsibleAgency is the right place for the
> authoritative holder of the metadata, or is another element to represent
> this needed?
>
> Could the representation of latitude and longitude be reconsidered in
> light of the updated ISO 6709 allowing decimal degrees and other changes?
>
> More soon,
> Fran
>
>
>
> On 1/9/15 10:00 AM, Fran Boler wrote:
>> Author: Fran Boler, Carey Noll
>>
>>
>> Dear Colleagues-
>>
>> As many of you know, at the IGS workshop in Pasadena this past June
>> there was discussion in the infrastructure and data center breakouts
>> about transmitting IGS site log metadata between data centers using
>> XML, using automated machine-to-machine transfer mechanisms. With the
>> introduction of the IGS Site Log Manager system, we believe the time
>> is right to do this. Advantages could include more rapidupdating of
>> site log information, more consistent information across data centers,
>> and more accurate metadata overall. Several data centers are committed
>> to moving forward on this effort in the next few months. In order to
>> implement such an exchange the first step will be to agree on the XML
>> schema to be used. SOPAC has had a longstanding geodesy XML project
>> (http://sopac.ucsd.edu/xmlGeodesy.shtml), and this is the ideal
>> starting point. We would like to kickoff this effort by requesting
>> feedback on the SOPAC Site Log XML schema.
>>
>> Those who would like to participate in this effort should respond with
>> an email (to IGS-DCWG at igscb.jpl.nasa.gov) as soon as possible
>> indicating your interest. *Please mention your level of involvement
>> as: “observer” or “planning to participate in the discussions” or
>> “planning to participate in discussions and work on implementation”.
>> *(Note:If you, as an igs-dcwg list member, do not have an interest in
>> this topic, you may wish to change your subscriber option to digest
>> for this list, or otherwise amend your subscription as there will be
>> additional traffic during this effort.)
>>
>> For those who will be active at this phase, please look at the SOPAC
>> Site Log XML schema and plan to provide comments to this list within
>> one month. Your comments should include any suggested amendments or
>> additions. As a rough timeline we would like to complete discussions
>> of the schema during February and begin discussing implementation
>> specifics no later than March.
>>
>> We wish to be inclusive and therefore ask you to circulate this
>> invitation to interested colleagues. All interested persons should
>> ensure that they are members of the igs-dcwg maillist by visiting
>> http://igscb.jpl.nasa.gov/mailman/listinfo/igs-dcwg.
>>
>> Kind regards,
>> Fran Boler, IGS Governing Board Data Center Representative
>> Carey Noll, IGS Data Center Working Group Chair
>>
>>
>>
>>
>> _______________________________________________
>> IGS-DCWG mailing list
>> IGS-DCWG at igscb.jpl.nasa.gov
>> http://igscb.jpl.nasa.gov/mailman/listinfo/igs-dcwg
>
>
>
> _______________________________________________
> IGS-DCWG mailing list
> IGS-DCWG at igscb.jpl.nasa.gov
> http://igscb.jpl.nasa.gov/mailman/listinfo/igs-dcwg
>


-- 
M.Eng. Markus Bradke

Helmholtz Centre Potsdam
GFZ German Research Centre for Geosciences
Department 1: Geodesy and Remote Sensing
Section 1.1 : GPS/Galileo Earth Observation

Telegrafenberg
Building A17, Room 10.09
D-14473 Potsdam

Phone: +49 331 288-1182
Fax  : +49 331 288-1759
Mail : markus.bradke at gfz-potsdam.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GFZ_Sitelog_Draft.xml
Type: text/xml
Size: 14289 bytes
Desc: not available
URL: <http://lists.igs.org/pipermail/igs-dcwg/attachments/20150302/5b82b75c/attachment.xml>

More information about the IGS-DCWG mailing list