[tdwg-content] [tdwg-tag] DwC change review: geo terms

Matt Jones jones at nceas.ucsb.edu
Sat Sep 10 01:27:39 CEST 2011 

Thanks, that helps.  I looked at it very quickly so far, and so I could very
easily have missed key information -- so be sure to let me know what I
misinterpreted. Nevertheless, if I'm reading this correctly, they are
proposing that instance data be represented as WKT (section 8.5) or GML
(section 8.6) literal values. The example they give for encoding a Point is:

<sfg:Point rdf:about="http://somewhere/ApplicationSchema#APointGeom">
   <geo:asWKT rdf:datatype=
     "http://www.opengis.net/def/dataType/OGC-SF/1.0/WKTLiteral">
      <![CDATA[
        <http://www.opengis.net/def/crs/OGC/1.3/CRS84>
        Point(-83.4 34.3)
      ]]>
   </geo:asWKT>
</sfg:Point>

Instead of get:asWKT they also allow the geo:asGML property to encode as a
GML literal as well.  But in either case, there is no direct RDF class that
exposes the spatial concepts -- they are buried in a liter syntactic
encoding from other languages.

I'm not seeing in there anything corresponding to the W3C lat and lng
concepts.  Did I miss it?

Matt

On Fri, Sep 9, 2011 at 2:36 PM, Phillip C. Dibner <pcd at ecosystem.com> wrote:

