Changes between Version 65 and Version 66 of FCS-Specification-ScrapBook


Ignore:
Timestamp:
02/18/14 15:18:46 (10 years ago)
Author:
teckart
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • FCS-Specification-ScrapBook

    v65 v66  
    769769    * [[teckart|Thomas (ASV)]]: I am not sure if this is a problem, but we could interpret "Capabilities" just as a verbose listing of all capabilities of the endpoint. The <ed:Profile> is just the shorter version regarding our definition of what is "basic" and what is "extended". That way our standard aggregator can just work with the profile name, whereas other clients (that don't care how we interpret these terms) could look if an endpoint supports all functionality they need.
    770770      * [[oschonef|Oliver (IDS)]]: Ok, then let's keep `<ed:Profile>` and add the verbose capabilities list to the Endpoint Description. A TODO for the ''basic'' profile is then to decide the ''basic'' capabilities are (I think this should just be one 'basic-search').
    771        * [[teckart|Thomas (ASV)]]: I agree. Our basic profile hardly contains anything that can be differentiated more.
     771       * [[teckart|Thomas (ASV)]]: I agree. Our basic profile hardly contains anything that can be differentiated further.
    772772* [[teckart|Thomas (ASV)]]: The endpoint specification contains information about supported profile and dataviews. This is no problem for an endpoint with only one resource or homogenous resources. When we extend the profile by adding information about annotation tiers this may not be applicable for all provided resources (like an endpoint that provides two corpora, where only one is annotated with POS tags). So maybe some of this information is not specific for the endpoint but for the resource.
    773773 * [[oschonef|Oliver (IDS)]]: My aim was to consider the list of data views as a hint, what data views  are available at an Endpoint. The semantics is not, that ''every'' resource/collections supports all these data views. It's a little influenced by what SRU does in explain with `<zr:schemaInfo>`.  We could keep it this way, remove it of extend it, so this information can be given on resource/collection level