Changes between Version 6 and Version 7 of ServiceBinding

08/02/07 08:41:40 (12 years ago)

expanding discussion of ISO consequences


  • ServiceBinding

    v6 v7  
    228228     * Which has 0 to many CI_OnlineResources 
    229229       * Which consists of a compulsory linkage and optional protocol, applicationProfile,name,description,function 
    230          * of the latter could be download, information,offlineAccess 
    231            * defined as "instructions for transferring data", "information about " 
     230         * of the latter using the CI_OnlineFunctionCode default could be download, information,offlineAccess 
     231           * defined as "instructions for transferring data", "information about " (but note that ISO19139 allows one to use your own controlled vocab here). 
    232232   * We may want to make use of the MD_Format 
    233233     * Which has compulsory name and version characterstrings plus an optional specification 
    234  * Further, all metadata records have MD_Identification elements, and these include 
    235    * Aggregations of MD_ServiceIdentification records (which takes us to ISO19119, and the OGC 
    236 profile of ISO19115+ISO19119 for CSW2.0). 
     234 * We could try and use the MD_PortrayalCatalogueReference which points to a CI_Citation, and thus could point to an CI_OnlineResource which we could bind appropriately for visualisation. 
     235 * Further, all metadata records have MD_Identification elements, and these can include 
     236   * Aggregations of MD_ServiceIdentification records (which takes us to ISO19119, and the OGC profile of ISO19115+ISO19119 for CSW2.0). However, it appears that the intention of using these is when the metadata 
     237record actually describes a service, not for providing a related URL which describes a service pointing 
     238at the particular metadata item of interest. (As an aside, I don't think MD_ServiceIdentification actually exists, it's replaced by SV_ServiceIdentification in practice). 
     240The ISO/OGC way of doing the service binding is to have a registry where one polls the registry for datasets of interest, then uses *registry* associations to find the services which act upon the data, rather than rely on entries within the records. We're clearly not doing this in advance of satisfactory registry implementations. We could implement similar functionality within the discovery client (my code) by implementing service metadata, and exploiting what we know about the underlying features, but I don't think this is tenable for NDG2. 
     242This does present us with a bit of a problem in terms of interoperability between incoming DIF records and outgoing ISO19139 versions of them. I think we should define this as NOT ALLOWED (I can implement this within the discovery code). On the other hand incoming ISO19139 records ought to be renderable as DIF (albeit in  a lossy manner), and so we will try and support that). 
     244Finally, in terms of export from MOLES proper, we should not attempt to export related URLs in general, but we ought to be able to support the three cases above:  
     245 * NDGA via the MD_DigitalTransferOptions, and 
     246 * NDGB via the MD_DigitalTransferOptions with   
     247 * CSML via the MD_PortrayalCatalogueReference. 
     248In all three cases we need to exploit CI_OnlineResource, and we could probably live with the vanilla CI_OnlineFunctionCodes (download,information,download) respectively ... but if we do that, we've somewhat 
     249obscured the semantics. I'd rather take advantage of the ability to have our own controlled vocab in CI_OnlineFunctionCode, and have the dif keyword vocab in there.