> Hm, it appears that it has already been submitted for public review, and is
> being edited for final release by the working group.  There may be some
> further activity at the upcoming OGC Technical Committee meeting in Boulder,
> Sep 19 - 22.  Here is a better page:
> http://www.opengeospatial.org/standards/requests/80 .   The notice says
> there's a more current copy on the Standards page, but it doesn't appear to
> be there yet.  So the download on the above URL is probably the most current
> available.
>
> Flip
>
>
>
> On Sep 9, 2011, at 3:18 PM, Matt Jones wrote:
>
> Thanks, Flip, for the update.  That page didn't have any links to candidate
> standards, working drafts, RDFS/OWL schemas, or other documents that would
> explain the current approach.  Is the development of these proposals open to
> the public?  I'd love to take a look at it.
>
> Thanks,
> Matt
>
> On Fri, Sep 9, 2011 at 2:01 PM, Phillip C. Dibner <pcd at ecosystem.com>wrote:
>
>> Yes, there are semantic efforts underway at OGC.  Some of them are
>> reaching a degree of maturity, e.g. GeoSPARQ, an extension of the SPARQL
>> query language (
>> http://www.opengeospatial.org/projects/groups/geosparqlswg ).  Other,
>> more recent efforts are building upon the base classes defined by GeoSPARQL.
>>
>> Flip
>>
>> On Sep 9, 2011, at 2:17 PM, Hilmar Lapp wrote:
>>
>> > (Sorry if you receive this twice - John asked to repost here.)
>> >
>> > Where is adopting these terms now going to put us with respect to OGC
>> standards, which, I think, will ultimately be more authoritative than an
>> informal W3C vocabulary.
>> >
>> > I don't have enough insight into OGC standards for vocabularies for
>> describing geolocations, but I have also learned earlier this year from Flip
>> Dibner (copied here) that there are efforts underway within OGC to create
>> RDF vocabularies (presumably corresponding to OGC's XML standards?).
>> >
>> >       -hilmar
>> >
>> > On Sep 6, 2011, at 6:33 PM, Javier de la Torre wrote:
>> >
>> >> Hi John,
>> >>
>> >> As you mention from previous discussion I would still adopt option
>> number 1 as I believe there is enough tools out there to handle
>> transformations. The current situation I think is much worst on the consumer
>> part and I think is time to think more on data use than on data
>> mobilization.
>> >>
>> >> Best,
>> >>
>> >> Javier.
>> >>
>> >> On 07/09/2011, at 00:00, John Wieczorek <tuco at berkeley.edu> wrote:
>> >>
>> >>> Perhaps my message was too long for easy digestion and action, as I've
>> >>> received no responses. I will take the initiative to initiate option
>> >>> 3. No further action from the TAG on this at this point. Be prepared
>> >>> though, VOTES by the TAG on publicly resolved issues are forthcoming
>> >>> very soon.
>> >>>
>> >>> On Sat, Sep 3, 2011 at 9:34 AM, John Wieczorek <tuco at berkeley.edu>
>> wrote:
>> >>>> Hi TAGers,
>> >>>>
>> >>>> I am deep in the review process for the proposed changes to Darwin
>> >>>> Core, trying to do due diligence. Some of the change requests are
>> >>>> challenging to summarize to determine if there is consensus, in spite
>> >>>> of, or because of the discussions. One of the requests on which I’d
>> >>>> like some TAG help before proposing a solution is the request for the
>> >>>> inclusion of the terms from the geo: namespace
>> >>>> (xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#").
>> >>>>
>> >>>> Support in tdwg-content for this request comes from multiple
>> >>>> independent sources. There has been a long history of discussion
>> >>>> (http://lists.tdwg.org/pipermail/tdwg-tag/2010-August/000050.html),
>> >>>> beginning in anticipation of the 2010 TDWG BioBlitz. The proposal has
>> >>>> gone through the minimum 30-day public review and discussion on the
>> >>>> forum tdwg-content at lists.tdwg.org:
>> >>>>
>> >>>> http://lists.tdwg.org/pipermail/tdwg-content/2011-July/002581.html
>> >>>>
>> >>>> There seems to be general support for the additions, however, after
>> >>>> reviewing the discussions and the references. I have the following
>> >>>> observations/concerns:
>> >>>>
>> >>>> 1) The discussions presented geo:lat and geo:lng as W3C standards.
>> >>>> This is not actually the case. These terms were created by the W3C
>> >>>> Semantic Web Interest Group in 2003. The documentation for these
>> terms
>> >>>> (http://www.w3.org/2003/01/geo/) states:
>> >>>>
>> >>>> "This document was created as an informal collaboration within W3C's
>> >>>> Semantic Web Interest Group. This work is not currently on the W3C
>> >>>> recommendation track for standardization, and has not been subject to
>> >>>> the associated review process, quality assurance, etc. If there is
>> >>>> interest amongst the W3C membership in standards work on a
>> >>>> location/mapping RDF vocabulary, this current work may inform any
>> more
>> >>>> formal efforts to follow."
>> >>>>
>> >>>> These terms do seem to have widespread usage in the semantic web.
>> >>>> Should we be concerned that they are not part of a standard?
>> >>>>
>> >>>> 2) geo:lat and geo:lng are not semantically equivalent to the
>> existing
>> >>>> Darwin Core terms decimalLatitude and decimalLongitude, which have
>> >>>> been a part of the Darwin Core since it 2003 (or before, if we ignore
>> >>>> the missing Datum term in earlier versions). The addition of the geo:
>> >>>> terms as a third set of geolocation terms for Darwin Core raised
>> >>>> concerns about confusion. I share this concern. An option would be to
>> >>>> adopt these terms and deprecate dwc:decimalLatitude, dwc:Longitude,
>> >>>> and dwc:geodeticDatum. Data that would have occupied these terms
>> would
>> >>>> go instead to dwc:verbatimLatitude dwc:verbatimLongitude, and
>> >>>> dwc:verbatimSRS. I see a couple of problems with this. First, most of
>> >>>> the time the data in the decimal coordinate fields are not the
>> >>>> verbatim originals, so this would be a misuse of the Darwin Core
>> >>>> terms. Second, this change would make it more difficult for data
>> >>>> consumer’s to use existing georeferences. Here’s how. Right now the
>> >>>> verbatim fields are meant to hold the original coordinate
>> information,
>> >>>> which means they have a wide variety of content - everything from
>> UTMs
>> >>>> to custom-encoded coordinates, in any conceivable format. Meanwhile,
>> >>>> the data in the decimal coordinates fields can be much more readily
>> >>>> transformed into the desired standardized spatial reference system
>> >>>> afforded by the geo: terms, because the values are at least
>> >>>> standardized on decimal degrees and only a datum transformation has
>> to
>> >>>> be done on them.
>> >>>>
>> >>>> Do we abandon the dwc: terms decimalLatitude, decimalLongitude, and
>> >>>> geodeticDatum? Do we abandon them now? Do we build the simplest
>> >>>> possible tools necessary for anyone to do the transformations so that
>> >>>> these terms are no longer needed? If so, do we wait until those tools
>> >>>> exist?
>> >>>>
>> >>>> 3) Additional concern was expressed that the term geo:alt should also
>> >>>> be added. No one has made a formal request for this. However, if the
>> >>>> other geo: terms were adopted, it might be silly not to adopt this
>> one
>> >>>> as well. Doing so would raise a host of issues similar to those
>> raised
>> >>>> for lat and lng.
>> >>>>
>> >>>> I don’t have a good solution. The best short-term one, in my opinion,
>> >>>> is to leave Darwin Core as it is, and to recommend that if
>> >>>> applications (or aggregators) want to share “cleansed” point-based
>> >>>> georeferences, that they do so with the geo: tags, the values for
>> >>>> which they derive through transformations to WGS84 of the DwC decimal
>> >>>> coordinates and geodeticDatum.
>> >>>>
>> >>>> Options:
>> >>>>
>> >>>> 1) Accept the proposal, adding geo:lat, geo:lng, and geo:alt to the
>> >>>> list of recommended terms for DwC.
>> >>>>
>> >>>> 2) Reject the proposal pending further directed research into a
>> >>>> comprehensive solution that considers all geospatial terms in Darwin
>> >>>> Core (including footprintWKT, for example).
>> >>>>
>> >>>> 3) Reject the proposal for now, reopening the public discussion with
>> >>>> these concerns.
>> >>>>
>> >>>> Others?
>> >>>>
>> >>> _______________________________________________
>> >>> tdwg-tag mailing list
>> >>> tdwg-tag at lists.tdwg.org
>> >>> http://lists.tdwg.org/mailman/listinfo/tdwg-tag
>> >> _______________________________________________
>> >> tdwg-tag mailing list
>> >> tdwg-tag at lists.tdwg.org
>> >> http://lists.tdwg.org/mailman/listinfo/tdwg-tag
>> >
>> > --
>> > ===========================================================
>> > : Hilmar Lapp  -:- Durham, NC -:- informatics.nescent.org :
>> > ===========================================================
>> >
>> >
>> >
>>
>> _______________________________________________
>> tdwg-content mailing list
>> tdwg-content at lists.tdwg.org
>> http://lists.tdwg.org/mailman/listinfo/tdwg-content
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.tdwg.org/pipermail/tdwg-content/attachments/20110909/9886e326/attachment.html

More information about the tdwg-content mailing list