Re: [Spatialml-discussion] some comments

[Justin R. <jr...@mi...>]

A few comments and clarifications that I wanted to make here as well.

> 1. A gazetteer reference is made using the gazref attribute, which  
> takes the form prefix:identifier.  Have you considered making such  
> references href-style URLs?  For then a client could automatically  
> follow a gazref link and retrieve the associated place information.   
> I realize that gazetteer record formats are not yet standardized, nor  
> is the identification of places by URIs, but this is a use case that  
> could help drive such standardization.  As SpatialML stands now, a  
> client needs three document-external pieces of information to follow  
> a gazref: the location of the gazetteer being referred to; the  
> protocol for accessing that gazetteer; and the format of that  
> gazetteer's records.  (Also, see comment #6 below).
> 
> **This is an excellent point. XML Schemas should be made use of in the
> guidelines, to facilitate such an
> integration. 

We basically are using URNs here, noting both where to get the info and
what to ask for, though it makes no mention of how to get there, how to
ask, or what the answer will look like. Maybe we could allow for full
URLs by further specifying some type of URI scheme, such as
"gaz:igdb:12345" in addition to allowing
"http://igdb.foo/getrecord?r=12345" types. 

I'm of the opinion that requiring a URL fronted interface shouldn't
exactly be a requirement. Using a URN allows for more flexibility in
defining the accessor methods of a particular gazetteer. I do agree that
it's something to be aspired to, but I don't think it should be a
requirement. But even if we were to require a URL accessor in front of
each gazetteer, doing so would still say nothing about the format of the
returned result. It does cut down on the requirement of external
information to make full use of gazRefs, but it doesn't cut it out
entirely.

> 3. Seems like the document should at least suggest a format for  
> latitude/longitude coordinates.
> 
> **Yes, certainly, and it's in the works, as Section 24 suggests. 

Most definitely. The syntax of what are currently plain-text fields
(such as latLong and gazRef) is something that we're working out at the
moment. We are also considering moving it to a more general "location"
field and allowing specification in other coordinate systems (such as
UTM). Comments and suggestions are welcome!

> 4. Why is PLACE's id attribute required when no other attribute is?
> 
> **That's because the annotation editing/authoring tool being used here
> to annotate SpatialML (Callisto) requires that. 

Actually, that's not quite true. Callisto doesn't require id attributes
to be set, but they're still a really good idea anyway. The id attribute
is required here because that's the only way that a PLACE can be
referenced by a PATH or LINK. Since SpatialML is a language with a
fairly flat syntactic structure, we need document-global-unique
referents such as this in order to tie anything in together. Further,
it's our position that every element SHOULD have an id, since an
external language might, say, string multiple PATHs and LINKs together.
(You'll note that it's a #REQUIRED attribute on PATH, LINK, and SIGNAL
as well as PLACE). Maybe we need to say this a bit stronger in the
guideline documents? Regardless, the other attributes are optional
because sometimes the only thing that you can say is "This is a place"
with no further details. 

> 6. If gazetteers are identified by prefixes, consider using the XML  
> namespace mechanism to correlate prefixes with gazetteer URLs.  This  
> technique is used in XML Schema, for example.

See note above about URN vs. URL, but I do think that moving to a full
an WC3 XML Schema will give us more expressive control than our current
DTD allows.

> 7. Consider rephrasing sentences having "we" in them (e.g., "we try  
> to keep the extents as small as possible...") to passive requirements  
> ("guideline: extents should be kept as small as possible..."). 
> 
> **Thanks -- will certainly do that. The first-person plural doesn't
> sound very professional.

But on the same token, excessive use of the passive voice is tiresome.
I'm not sure what the general rule of thumb here is, but I do recall
most standard description documents sounding dry and stuffy. :)

> 8. I don't understand the distinction between cities, towns, and  
> villages in CTV.  Should I?
> 
> ***CTV is rather like a constrained version of the description
> attribute on a PLACE tag. If the text characterizes a place as being
> one of these, e.g., "village of Upper Slaughter" or "town of Chipping
> Camden" then the guidelines say it should be marked as such (i.e.,
> CTV="VILLAGE", and CTV="TOWN"). Rather than attempt to further
> decompose these fuzzy concepts further in terms of gazetteer features,
> instead it may be desirable to record these characterizations 'at face
> value' in case the information is useful downstream. But it does seem
> somewhat awkward, not sure exactly why.

Further, it's kind of a first attempt at a notation of *scale* within
gazetteer feature types. Maybe we should move on to a more general
"scale" attribute, with defined ranges for each allowable PLACE type?

> Minor points:
> 
> 9. Some codes are abbreviated (RGN), some are spelled out  
> (BODYOFWATER).  I take it some were copied, but I guess I would  
> strive for consistency here.
> 
> **OK.
>
> 10. More generally, the use of abbreviations counters XML's goal and  
> virtue of self-documentation.  Coded abbreviations like mod="BR" are  
> already inscrutable to me, and I read the spec all of 5 minutes ago.   
> Why not spell it out, i.e., modifier="BORDER"?
> 
> **OK.

I agree, though I think that the country codes should remain a copy of
the ISO 3166 standard. I would also say that the sixteen compass points
allowable for different attributes (N, NNE, NE, ENE, etc.) could
reasonably stay abbreviated without causing overmuch confusion. Apart
from this small subset, I think things should be spelled out.

Thank you for your great feedback.

 -- Justin