Ah - if only we lived in an ideal world and everyone filled out
metadata like we wished.
As much as a long string of hierarchies in the location field would
be ideal for searching - I don't see it happening. We, for example,
are dealing only with Australian information - I don't see us getting
our staff adding "Australia, Victoria, Dandenong, .... etc.). It just
wouldn't be done.
Re Jordan's comment that very few people will search on lat/long - well,
if the search protocol is set up to allow people to search in that way
(i.e. by drawing a rectangle on a map), they will. It is not Dublin
Core, but see
http://www.environment.gov.au/net/edd.html
The Basic search uses several clicks to do the search - the Advanced uses
Java. You'll note that the advanced also does a temporal search.
The DTSC are developing a similar search technique for Dublin Core.
I know of a number of large resource recovery programs using similar searches.
We are adding it to our Dublin Core shortly.
regards
arthur
________________________________________________________________________________
Arthur D. Chapman [Scientific Coordinator, Biodiversity & Vegetationn, ERIN]
Environmental Resources Information Network internet: [log in to unmask]
GPO Box 787, Canberra, voice: +61-2-6274 1066
ACT 2601, AUSTRALIA fax: +61-2-6274 1333
>
>Weibel,Stu felt an urge to reveal at 3:24 AM -0500 on 1997-09-30:
>
>> Mary's Coverage workgroup paper adopts a strongly cartesian or
>> foot-print view of coverage.
>>
>> I can also imagine it being used in an unqualified free-text mode...
>> coverage = Columbus, Ohio
>>
>> very loose semantics, indeed. Useful? Probably less so than a more
>> strongly-typed version. Eric mentioned to me that some substantial
>> percentage (40%?) of all web searches are for local resources.
>> <red-neck-accent>Don't need no bounding box to find a list of all the
>> Holiday Inns in Columbus.</red-neck-accent>
>
>I'm not sure what you mean by "strongly-typed" version, but I think *very*
>few people doing any kind of search will type in the exact geographic
>location (longitude, latitude, and minutes) of that place--just the name.
>I think it would be better to set up a clear syntax of location based on
>geographic names. I swear we had this thread earlier, and I said something
>along the lines of "We should have a sort of hierarchal system"--preferably
>top-down.
>
>For example, you might put "US-VA-Charlottesville-Downtown Mall". This
>would indicate that the general coverage is the US, then more specifically
>the state of Virginia, then the city of Charlottesville, then the area
>known as the Downtown Mall. This would be perfect for a page describing
>attractions/shops on the Downtown Mall in Charlottesville, VA US. I think
>that using standardized postal abbreviations for upper-hierarchal locations
>makes the most sense--in my example, Virginia should only be indicated by
>VA, not Va or other variants.
>
>However, the last item *shouldn't* be abbreviated. For example, if I
>specified simply a document covering Virginia, then it should be
>"US-Virginia". Why the change? Think of how the usual search terms would
>be used. If you're looking for something in a town, you might type the
>name of the town and the abbreviation of the state, ie: "Richmond VA". But
>if you're doing a search for something in the state of Virignia, you'd
>probably type "Virginia" in full. The same applies if the coverage is for
>the entire US--people might type in US, but they're much more likely to
>type in "United States".
>
>The geographic coverage could then have many levels of granularity, similar
>to the ISO DATE's granularity. While writing out records as "Town, Region,
>Country" may be more familliar, since metadata is not specifically for
>humans to look at but instead for record keeping, it doesn't really matter.
>
>Some other options: Use a zip-code schema (this would work for US--I don't
>know how many countries use zip codes though, or similar things). Also,
>apparently there's this global positioning systems standard, although that
>seems a little to specific.
>
>The name of countries and cities should correspond to the language of the
>document. For example, a document in Italian should use "Roma", while a
>document in English should use "Rome". This way, the documents found will
>most likely correspond to the user's language preferences as well.
>
>--------------------------------------------------------
>[ Jordan Reiter ]
>[ mailto:[log in to unmask] ]
>[ "Don't you realize that intellectual people ]
>[ are all ignorant because they can't spray ]
>[ paint that small?" ]
>--------------------------------------------------------
>
>
>
|