Fix dead links in example readme

Author: PHochmann

examples/README.md

@@ -20,61 +20,57 @@ Example [TEXT_RESOURCE](TEXT_RESOURCE.ttl) is based on the [DATA1](DATA1.ttl) ex
 
 ## Example DATA2: Free download of raw, historical data
 
-The resource example [DATA1](DATA1.ttl) illustrates an easy, non-interactive access to historical data provided by the participant [PART1](PART1.ttl). The monthly traffic statistics collected during a year since 2000 are exposed for download as individual files (“artifacts”) via the Trusted Connector [CONN2](CONN2.ttl). The file names (e.g., `E1_20000101.csv`) encode by convention the discriminating parameters, i.e. the highway (e.g., `E37`), year (e.g., `2018`), month (e.g., `01`). The reports comprise tabular data in CSV format. The data may be used free of charge, the policy requires a credits
+The resource example [DATA1](DATA1.ttl) illustrates an easy, non-interactive access to historical data provided by the participant [PARTICIPANT_1](PARTICIPANT_1.ttl). The monthly traffic statistics collected during a year since 2000 are exposed for download as individual files (“artifacts”) via the Trusted Connector [CONNECTOR_2](CONNECTOR_2.ttl). The file names (e.g., `E1_20000101.csv`) encode by convention the discriminating parameters, i.e. the highway (e.g., `E37`), year (e.g., `2018`), month (e.g., `01`). The reports comprise tabular data in CSV format. The data may be used free of charge, the policy requires a credits
 attribution though.
 
 ## Example DATA3: On-line data query
 
-Example [DATA2](DATA2.ttl) introduces simple interactive features allowing the consumer to selectively retrieve content beyond the constraints of server-defined contents as in example [DATA1](DATA1.ttl) (e.g. statistics for a highway section across several years).
+Example [DATA3](DATA3.ttl) introduces simple interactive features allowing the consumer to selectively retrieve content beyond the constraints of server-defined contents as in example [DATA1](DATA1.ttl) (e.g. statistics for a highway section across several years).
 
-## Example APP1: Data App for content integration (system adapter)
+## Example APP_RESOURCE: Data App for image anonymization
 
