A.02.06.federated.catalogues.advertisement

[jensscheerlinck]

This issue has been extracted from the issue list on:https://ies-svn.jrc.ec.europa.eu/issues/2685

Comment

Ambiguity:
Neither requirement 3 nor the test states unambiguously how the list of federated catalogues shall be advertised. Adding Xpath references may help, but the information should also be included in the TG.
Notes:
XPATH expression is missing

Under 'notes', hyperlink to section 4.3.4.3

[PeterParslow]

The detail of Requirement 3 is provided by Requirement 16, although that only applies to one of the options for implemeneting the Link Discovery service operation. On the other hand, it is the only option in which listing federated catalogues is required. So requirement 3 says the service shall do it, and requirement 16 says how.
Propose: delete this test case, leaving A.02.07 to test both requirements. See #40

[PeterParslow]

I was strictly speaking wrong yesterday, Requirement 3 talks about providing a "list" which seems to be the collection of metadata records returned by a Discover Metadata request with a filter on serviceType=Discovery. But it doesn't say that explicitly, and use of the word "advertised" led me to think of the GetCapabilities response..
Requirement 16 is specifically about the list of federated catalogues given in the service-under-test's GetCapabilities response.

[PeterParslow]

So to test Requirement 3, as A.02.06 sets out to do, suggested resolution: clarify the TG requirement: is it as described above? If so, then this is part of the search terms test, but might be useful to keep separate, as it relates also to other 'federated search' tests. It is more 'diagnostic' than a test, as it may be the best way to resolve whether a given service is 'federated'.

[aquaglia]

I would like to be sure that the determination of the Discovery Client scenario is carried out correctly as I really do not think it can be based on the capabilities information only.

[PeterParslow]

Perhaps it would be better to design the ATS around the "scenarios" discussed in the TG, rather than around the requirements per se. That would be greatly helped if the TG was entirely reorganised in terms of conformance classes, such as "Discovery client approach, with linked metadata" - I can see six such classes.
But working from where we are, the only requirement specific to the Discovery Client approach is Requirement 15, tested by test case A.4.2. To test the scenario correctly requires passing many (most?) of the other tests too.
Perhaps a short document listing the scenarios & which requirements / test cases need to be covered for each would be useful. I'll try to make time (tomorrow?) to draft such a thing.

[aquaglia]

We could even consider adding the Discovery Scenario to the INSPIRE Extended Capabilities.

[PeterParslow]

Here's my thinking on possible conformance classes, mainly around the Link Discovery Service choice made. It would be good to have someone verify the understanding, which I hope will be useful in understanding the requirements.
We may even want to propose that radical a change to the Technical Guidance!
INSPIRE TG Discovery Service proposed conformance classes.docx

[aquaglia]

Dear Peter, what is your point?

[PeterParslow]

I had thought that was clear in the discussion over the last few days, culminating with yesterday.
I have found that this GitHub approach tends to address each requirement is if it were entirely independent. We've included the possibility that some are pre-requisites, but there are also groups of requirements which relate to different scenarios - these would be better handled if the TG was divided into conformance classes, but even though it isn't, I think there are sets of requirements that are best handled together.
One concerns the metadata scenario: various tests have different results depending on which scenario has been adopted (and there is no official way of knowing that!)
Another concerns the approach to Link Discovery Service: each one has a different set of requirements that apply, including some that change from conditional to mandatory
The third concerns multi-lingual support.
It is quite likely that this is so familiar to you, that you don't see the issue, but I hope that people coming 'new' to it (perhaps to implement at test suite) may benefit from the insight. But only of course if it correct!

[aquaglia]

Yes, this GitHub approach makes it very hard to see the whole picture, I am sorry.
Many thanks for the recap.
I find a bit hard to follow the summary table because requirement numbers do not tell me much.

[cportele]

At least this discussion got my attention 😄. I have never really looked at the discovery service TG before, but I will be doing this now. If I understand the discussion correctly the requirements are not stated clearly. In particular, some requirements change depending on some options, but that is not obvious from the requirement. I will try to understand this a bit better until Friday.

A small note on the "six conformance classes": Every requirement belongs to exactly one conformance class, so the conformance class structure would need to be different. Likely with a core / base conformance class with all requirements that are shared between all options (and with the same interpretation) and then conformance classes that build on top of this core class. And requirements that change interpretation should be split into separate requirements for each option. But that is a discussion for the MIG in the future, if/once they revise the TG to introduce more than a single conformance class.

[cportele]

Going back to the specific issue, requirement 16 also does not specify the "how".

It says: "A federated Discovery Service shall be published in the Member State’s Discovery Service’s capabilities document as the URL of its HTTP/KVP/GET GetCapabilities request."

The requirement does not state how/where the federated service must be published, just that the GetCapabilities URL must be used.

The text above the requirement is probably meant to state this, but it is not part of the requirement and it is written as a permission statement ("may advertise") only.

In addition, the test method is also unclear how to "examine whether all federated catalogues have been advertised" in an automated test. Where can I get that list of "all federated catalogues" from the discovery service? Should the test be manual?

Going back to requirement 3, which may be related to getting that list. It is unclear what parameters that GetRecords ("Discover Metadata") request must have (is this where "serviceType=Discovery", see above, becomes relevant?) and how I find the federated catalogues in the response document. And how do I know that these are the federated catalogues? Probably this is a manual test, too. Or maybe this is a manual test, but I could use the mechanism in the test for requirement 16 to determine, if that is met. But the test for requirement 16 does not say this.

Another note (on the TG, not the ATS) is that I am also confused about the reference to a "Discover Metadata request". As this is a TG, shouldn't this use in the implementation requirements the language of the implementation option, ie CSW ISO AP? Anyway, based on section 4.3.2 this is GetRecords in CSW.

[PeterParslow]

Notes from telephone meeting 2016-04-28:
Change the TG to:
a) remove the 'federated' option, because performance is not good enough
b) include a way to explicitly indicate which scenario (of 'centrlised' and 'client') has been adopted.
In practice, it is the 'client' approach which needs to publish the list of 'other catalogues that the client should search' (which isn't necessarily all the Discovery services that have records in the main service). This is almost the opposite of OGC's FederatedCatalogues element; it is a bit like coupling - but that is explicitly between service & dataset, not service & service. Most likely, we'll need an additional element.
Meanwhile, can't test this.