[gin-info] Site UniqueID

[Laurence Field]

Hi Oxana,

I am really pleased that you brought this up.

I agree that this use case does really practicle when it comes to grid 
middleware. Any middleware decisions based on the site will only be 
assumptions. However, as you pointed out, putting a site on a map is 
import for people. It is also a very easy thing to understand and a good 
place to start. We can focus on the problem on making the information 
systems interoperate rather than getting side tracked into discussions 
about how a CE should be represented. By focusing on this simple use 
case we have very quickly brought together many information systems and 
can demonstrate this in a simple yet stunning way that can easily be 
understood, ideal for the groups first goal which was to demonstrate 
something at Super Computing 2006.

This simple use case has also shown us a number of fundamental issues. 
The first is that the information required is defined by the use case.  
In this instance we need the location. There are many different ways to 
represent a location and different precisions.  What works best for this 
use case is a close approximation in text for people and an accurate 
number for the display.  The other important issue, which you pointed 
out,  is the the information system is only as good as the quality of 
the information inside of it.  How do we ensure that the information is 
published correctly and how can we verify that it is accurate?

These are both implementation and operational aspects of the problem. 
What we have seen in production is that values which are generated, tend 
to be more accurate than values which are entered by hand. A system 
administrator may enter some random value because they don't think that 
it is important. There are no sites at 0,0 so there is some hope :).  
Without any well defined instructions, they my look a the coordinates of 
the local city, however, with the accuracy of Google Earth, this might 
not be good enough.  It is very easy to automatically check that the 
number is in the correct format and range but more difficult to verify 
that it is in the correct for that site. It is very easy to look a the 
points and spot the ones that  are not in the right  place but difficult 
to automate this.

As you pointed out, trying to automatically generate these from the 
IP-to-geolocation databases might be a better idea. It would be 
interesting to see how this works and how accurate it is.  If we loose a 
little accuracy for improved quality, it might be worth to use this 
method. If so we implement this in the provider or in the application 
creating the kml file?  It is not published from the site, then we don't 
need have it in a common schema :)

Even though the site entry might not be so usefully for doing practical 
things like submitting jobs and moving files, I think that this use case 
has show us a few things about these kind of problems.

Laurence



Oxana Smirnova wrote:
> Hi Laurence,
>
> I am personally very sceptical of lattitude and longitude usefullness 
> and especially the "Location" thingy - there is practically no way to 
> validate it or fill automatically, so it carries no *reliable* 
> information. That is, I can set up a site in Berlin and give the 
> coordinates of Rome, for some practical funding reasons - would anybody 
> be happy? It can not be used even for network proximity estimate: e.g. 
> Lund and Copenhagen have few seconds of coordinate difference, and yet 
> they are separated by 1500 kilometers (yes, fifteen hundred) of cable.
>
> However, if the unique ID will contain an IP address of something that 
> can be resolved by DNS, one could use one of the IP-to-geolocation 
> databases, either free or commercial one, and make at least an impartial 
> estimate for site location. Also, sites in the same domain tend to have 
> better connectivity :-)
>
> Cheers,
> Oxana
>
> L