[appendix] = Review comments from TB12 participants * *Review comment 1 (C. Heazel)* On the GetCapabilities() operation – I don’t think it is necessary to modify this operation. It is sufficient to have a standard service metadata document with two defined operations; getRespourceById() and getAssociations(). GetResourceById() is required by OWS Common. GetAssociations() can do everything you are trying to do in the service metadata. Furthermore, it will avoid further balkanization of the service metadata. * *Response to comment 1* The WIS does not modify the GetCapabilites() operation in any way. It is the standard GetCapabilities operation that every other OGC web service uses. The issues is with the response. Currently, OWS common requires that 2 operations be defined in the operations metadata section of a capabilities documents. A change request was posted a couple of years ago (OGC 14-026) to remove this restriction. This is a backward compatible change would allow a WIS to be implemented without having to implement any other operation (i.e. simple implementation) and still let existing OGC services operate as they always have. The GetResourceById operation, as far as I know, is not mandatory for all services. Rather OWS common says: "This typical operation is specified as a base for profiling by specific OWS specifications.". So I believe that OWS common says that if your service includes a GetResourceById operation then it should be derived from the base defined therein. The WIS handles the 2-operation minimum requirement by defining a dummy no-op. However, the idea of implementing one or both of GetResourceById and/or GetAssociations() is not a bad one. It would impose an additional burden on the implementation of a WIS, since the WIS would need to cascade those requests down to the services that it is aggregating but that extra complexity could be handled by adding an additional, optional, conformance class to the WIS. I have added this to the future work section. * *Review comment 2 (C. Heazel)* Consider the value of making a mandatory getResourceById() operation which is defined the same for all OGC services. Since all of the OGC resources are defined by a URL and resource identifier, then the getResourceById URL and the identifier are all we need to retrieve that resource. We can consider this in a CR to OWS Common. * *Response to comment 2* Agreed (see: http://ogc.standardstracker.org/show_request.cgi?id=412) * *Review comment 3 (C. Heazel)* On identifiers – I suggest using URNs rather than URLs. The URLs imply that the services are only accessible through HTTP and that the identifiers resolve to the identified resource. This will usually not be the case. Using a URN for the identifier makes a clear distinction between the resource identifier and the URL for accessing that resource. * *Response to comment 3* I am not opposed to this but it was my understanding the the OGC directives recommend HTTP-URI identifiers rather than URN identifiers. According to Carl Reid: "Proposed initially by Simon Cox and presented in early 2010 (https://portal.opengeospatial.org/files/?artifact_id=39331&version=1). The policy was discussed in the OAB and then the broader OGC TC and approved at the June 2010 meetings. The decision is documented in the OGC Policy Directives (06-135r11). The specific wording is: At the June 2010 meetings, the OGC Members approved a change related to the use of URIs in OGC standards documents. There were two parts to the motion: 1. OGC Technical and Planning Committees directs the OGC-Naming Authority that all new OGC identifiers issued for persistent public OGC resources shall be http URIs, instead of URNs; 2. New standards and new major versions of existing standards shall use http URIs for persistent public OGC resources to replace OGC URN identifiers defined in previous standards and versions, unless the OGC-NA approves an exception. At the time, the use of http URIs was (a) seen as a way to resolve deployment challenges and (b) provides an opportunity for easier engagement with broader communities. So OGC was asked to consider taking the next step, and mandate the use of http URIs for persistent identifiers in OGC standards. However, that has not entirely happened. There are still OGC http uri deployment challenges. Further, URNs are still very much in use. The IESG processes a number of new URN proposals each year. Many (most) internet standards use urn's and any number of new revisions or RFC still use urn's. Other standards organizations are also still using urn's. And of course there was the backwards compatibility issue." In any case, for all non-CSW ebRIM-specific identifiers in this ER, I have defined both a URN form and an HTTP-URI form -- just to cover all the bases! * *Review comment 4 (C. Heazel)* Nice – this goal is more likely to be achieved if the getAssociations() operation can be implemented without any changes (outside of the additional operation metadata) to the existing service. Consider a use case from the tactical sensor world. These sensors are not connected to the Internet. Rather they form and re-form mesh networks based on who is currently in range (the sensor can move). Usually one of the participants in the mesh also has up-link capability. GetAssociations() can tell me which sensors are currently accessible through the up-link. It could also support a temporal filter so I can discover which sensors have been associated over a period of time. This is useful if I am looking for archived sensor readings. This really calls for a JSON-LD output format. * *Response to comment 4* I am not exactly sure how you could implement a GetAssociations() operation without modifying the service. The primary reason for the existence of the operation is to allow services to advertise the associations they are usually aware of internally. In static, or pseudo-static case, I suppose you could implement the operation on top of a static Associations document without necessarily modifying the service to which the associations pertain. But I don't think that is the general case. Just like the use case you describe, participants in the mesh network know who they have been and are associated with. The idea is to make this internal or private information available through a public API. In the current testbed a primary use case was to have a catalogue harvest this association information to support rich discovery. However, once exposed through a public API the universe of possibilities for this kind of knowledge is quite large as illustrated by your use case. I quite like the use case you describe and I am pleased to say that it could be accommodated with the current proposal since associations can have properties and one of those properties could be a time stamp. I agree that JSON-LD would be useful output format and have added this to the future work section.