Site capabilties listing extended to include services within CANFAR / SI / User Storage sites

In this SRCNet environment numerous teams,  distributed across different countries and institutions, work together to design, develop, and deploy various prototypes and services essential for the SRCNet itself. These components may include data storage systems, processing platforms, software repositories, APIs, hubs,monitoring tools, DTNs, frontends, protocols, computing resources, software services and more.  

The need to effectively coordinate and share information on the services developed and made available by the different teams (from PI15 onwards) is very important. Without a centralized system (wiki, repo, live document, other,...) to catalog/index and visualize these services, teams may struggle to discover and leverage resources that could significantly enhance their work.  This feature aims to address this challenge by providing a directory where teams can register and showcase the services they offer. This directory becomes a hub of information, facilitating transparency, collaboration, and efficient resource allocation across the SRCNet members/teams.

Here is a list of features that I think are sufficient for now (can be organized by Team, for example):

1. Semantic metadata of the service: (jsonld file) semantic metadata can provide additional insights and enhance the discoverabiliity and interoperability of the services. Thinking about the future, interoperability is key, and having the semantic description would be a plus for the discovery of services.{}
2. Name: Short name of the service, platform, API, etc.
3. URL/IP:  DNS, Address or IP address of the service.
4. Detailed description: Information detailing the functionalities and capabilities of the service.
5. Responsible person: Individual or team responsible for the maintenance and support of the service (Jira user, email, etc.)
6. Location/Origin: Country/Location where the team or SRC responsible for the service is located.
7. SRC or work team: Identification of the team or SRC that developed or manages the service.
8. Service status: Current state of the service (available, shut down, in development, etc.).
9. Service lifespan: Estimated duration of the service, if temporary.
10. Permanent, long-term or temporary development: Indication of whether the service is permanent or temporarily in development.
11. Version, Compatibility and/or integration requirements: Details about platforms, operating systems, or other dependencies necessary to use the service.
12. Performance metrics: Relevant data on the performance of the service, such as response time, availability, and scalability.
13. Security requirements: Specifications about security measures implemented in the service, such as authentication, authorization, and data encryption, if needed.
14. Additional documentation: Links or references to additional technical or outcomes, documentation, tutorials, or usage guides for the service.