[georss] Why this syntax?

[Josh@oklieb]

Danny,

At one level, the syntaxes look similar. However, their  
expressiveness is quite different. gml:Point (and georss:point which  
maps to it) encode a rigorous and extensible model for representing  
physical entities with geometries in well-defined coordinate  
reference systems. Even though geo:Point is defined nominally in RDF  
as a class with two mandatory properties, most implementers tend to  
remove the geo:Point and use the geo:lat and geo:long properties with  
other objects whose geographic representation is undefined. This is  
not only impractical to extend to any other geometry, but ends up  
handicapping applications because the intent of the "tagger" can be  
difficult to interpret.

The apparent utility of parsing the individual coordinates also  
creates the impression that there is a significance to them  
individually. In some conceptual models, latitude and longitude may  
be considered separate concepts, but as a practical and mathematical  
matter of representing the location of a physical entity, they  
constitute a vector.  The SPARQL example could illustrate (although  
not as shown) the classic example of tricking a scalar query  
processor into performing a bounding box search, but in general it is  
misleading and invalid to query the coordinates separately. Since the  
values really need to be processed together, a whitespace-separated  
or path is the most common representation (e.g. in SVG as well as GML).

--Josh

Now this begs the question of

On May 8, 2006, at 6:49 PM, Danny Ayers wrote:

> Sorry if I'm missing something in the docs, but I can't really see any
> reason for opting for:
>
>  <gml:Point>
>      <gml:pos>45.256 -71.92</gml:pos>
>   </gml:Point>
>
> ...syntax, when the
>
>  <geo:Point>
>    <geo:lat>45.256</geo:lat>
>    <geo:long>-71.92</geo:long>
>  </geo:Point>
>
> ...syntax is not only already "out there", but easier to parse using
> XML tools (and no harder to create). With "valueA valueB valueC..."
> it's necessary to micro-parse and determine what parameter each value
> corresponds to, an unnecessary processing step.
>
> Ok, I believe the space separated approach is that taken by GML, but
> as you are talking about this vocabulary being deployed in RSS and
> Atom, new ground, surely the options are still open.
>
> To put it another way, why not:
>
> <georss:geo>point 45.256 -71.92</georss:geo>
>
> which also happens to be entirely extensible, e.g.:
>
> <georss:geo>polygon 45.256 -110.45 46.46 -109.48 43.84 -109.86 45.8
> -109.2</georss:geo>
>
> One immediate reason for using XML at a more granular level is for
> ease of use with RDF vocabularies (e.g. RSS 1.0). If the components
> are separated, it would be possible to apply a SPARQL query to an RDF
> model directly like this:
>
> SELECT  ?blog ?latitude
> WHERE   {
>    ?blog geo:lat ?latitude .
>    ?blog geo:lat ?longitude .
>    FILTER (?latitude > 50 && ?longitude < -60) .
> }
>
> With the space-separated data, in the RSS 1.0 case you have the
> slightly  bizarre situation where an otherwise directly
> interpretable/queryable document would have to be transformed or have
> some other kind of custom processing before anything useful can be
> done with it.
>
> Cheers,
> Danny.
>
>
> --
>
> http://dannyayers.com
> _______________________________________________
> georss mailing list
> georss at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/georss