-The photographs taken by a surveillance camera are injected into the mobile Connector environment [CONN1](CONN1.ttl) by means of the Data App [APP1](APP1.ttl) serving as a technology adapter. It implements a camera driver that accesses the raw digital content and exposes still images in various representations via a defined interface.
-
-## Example APP2: Data App for image anonymization
-
-The image content provided by [APP1](APP1.ttl) have to be anonymized prior to being forwarded to a Data Consumer. The Data App [APP2](APP2.ttl) accepts images of standard traffic scenarios in various file formats (e.g. PNG, JPG) recorded in compliance with the international norm [IEC 62676-4:2014](https://webstore.iec.ch/publication/7353). It is trained to locate particular personal information (e.g., the license plate of a car) and to apply image
-processing techniques to irreversibly obfuscate this information. The Data App is likewise deployed within the Mobile Connector [CONN1](CONN1.ttl), i.e. at the source of image recording, in order to prevent the disclosure of unprocessed content.
+The Data App [APP_RESOURCE](APP_RESOURCE.ttl) accepts images of standard traffic scenarios in various file formats (e.g. PNG, JPG) recorded in compliance with the international norm [IEC 62676-4:2014](https://webstore.iec.ch/publication/7353). It is trained to locate particular personal information (e.g., the license plate of a car) and to apply image
+processing techniques to irreversibly obfuscate this information. The Data App is likewise deployed within the Mobile Connector [CONNECTOR_1](CONNECTOR_1.ttl), i.e. at the source of image recording, in order to prevent the disclosure of unprocessed content.
 
 # Infrastructure components
 
-## Example CONN1: Mobile, base connector
+## Example CONNECTOR_1: Mobile, base connector
 
-Connectors are the central building blocks, the edge nodes of the IDS network. The example Connector [CONN1](CONN1.ttl) is deployed on a mobile sensor platform located close to a traffic hot spot. It hosts a data processing pipeline where image data received form APP1 is fed into APP2.
+Connectors are the central building blocks, the edge nodes of the IDS network. The example Connector [CONNECTOR_1](CONNECTOR_1.ttl) is deployed on a mobile sensor platform located close to a traffic hot spot.
 
-## Example CONN2: Trusted connector
+## Example CONNECTOR_2: Trusted connector
 
-The Trusted Connector [CONN2](CONN2.ttl) represents a hardened version of the Connector runtime, a certified platform for data integration, processing and publishing maintained by the participant [PART1](PART1.ttl) as part of its data provisioning infrastructure.  
+The Trusted Connector [CONNECTOR_2](CONNECTOR_2.ttl) represents a hardened version of the Connector runtime, a certified platform for data integration, processing and publishing maintained by the participant [PARTICIPANT_1](PARTICIPANT_1.ttl) as part of its data provisioning infrastructure.  
 
 
 ## Example TRUSTED_CONNECTOR: Trusted connector
 
-The TRUSTED_CONNECTOR [TRUSTED_CONNECTOR](TRUSTED_CONNECTOR.ttl) is based on the [CONN2](CONN2.ttl) example with additional comments.
+The TRUSTED_CONNECTOR [TRUSTED_CONNECTOR](TRUSTED_CONNECTOR.ttl) is based on the [CONNECTOR_2](CONNECTOR_2.ttl) example with additional comments.
 
 
-## Example BROKER1: Logistics broker
+## Example BROKER: Logistics broker
 
-Because of the vast amount of resources a dedicated Broker for the "logistics domain" is operated by the service provider [PART2](PART2.ttl). Next to a customer-oriented GUI the data registry exposes a series of service interfaces (APIs) for lif-cycle management (publication,updated, removal) and search of content offerings.  
+Because of the vast amount of resources a dedicated Broker for the "logistics domain" is operated by the service provider [PARTICIPANT_2](PARTICIPANT_2.ttl). Next to a customer-oriented GUI the data registry exposes a series of service interfaces (APIs) for lif-cycle management (publication,updated, removal) and search of content offerings.  
 
-## Example APPSTORE1: General purpose AppStore
+## Example APPSTORE: General purpose AppStore
 
-The example AppStore [APPSTORE1](APPSTORE1.ttl) maintains metadata and software resources across IDS communities and providers. The software company PART2 advertises and distributes
-its Data Apps (e.g. APP2) via that registry.   
+The example AppStore [APPSTORE](APPSTORE.ttl) maintains metadata and software resources across IDS communities and providers. The software company PARTICIPANT_2 advertises and distributes
+its Data Apps (e.g. APP_RESOURCE) via that registry.   
 
 # Participants
 
-## Example PART1: European traffic data provider)
+## Example PARTICIPANT_1: European traffic data provider)
 
-The hypothetical "Highway monitoring and statistics agency" acts as a data provider [PART1](PART1.ttl). It maintains a large-scale infrastructure for monitoring, analysis and prediction of highway utilization statistics in European context. The agency has deployed a range of mobile connectors (e.g. CONN1) for distributed collection and publication of geotagged, regional sensor data, likewise a secure connector (CONN2) for sharing valuable statistics
+The hypothetical "Highway monitoring and statistics agency" acts as a data provider [PARTICIPANT_1](PARTICIPANT_1.ttl). It maintains a large-scale infrastructure for monitoring, analysis and prediction of highway utilization statistics in European context. The agency has deployed a range of mobile connectors (e.g. CONNECTOR_1) for distributed collection and publication of geotagged, regional sensor data, likewise a secure connector (CONNECTOR_2) for sharing valuable statistics
 reports and predictions.
 
 
-## Example PART2: Software development and service provision
+## Example PARTICIPANT_2: Software development and service provision
 
-The participant App4Traffic GmbH ([PART2](PART2.ttl)) provides a wide range of software development, consultancy and data hosting services and thus implements multiple roles within the IDS ecosystem. Based in Switzerland (Musterstraße 2, Zürich) the SME develops and distributes IDS Data Apps (e.g. APP1) and serves
-customers like PART3 with advanced analytics services based upon data from PART1.   
+The participant App4Traffic GmbH ([PARTICIPANT_2](PARTICIPANT_2.ttl)) provides a wide range of software development, consultancy and data hosting services and thus implements multiple roles within the IDS ecosystem. Based in Switzerland (Musterstraße 2, Zürich) the SME develops and distributes IDS Data Apps and serves
+customers like PARTICIPANT_3 with advanced analytics services based upon data from PARTICIPANT_1.   
 
-## Example PART3: Global logistics company
+## Example PARTICIPANT_3: Global logistics company
 
 The international "Supercargo Logistics" company provides services around the globe with subsidiaries in a number of countries, among others Supercargo GmbH - headquarters - (Musterstraße 5, Köln, Deutschland), Supercargo OOO (Yлица пример 120, Москва), and Supercargo Ltd. (Sample Road 15c, Hongkong).
 Their businesses are thus subject to international, national and optionally some custom regulations (legal areas). The organization complies with the ISIC classification rev. 4 and has ISIC code 4923 (freight transport via road). The company retrieves live traffic monitoring data, in order to supply its drivers with up-to-date traffic information, efficient routing and timely hazard warnings.
@@ -83,17 +79,3 @@ Their businesses are thus subject to international, national and optionally some
 
 In the following examples of business interactions among participants are given. The realization of the core IDS value propositions (secure data transfer between standardized components while ensuring data sovereignty) is supported by interactions (e.g. data transfer) annotated with metadata (instances of the `Message` class in the header part). Metadata descriptions of content being exchanged are mandatory. Therefore, the IDS infomodel introduces a concise set of message types specifying metadata fields that must/should/can be given in order to
 facilitate the business interactions.
-
-## Example INTER1: Connector registration at Broker (stable)
-
-The example [INTER1](INTER1.ttl) showcases the publication of Resources as part of the overall "self-description" of a Connector.
-Connector CONN2 registers at the Broker INFRA1 by dispatching a dedicated message to the generic Message-API of the Broker (`ConnectorAvailable`). Next to the mandatory fields, the message header identifies the consumer connector (Broker). The message payload comprises the complete "self-description"
-document of the registering Connector, i.e., the content of [CONN2](CONN2.ttl) in JSON(-LD) format (default).
-
-## Example INTER2: Broker search and identification of content offerings (stable)
-
-Later on the Connector CONN2 may issue queries on the Broker to learn about Resources available ([INTER2](INTER2.ttl)). For this purpose it dispatches a dedicated request message (`BrokerQuery`), indicating the target scope of the query ("all", or only "active", i.e. live connectors) and the query language
-type. The respective query string is supplied as the literal payload. In case of a SPARQL this might be a DESCRIBE_QUERY, e.g. ```DESCRIBE ?content WHERE { ?content a ids:Content  }``` retrieving information about any content available. Upon request completion, a Result message is sent back to the issuing connector CONN2. The Result message is fairly minimal containing only the mandatory fields and a correlation attibute referring to the previously sent request. The resultant payload is an RDF graph serialized as a default or client-selected Representation.  
-
-## Example INTER3: Contract negotiation of the selected contents
-Example [INTER3](INTER3.ttl) illustrates the message exchange in order to negotiate a usage contract.