Hi Tom, Tom Scavo wrote:
Suppose, for example, UIUC and UIowa jointly offer a graduate-level geography course (GEOG 602) to advanced undergraduate and graduate students at both institutions. The first semester this joint course is offered, it is agreed that the GISolve gateway (VO name: http://gisolve.org) deployed at UIUC will support all students taking the course. Consequently, each student is obliged to obtain a GISolve gateway account at http://www.gisolve.org/.
Now it turns out that the GISolve gateway proxies grid requests to a resource provider (RP) on the back end. To distinguish grid requests originating from the two groups of users (uiuc.edu and uiowa.edu), the RP (hosted by NCSA at UIUC) requires isMemberOf attributes with one of the following values:
http://gisolve.org/uiuc.edu/geog602 http://gisolve.org/uiowa.edu/geog602
To further distinguish requests, the gateway and RP together define roles (faculty, student, admin, etc.) that are appended to the relevant isMemberOf attribute values using familiar URL notation. For example, to distinguish between students at each of the two institutions, the following attribute values are defined:
http://gisolve.org/uiuc.edu/geog602#student http://gisolve.org/uiowa.edu/geog602#student
Attributes values such as these have a number of desirable properties. First of all, the VO already owns the namespace, so globally unique attribute values are immediately available. Moreover, URLs are easily parsed by most languages, so processing is a snap.
Does anyone see a downside to such a naming scheme?
Well, I can't really see the reason for putting http:// there, and making it a URL. It'll confuse everybody, actually the above text confuses even my MUA - thuderbird - which allows me to click at those example attributes' values. My and I think general view on URL is that it identifies a resource via a representation of its access mechanism - and it is not true in this case. In another words, without very serious reason I wouldn't use http:// URLs for things that aren't by any mean resources accessible via HTTP protocol. Looking at the other end of your proposition - scoped attribute value encoded with '#': <whatever>/gisolve.org/uiuc.edu/geog602#student is nearly the same as my original proposition. My was: /gisolve.org/uiuc.edu/geog602:student Valerio convinced me that it will be better to use the same notation that MACE profile defines (with '@'). Parsing is trivial in any case. The only one tiny issue is to define which are reserved chars and how to escape them. Of course URI encoding rules with percent encoding of special characters is fine. Eventually one minor note: all those examples above should contain vo service id as the "host" component (see the rest of discussion - one service can manage many VOs). E.g.: http://voservice.uiuc.edu/gissolve/uiuc.edu/geog602#student To summarize: I don't think that a URL is a good choice, a URI is fine with me, however at least partial compatibility with MACE-dir is tempting too - that's why we proposed @ notation. Best regards, Krzysztof