5.1 KiB
| title | chunk | source | category | tags | date_saved | instance |
|---|---|---|---|---|---|---|
| Discoverability | 3/4 | https://en.wikipedia.org/wiki/Discoverability | reference | science, encyclopedia | 2026-05-05T07:22:29.265231+00:00 | kb-cron |
=== Internet search === For items that are searched for online, the goal of discoverability is to be at or near the top of the search results. Organizations may make efforts to make it more likely, that "their" content or webpages are at the top, or close to the top, of search results; these approaches are often collectively called search engine optimization (SEO). Note that when an organization takes action to increase the SEO of its website, this does not normally involve changes to the search engine itself; rather, it involves adding metadata tags and original content, among other strategies, to increase the "visibility" of the website to search engine algorithms. Recent discussions of discoverability have also considered AI-generated answer systems, in which visibility may depend not only on ranking in conventional search results but also on whether sources are selected, cited, and synthesized in generated responses.
==== Services ==== In a service delivery context, the application of this principle requires collecting information about the service during the service analysis phase as during this phase; maximum information is available about the service's functional context and the capabilities of the service. At this stage, the domain knowledge of the business experts could also be enlisted to document meta-data about the service. In the service-oriented design phase, the already gathered meta-data could be made part of the service contract. The OASIS SOA-RM standard specifies service description as an artifact that represents service meta-data. To make the service meta-data accessible to interested parties, it must be centrally accessible. This could either be done by publishing the service-meta to a dedicated 'service registry' or by simply placing this information in a 'shared directory'. In case of a 'service registry', the repository can also be used to include QoS, SLA and the current state of a service.
=== Voice user interfaces === Voice user interfaces may have low discoverability if users are not aware of the commands that they are able to say, so these interfaces may display a list of available commands to help users find them.
== Metadata types ==
=== Functional === This is the basic type of meta-information that expresses the functional context of the service and the details about the product, content, or service's capabilities. The application of the standardized service contract principle helps to create the basic functional meta-data in a consistent manner. The same standardization should be applied when the same meta-information is being outside the technical contract of the service e.g. when publishing information to a service registry. For general items, the data that might be used to categorize them may include:
Name of product, content or service (for audiovisual content, this would be song name, or TV show/movie title) Name of manufacturer, designer, creators (for audiovisual content, this would be names of director/producer/artists) Technical data (size, weight, height for physical items, or in the case of digital files, compression approach, file size) For items which can identify their location via embedded sensors (such as with Internet of things geolocation data), location of use/access)
=== Quality of service ===
For services, to know about the service behavior and its limitations, and about the user experience, all of this information needs to be documented within the service registry. This way potential consumers can use this meta-information by comparing it against their performance requirements.
== Considerations ==
=== Services === The effective application of this design principle requires that the meta-information recorded against each service needs to be consistent and meaningful. This is only possible if organization-wide standards exist that enforce service developers to record the required meta-data in a consistent way. The information recorded as the meta-data for the service needs to be presented in a way so that both technical and non-technical IT experts can understand the purpose and the capabilities of the service, as an evaluation of the service may be required by the business people before the service is authorized to be used. This principle is best applied during the service-oriented analysis phase as during this time, all the details about the service's purpose and functionality are available. Although most of the service design principles support each other in a positive manner, however, in case of service abstraction and service discoverability principle, there exists an inversely proportional relationship. This is because as more and more details about the service are hidden away from the service consumers, less discoverable information is available for discovering the service. This could be addressed by carefully recording the service meta-information so that the inner workings of the service are not documented within this meta-information.