﻿[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.
