Re: [galeon] [WCS-2.0.swg] GML coverages / xlink (was: Re:CF-netCDFstandards initiatives)

NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.

The full snippet below is:

            <valueComponent
                
xlink:href="http://www.unidata.ucar.edu/software/netcdf/examples/tos_O1_2001-2002.nc#tos";
                xlink:role="urn:mimetype:application/x-netcdf" 
xlink:arcrole="QuantityList">
                <QuantityList uom="K"/>
            </valueComponent>

 

My suggestion is that:

·        the fragment identifier 'tos' refers to a netCDF variable called tos 
within the file .....tos_O1_2001-2002.nc (RFC 3986 says the semantics of a 
fragment id depend on the media type, so this part is OK)

·        the xlink:role says that the file is netCDF (so I now know how to read 
it, what '#tos' means, and that I'll get back a bunch of numbers)

·        the xlink:arcrole is an xpath that means to insert those numbers in 
the child QuantityList element (arcrole in xlink is loose, but intended to 
convey the relationship between the target resource with respect to the source; 
my proposal is consistent with this, and also with GML which phrases is thus: 
"description of the role or purpose of the target resource in relation to the 
present resource, given as a URI")

 

I think this profiled use of xlink gives us a quite flexible, but neat, way of 
integrating various non-GML content within the semantically tight framework of 
GML and ISO TC211.

 

 

From: Ron Lake [mailto:rlake@xxxxxxxxxxxxx] 
Sent: 28 August 2009 01:41
To: Woolf, Andrew (STFC,RAL,ESC); Whiteside, Arliss E (US SSA)
Cc: Unidata Techies; Ben Domenico; Carl Reed; Unidata GALEON; wcs-2.0.swg
Subject: RE: [galeon] [WCS-2.0.swg] GML coverages / xlink (was: 
Re:CF-netCDFstandards initiatives)

 

Hi Andrew:

 

Use of XPointer expressions is (was) the recommended means to refer to XML 
Schema fragments (xlink:role was gml:remoteSchema). This is (was) also the 
recommended means to refer to remote content where that content is XML (from 
the XPointer spec).

 

In GML, a property with an xlink:href means that the value of the property can 
be determined from the value of the xlink:href (this is just a URI).   It is 
application dependent, meaning that it is up to an application schema to define 
whether or not the URI is also a URL.  Note that in the RDF from which this 
derives (rdf:resource = "..") the reference was always interpreted (if I recall 
RDF correctly) as a URL.  I would interpret your example as saying that the 
xlink:href = 
"http://www.unidata.ucar.edu/software/netcdf/examples/tos_O1_2001-2002.nc#tos 
<http://www.unidata.ucar.edu/software/netcdf/examples/tos_O1_2001-2002.nc#tos> 
" as meaning that 
"http://www.unidata.ucar.edu/software/netcdf/examples/tos_O1_2001-2002.nc#tos 
<http://www.unidata.ucar.edu/software/netcdf/examples/tos_O1_2001-2002.nc#tos> 
" can be resolved to a valueComponent.

 

Do you have an example (I may have missed it) where you use the XPath 
expression in your arcrole to locate it somewhere else?


R

 

 

 

From: galeon-bounces@xxxxxxxxxxxxxxxx [mailto:galeon-bounces@xxxxxxxxxxxxxxxx] 
On Behalf Of Woolf, Andrew (STFC,RAL,ESC)
Sent: August 27, 2009 4:12 PM
To: Whiteside, Arliss E (US SSA)
Cc: Unidata Techies; Ben Domenico; Carl Reed; Unidata GALEON; wcs-2.0.swg
Subject: Re: [galeon] [WCS-2.0.swg] GML coverages / xlink (was: 
Re:CF-netCDFstandards initiatives)

 

In my proposed 'best practice profile' of the use of xlink for referring to 
file-based content, I'm suggesting that arcrole define a local XPath to the 
location at which the content is to be logically inserted (the child 
QuantitytList element in this example).

 

It's not unusual to use XPointer as a fragment identifier in a URI, so we can 
finesse the syntax of doing this. The novelty of this proposed xlink profile is 
in interpreting arcrole in this manner. I believe it is perfectly consistent 
with the xlink spec (and also with GML).

 

From: Whiteside, Arliss E (US SSA) [mailto:arliss.whiteside@xxxxxxxxxxxxxx] 
Sent: 21 August 2009 21:42
To: Woolf, Andrew (STFC,RAL,ESC)
Cc: Ben Domenico; Unidata GALEON; wcs-2.0.swg; Unidata Techies; Carl Reed
Subject: RE: [WCS-2.0.swg] GML coverages / xlink (was: Re: CF-netCDFstandards 
initiatives)

 

Andrew,

 

Sorry, it is not clear to me what this XML example is intended to show.  Is it 
intended to show referencing of a CF-netCDF file?

 

If so, I think the XML fragment 

[<valueComponent  
xlink:href=http://www.unidata.ucar.edu/software/netcdf/examples/tos_O1_2001-2002.nc#tos
 <http://www.unidata.ucar.edu/software/netcdf/examples/tos_O1_2001-2002.nc#tos> 
]

is NOT correct if the referenced file is not the GML encoding of one of the 
four specified gml:Value alternatives.  (Notice that the <documentation> of 
gml:valueProperty defines it as "Property that refers to, or contains, a 
Value.")

Arliss
  

________________________________

From: Woolf, Andrew (STFC,RAL,ESC)
Sent: Thursday, August 20, 2009 4:29 AM
To: Peter Baumann
Cc: Ben Domenico; Unidata GALEON; wcs-2.0.swg; Unidata Techies; Carl Reed; 
Robin,Alexandre
Subject: Re: [WCS-2.0.swg] GML coverages / xlink (was: Re: CF-netCDFstandards 
initiatives)

 

<RectifiedGridCoverage id="tos_O1_2001-2002">
    <domainSet>
        <RectifiedGrid dimension="3" id="tos_O1_2001-2002.domain">
            <limits>
                <GridEnvelope>
                    <low>0 0 0</low>
                    <high>23 169 179</high>
                </GridEnvelope>
            </limits>
            <axisLabels>x y t</axisLabels>
            <origin>
                <Point id="tos_O1_2001-2002.domain.origin" 
srsName="urn:x-ogc:def:crs:badc:TimeLatLon:2001-01-01:1d">
                    <pos>-79.5 1 1</pos>
                </Point>
            </origin>
            <offsetVector 
srsName="urn:x-ogc:def:crs:badc:TimeLatLon:2001-01-01:1d">1 0 0</offsetVector>
            <offsetVector 
srsName="urn:x-ogc:def:crs:badc:TimeLatLon:2001-01-01:1d">0 1 0</offsetVector>
            <offsetVector 
srsName="urn:x-ogc:def:crs:badc:TimeLatLon:2001-01-01:1d">0 0 2</offsetVector>
        </RectifiedGrid>
    </domainSet>
    <rangeSet>
        <ValueArray gml:id="tos_O1_2001-2002.range">
            <valueComponent
                
xlink:href="http://www.unidata.ucar.edu/software/netcdf/examples/tos_O1_2001-2002.nc#tos";
                xlink:role="urn:mimetype:application/x-netcdf" 
xlink:arcrole="QuantityList">
                <QuantityList uom="K"/>
            </valueComponent>
        </ValueArray>
    </rangeSet>
</RectifiedGridCoverage>

 

(The referenced CRS is a composite using a TM_CoordinateSystem 
(gml:TimeCoordinateSystem) for time, with origin 2001-01-01 and interval 'one 
day'.)

 

Our current CR 07-112 will enable analogous use of CF-netCDF files using 
'auxiliary coordinate variables' for a gml:ReferenceableGrid.

 

Cheers,

Andrew

 

From: Peter Baumann [mailto:p.baumann@xxxxxxxxxxxxxxxxxxxx] 
Sent: 20 August 2009 10:50
To: Woolf, Andrew (STFC,RAL,ESC)
Cc: Robin, Alexandre; Max Martinez; Ben Domenico; Unidata Techies; Unidata 
GALEON; Carl Reed; wcs-2.0.swg
Subject: GML coverages / xlink (was: Re: [WCS-2.0.swg] CF-netCDF standards 
initiatives)

 

Andrew-

I anyway wanted to contact you on the xlink question.

Your approach as presented at the Boston TC meeting I consider the missing link 
for WCS: we consider coverages delivered as a manifest (XML) and one or more 
encoded files, referenced from the manifest. It seems like your approach allows 
to mimic this in GML. Is that correct?

As we currently are seriously considering adopting GML for the WCS 2.0 coverage 
model such a facility is of high importance to us.

-Peter

PS: this might also resolve the dispute of this thread: GML coverages can well 
reference a netCDF file then, can't they?


Woolf, Andrew (STFC,RAL,ESC) wrote: 

I'd say the same thing about GML - it's already possible to use GML to provide 
a canonical encoding linked to an underlying conceptual model AND xlink to 
netCDF for the actual content.

 

Andrew

 

From: wcs-2.0.swg-bounces+andrew.woolf=stfc.ac.uk@xxxxxxxxxxxxxxxxxxxxxxxx 
[mailto:wcs-2.0.swg-bounces+andrew.woolf=stfc.ac.uk@xxxxxxxxxxxxxxxxxxxxxxxx] 
On Behalf Of Robin, Alexandre
Sent: 20 August 2009 09:16
To: Max Martinez; Ben Domenico; Peter Baumann
Cc: Unidata Techies; Unidata GALEON; Carl Reed; wcs-2.0.swg
Subject: Re: [WCS-2.0.swg] CF-netCDF standards initiatives

 

FYI,

 

SWE Common can serve to send very efficiently packaged datasets (binary, 
compressed binary) just like NetCDF does while providing robust metadata 
describing the datasets.

These datasets can be N-D grid coverages, discrete coverages, or any other kind 
of sensor observations or model results.

 

The point for us to build SWE Common rather than just reusing NetCDF was to 
support efficient random access in huge datasets and real time streaming data 
(which NetCDF is not designed for) with a single model.

Both cases are supported and I am pretty sure we can generate a SWE Common 
encoded binary stream that is byte-to-byte compatible with the data section of 
a NetCDF file.

 

Developing a module for the NetCDF API dealing with SWE Common would be quite 
trivial thanks to the harmonization work we have already done.

 

Regards,

 

-------------------------------------------------

Alexandre Robin

Spot Image, Web and E-Business

Tel: +33 (0)5 62 19 43 62

Fax: +33 (0)5 62 19 43 43

http://www.spotimage.com <http://www.spotimage.com> 

Before printing, think about the environment

 

 

________________________________

De : Robin, Alexandre 
Envoyé : jeudi 20 août 2009 10:01
À : 'Max Martinez'; Ben Domenico; Peter Baumann
Cc : Unidata Techies; Unidata GALEON; wcs-2.0.swg; 'Carl Reed'
Objet : RE: [WCS-2.0.swg] CF-netCDF standards initiatives

 

Ben,

 

I hope we don't have to define a NEW standard but rather work with you to see 
how we can treat your use cases with SWE Common (which already incorporates 
some NetCDF concepts and is VERY close to NcML).

I already looked at the issue and writing a converter (even the 'on the fly' 
kind) between the two formats should be no problem at all.

 

Bringing legacy formats (be them pseudo-defacto standards of a community) into 
OGC is NOT going to help interoperability across domains...

 

Regards,

 

-------------------------------------------------

Alexandre Robin

Spot Image, Web and E-Business

Tel: +33 (0)5 62 19 43 62

Fax: +33 (0)5 62 19 43 43

http://www.spotimage.com <http://www.spotimage.com> 

Before printing, think about the environment

 

 

________________________________

De : wcs-2.0.swg-bounces+alexandre.robin=spotimage.fr@xxxxxxxxxxxxxxxxxxxxxxxx 
[mailto:wcs-2.0.swg-bounces+alexandre.robin=spotimage.fr@xxxxxxxxxxxxxxxxxxxxxxxx]
 De la part de Max Martinez
Envoyé : jeudi 20 août 2009 03:19
À : Ben Domenico; Peter Baumann
Cc : Unidata Techies; Unidata GALEON; wcs-2.0.swg
Objet : Re: [WCS-2.0.swg] CF-netCDF standards initiatives

 

Ben,

 

What exactly is an "OGC binary encoding standard"? Is CF-netCDF attempting to 
be the first of its kind or are there other examples?

 

Max

 

________________________________

From: wcs-2.0.swg-bounces+max.martinez=erdas.com@xxxxxxxxxxxxxxxxxxxxxxxx 
[mailto:wcs-2.0.swg-bounces+max.martinez=erdas.com@xxxxxxxxxxxxxxxxxxxxxxxx] On 
Behalf Of Ben Domenico
Sent: Wednesday, August 19, 2009 1:19 PM
To: Peter Baumann
Cc: Unidata Techies; Unidata GALEON; wcs-2.0.swg
Subject: [WCS-2.0.swg] CF-netCDF standards initiatives

 

Hello,

 

Some confusion has resulted from the fact that we are pursuing two parallel 
efforts at standardizing CF-netCDF within the OGC.  

 

The first initiative began a few years ago.  The goal is to establish CF-netCDF 
as an extension standard for WCS encoding of data in binary form.   Stefano 
Nativi just sent out an email announcing the latest revision of the proposed 
"discussion paper" on that topic.  This will be discussed and hopefully voted 
on at the September/October TC meeting.

 

At the same time, we have a new initiative to establish CF-netCDF as a separate 
 OGC binary encoding standard.    This approach will result in a binary 
encoding which can be used with different access protocols, e.g., WFS or SOS as 
well as WCS.   Of course, in the long run, our objective is to tie the two 
approaches together, but we do not want to impede progress on either right now 
by making them formally interdependent.  A very rough draft of the core 
standard for CF-netCDF is on the GALEON wiki at:

 

http://sites.google.com/site/galeonteam/Home/cf-netcdf-candidate-standard

 

As you can see, the draft for the OGC core is based on the NASA Earth Science 
Data System standard (NASA ESDS-RFC-011v1.00). We hope to have this candidate 
standard in the proper OGC template form by the September/October TC and will 
have an ad-hoc session at which we plan to establish a SWG.   Since there is 
already a large community of practice, endorsement by other standards groups 
(NASA and NOAA in the US), and solid reference implementations, we hope to move 
forward quickly with this standard.

 

We would very much like to have as many liaisons as possible between the WCS 
and CF-netCDF working groups to ensure that they are kept in harmony.

 

-- Ben

 

-- 
Scanned by iCritical. 

 

 

-- 
Dr. Peter Baumann
 - Professor of Computer Science, Jacobs University Bremen
   www.faculty.jacobs-university.de/pbaumann
   mail: p.baumann@xxxxxxxxxxxxxxxxxxxx
   tel: +49-421-200-3178, fax: +49-421-200-493178
 - Executive Director, rasdaman GmbH Bremen (HRB 147737)
   www.rasdaman.com, mail: baumann@xxxxxxxxxxxx
   tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
"A brilliant idea is a job halfdone."
 

 

-- 
Scanned by iCritical. 

 

 

-- 
Scanned by iCritical. 

 


-- 
Scanned by iCritical.

  • 2009 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the galeon archives: