Inconsistencies between SCOS Core RDF and SKOS API

As mentioned before, I found some inconsistencies between SCOS Core RDF ("CORE") 
http://www.w3.org/2001/sw/Europe/reports/thes/1.0/guide/
and SKOS Web Services API ("API")
http://www.w3.org/2001/sw/Europe/reports/thes/skosapi.html

Before that I thought about the use case I want to serve: 

(uc1) (Software-) Agent comes across the service-URL of an SKOS thesaurus interface. 
Could have found it in an UDDI, inspected the WSDL and detected "skos-core 1.0" as the schema.
Has there been discussion on SKOS in registries?

(uc2) Given that Agent "knows" how to handle SKOS: it requests a general thesaurus description from the interface. 
The description gives enough information (by well known URL-identifiers), so agent can decide whether to give it a closer look.
If this is not the case, Agent has to call his (human) master who must read all the stuff and decide "manually".

(uc3) Agent requests the kind of relations used in the thesaurus. 
Agent already "knows" some of them - some not. Can Agent "learn" on the fly? 


Then I revisited the SKOS-CORE 1.0 Guide and the SKOS API (no Guide so far, only a JavaDoc and a WSDL) to see how this little scenario is specified so far.

Found nothing about uc1.

-> affecting (uc2):
CORE knows  <skos:ConceptScheme> that describes the thesaurus using dublin core (DC) metadata. 
That looks fine, but the description of thesaurus might be a concept <skos:Concept> itself - I would like the idea.
I think that <skos:Concept rdf:about ="#self"> word be more powerful than <skos:ConceptScheme>.
Chapter 4 of the Guide suggests (if I understand it right) that also concepts can be annotated using DC, so we could describe it just as drafted for <skos:ConceptScheme>.   

API does not include a Service.GetConceptScheme() method ..., well I could use Service.GetConcept("#self"). 

The conceptScheme (or the concept of "#self") should use URI-references to well know external definitions describing its own scope. 

CORE only discusses "External (non-URI) identifiers for concepts" - external URI identifiers are only shown as interspersed DC or FOAF fragments  - this apears a little "weak" to me. 
Dan proposed <skos:conceptualizes> in http://lists.w3.org/Archives/Public/public-esw-thes/2004Apr/0021.html
Bernard prefers <skos:subjectIndicator> in http://lists.w3.org/Archives/Public/public-esw-thes/2004Apr/0024.html
Could also be <skos:externalIdentifier>, or use <skos:externalID> with a URL, as Bernard has proposed.

API is not consistent with CORE: API Concept has an attribut "uri" - the "Global URI of concept (optional)", which I understand to be an external identifier.


-> affecting (uc3):
API has a nice method: 
"public Relation[] getSupportedSemanticRelations()
Get a list of supported semantic relations. For example things such as broader, narrower, is-a each with a unique uri, a description of their meaning and human readable label." 

Fine - but CORE only contains a *fixed* set of relation types, that indeed are extensions of <skos:semanticRelation> . 

*** How to extend this set without extendig the interface definition? ***
*** Example: we use a "spatial intersection Relation".***

Maybe by inventing <skos:semanticRelation extension="#blahRelation"> or similar ? 
http://www.w3c.rl.ac.uk/SWAD/deliverables/8.2.html#2.3 talks about "Extensible and customisable relationship sets" but not about the service interface.

More exactly: if I extend <skos:semanticRelation> in <skos:spatialIntersection>,  Agent would have to be re-compiled to "understand" this in the Web Services/XML Schema world.
I am not really familiar with Web Services/RDF Schema . 
Any input from http://www.w3.org/2001/sw/Europe/plan/workpackages/live/esw-wp-4.html?

API has no fixed set of relations at all, that's why getSupportedSemanticRelations()could easily return my spatialIntersection relation.
 
"public class Relation: 
A class for semantic relations including the URI of the relation along with their description and human readable label. Intended to hold the URI of an rdf Property along with the rdfs:comment value as description and rdfs:label value as label. The SKOS-Mapping vocabulary draft is at http://www.w3c.rl.ac.uk/2003/11/21-skos-mapping and lists the mapping relation properties with their label and description."

I would like to see this also in a Guide. 
Can anyone provide a sample how to handle my "spatialIntersection Relation" in a way that Agent can learn to use it without having to be re-compiled?

I guess I prefer the model of API, but may be this is only because I am more familiar with Web Services and XML Schema than with RDF.
BTW, the XML Schema embedded in the WSDL of API has been generated by Axis ... hm ... it will work, as most of Axis does, but it should be edited before proposing it as the "normative" Schema ....

Thomas