I popped into this issue a while ago and wanted to share as I spend.... SOME time figuring out what was going on:
When I started out on the REST API i downloaded the BESAPI.CS using that in my setup.
At some point I discovered that the tuples were not a part of the pre-generated BESAPI.CS.
The queries made would just be some simple ones like: /api/query?relevance=(name of it, id of it) of bes computers
So to use the BESAPI.CS with tuples I had to get a hold on the BESAPI.XSD (think I just downloaded it from here at that time: https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/90553c0b-42eb-4df0-9556-d3c2e0ac4c52/page/79fc6abc-a920-49fa-accd-ab4c50eab283), and had to regenerate the BESAPI.CS using xsd.exe from the MS toolsets. Anyway, it would fail as the tuples in the xsd cause a cyclic reference. A cyclic reference is perfectly allowed (supporting unlimited nesting like a tuple within a tuple within a tuple...), but the xsd.exe does not support cyclic references. As a workaround to get the tuples in game I had to do the following.
- change the Tuples-part of the BESAPI.xsd from <code>Type="RelevanceResult"</code> to another type (like <code>Type="ObjectName"</code>)
- create a dummyobject somewhere in BESAPI.xsd (<code><xs:element name="dummy" type="RelevanceResult" /></code>) forcing the RelevanceResult-Type to be created in the .cs file
- run the xsd.exe (<code>xsd BESAPI.xsd /classes /namespace:MYNAMESPACE.BESAPI_Namespace</code>) to generate BESAPI.cs
- edit BESAPI.cs to get rid of the dummy-field, and make the Tuple-Type (2 places) into RelevanceResult instead of string.
This way the tuples was accessible directly through the 'generated but manually modified' C# BESAPI.CS file.