eduKateSG · Why Science?
Let one scientific web service introduce itself clearly—then verify what that description does and does not promise
Choose the closest route, then return to the full index whenever you need the wider evidence chain.
Science learning becomes powerful when students can tell a measured pattern from a model, a statistical decision from a mechanism, and a useful lead from a finished conclusion. GA4GH Service Info is a small standard that lets one web service describe itself through a common service-info endpoint. GA4GH lists it as current and Support Ready, with v1.0 approved on 5 February 2020. A response can identify the service, its type and version, the organisation responsible for it, an environment and optional descriptive fields. Other GA4GH APIs can embed or extend the model so clients discover protocol-specific capabilities without inventing unrelated metadata shapes. Service Info does not prove that a service is healthy, secure, scientifically valid, policy-compliant or authorised for a particular user, and it does not describe a catalogue of many services—that is the separate role of Service Registry. This guide supports Primary Science, PSLE Science, Secondary Science, O-Level Science and STEM education as a longform evidence-reading route; it is not medical advice, a laboratory protocol, an admission promise or a career guarantee.
Related eduKate reading: GA4GH Workflow Execution Service and portable workflows; GA4GH Task Execution Service and portable compute tasks; GA4GH Tool Registry Service and discoverable workflows; Science Learning Hub; Education Hub; STEM Education; Careers by Subject Capability.
Primary and official sources checked on 12 October 2026: Official GA4GH Service Info product page, current v1.0; Official GA4GH Service Info specification repository; Official GA4GH Service Info and Registry announcement; 2026 Singapore–Cambridge O-Level Biology syllabus; MOE G2/G3 Lower Secondary Science teaching and learning syllabus; 2026 MOE G2 Computing syllabus. Standards, service interfaces and recommendations can change, so preserve the dated documentation and versions used.
A deeper reading route
Service Info solves a modest but important problem: before a client talks to a scientific API, it needs to know what is answering. A predictable self-description can provide a stable service identity, responsible organisation, interface type and version. That reduces brittle configuration and makes provenance clearer. It also keeps discovery close to the service that owns the information, where deployment updates can be reflected deliberately.
The endpoint describes one service, not the entire organisation and not every downstream dependency. A WES implementation, for example, can use Service Info to advertise its WES type and supported details while a TES implementation describes itself separately. A client should avoid turning a friendly name or organisation field into an assumption about compatibility. Type, version, extensions and tested behaviour matter more than branding.
Self-description is evidence supplied by the service. It can be accurate, stale, incomplete or temporarily inconsistent with the running deployment. Strong clients cache cautiously, compare identity across requests and run small conformance checks. Operators should update metadata alongside releases and preserve old records in provenance. A service that says it is version 1.0 still needs behavioural tests before important data or compute is entrusted to it.
The endpoint is commonly public because discovery must happen before authentication, yet extensions can accidentally reveal internal hosts, software stacks, contact details or restricted capabilities. The specification calls for secure transport when sensitive information is involved and supports bearer-token patterns where authorisation is required. The safest metadata set is useful to legitimate clients and uninteresting to attackers.
Service Info also clarifies the difference between identity, capability, health and policy. Identity answers “which service is this?” Capability answers “which interface or extension does it claim?” Health requires monitoring or status signals, and policy decides whether a caller may act. Putting all four into one green badge creates false confidence; keeping them separate makes operations and scientific reporting more honest.
For students, the idea resembles a labelled laboratory instrument. The label says model, manufacturer and version, while a calibration record shows performance and a safety procedure controls use. One label is valuable precisely because it does not pretend to replace the other checks.
| Stage | Question | Evidence | Responsible output |
|---|---|---|---|
| Identify | Which single service is answering? | Stable ID, name and organisation | A traceable service identity |
| Describe | Which API type and version are claimed? | Service type, group and version | A discoverable interface contract |
| Extend | Which protocol-specific details are exposed? | Typed extensions and documented fields | A client-readable capability profile |
| Verify | Does the deployment behave as described? | Conformance, security and health checks | A bounded operational decision |
Inside this guide
1–12 · Foundations and design
- 1. Start with one service
- 2. Understand the current standard
- 3. Use the common service-info route
- 4. Preserve a stable service ID
- 5. Read the human name as a label
- 6. Use descriptions for orientation
- 7. Identify the responsible organisation
- 8. Read the service type precisely
- 9. Separate API and deployment versions
- 10. Interpret environment carefully
- 11. Treat contact information responsibly
- 12. Record creation and update context
13–24 · Models and estimation
- 13. Use upstream service types
- 14. Extend the model through schemas
- 15. Avoid extension collisions
- 16. Do not mistake a base URL for every route
- 17. Keep metadata fresh
- 18. Cache with an expiry policy
- 19. Treat public metadata as a security boundary
- 20. Use secure transport
- 21. Apply bearer authentication when required
- 22. Keep error meaning bounded
- 23. Separate identity from health
- 24. Separate capability from authorisation
25–36 · Diagnostics and interpretation
- 25. Separate conformance from science
- 26. Connect Service Info to WES
- 27. Connect Service Info to TES and TRS
- 28. Connect to Primary Science
- 29. Connect to Secondary Science
- 30. Connect to mathematics
- 31. Connect to computing
- 32. Connect to pathways
- 33. Did you know?
- 34. Write a reader-ready service record
- 35. Build a validation ladder
- 36. Finish with a reproducible bundle
Section 1 of 36
1. Start with one service
Service Info is a self-description for one service endpoint. It should answer which service a client reached before the client assumes compatibility.
Working checkpoint — Service Info: Bind the response to the exact base URL and access time. Keep endpoint, stable ID, service type and versions, organisation, environment and retrieval time together.
For a classroom model, label a fictional instrument and add separate calibration and safety cards.
Section 2 of 36
2. Understand the current standard
GA4GH lists Service Info as current and Support Ready and identifies v1.0, approved on 5 February 2020, as the last approved version.
Working checkpoint — service metadata: Record standard and implementation versions separately. Read every advertised capability beside schema validation, live conformance checks and authentication context.
For future study, connect service discovery to science, computing and cybersecurity while checking official pathways separately.
Section 3 of 36
3. Use the common service-info route
The standard adds a predictable service-info endpoint so clients do not need a different discovery convention for every GA4GH API.
Working checkpoint — service type: Test the route from the same network path as the client. Preserve stale or conflicting responses; a current page is not the complete deployment history.
For scientific writing, cite the service identity, endpoint, API version and dated metadata.
Section 4 of 36
4. Preserve a stable service ID
The identifier helps distinguish a service across deployments or names. Stability needs governance; reusing an ID for a different service breaks provenance.
Working checkpoint — API version: Define who issues IDs and when a new one is required. Separate self-description and API conformance from health, authorisation, security review and scientific validity.
For students, ask what the digital instrument calls itself, who operates it and which version it claims.
Section 5 of 36
5. Read the human name as a label
A name helps people recognise a service but is not a globally unique key and can change for branding or clarity.
Working checkpoint — deployment environment: Display the name while storing the stable ID. Treat service ID, API type and version as scientific apparatus identifiers: a silent change can alter behaviour.
For parents, ask which checks go beyond the label before data or computation are entrusted to it.
Section 6 of 36
6. Use descriptions for orientation
A description can explain intended purpose and scope. It is prose, not a machine-enforced guarantee or a substitute for protocol documentation.
Working checkpoint — capability discovery: Compare stated purpose with the requested use. Keep endpoint, stable ID, service type and versions, organisation, environment and retrieval time together.
For a classroom model, label a fictional instrument and add separate calibration and safety cards.
Section 7 of 36
7. Identify the responsible organisation
Organisation metadata connects a service to the group responsible for it and can include a name and URL. Responsibility still needs operational ownership.
Working checkpoint — Service Info: Verify the organisation through an approved registry or agreement. Read every advertised capability beside schema validation, live conformance checks and authentication context.
For future study, connect service discovery to science, computing and cybersecurity while checking official pathways separately.
Section 8 of 36
8. Read the service type precisely
The type conveys a group, artifact and version that identify the API contract. Clients should use it for compatibility rather than infer from a product name.
Working checkpoint — service metadata: Validate every component of the advertised type. Preserve stale or conflicting responses; a current page is not the complete deployment history.
For scientific writing, cite the service identity, endpoint, API version and dated metadata.
Section 9 of 36
9. Separate API and deployment versions
A service can implement one API contract while its software deployment has another release number. Those versions answer different questions.
Working checkpoint — service type: Store both when the implementation exposes them. Separate self-description and API conformance from health, authorisation, security review and scientific validity.
For students, ask what the digital instrument calls itself, who operates it and which version it claims.
Section 10 of 36
10. Interpret environment carefully
An environment label can distinguish production, testing or another deployment context. Free-text labels need local conventions to avoid ambiguity.
Working checkpoint — API version: Reject accidental use of a test environment for production data. Treat service ID, API type and version as scientific apparatus identifiers: a silent change can alter behaviour.
For parents, ask which checks go beyond the label before data or computation are entrusted to it.
Section 11 of 36
11. Treat contact information responsibly
Contact URLs or information can help users report problems, but personal addresses and internal routing should not be overexposed.
Working checkpoint — deployment environment: Publish a maintained service channel rather than private details. Keep endpoint, stable ID, service type and versions, organisation, environment and retrieval time together.
For a classroom model, label a fictional instrument and add separate calibration and safety cards.
Section 12 of 36
12. Record creation and update context
Timestamps can help clients judge freshness when implemented, but clocks, deployment pipelines and cache layers can produce discrepancies.
Working checkpoint — capability discovery: Compare metadata time with observed release and cache headers. Read every advertised capability beside schema validation, live conformance checks and authentication context.
For future study, connect service discovery to science, computing and cybersecurity while checking official pathways separately.
Section 13 of 36
13. Use upstream service types
When another GA4GH standard embeds Service Info, its own type should identify the actual API rather than a generic Service Info type.
Working checkpoint — Service Info: Advertise the protocol clients will call. Preserve stale or conflicting responses; a current page is not the complete deployment history.
For scientific writing, cite the service identity, endpoint, API version and dated metadata.
Section 14 of 36
14. Extend the model through schemas
Protocol-specific specifications can extend the common model with their own fields, allowing a shared base plus meaningful capabilities.
Working checkpoint — service metadata: Validate extensions against the owning API schema. Separate self-description and API conformance from health, authorisation, security review and scientific validity.
For students, ask what the digital instrument calls itself, who operates it and which version it claims.
Section 15 of 36
15. Avoid extension collisions
Locally invented fields can collide with later standards or mean different things across services. Namespacing and documentation reduce ambiguity.
Working checkpoint — service type: Register or namespace durable extensions. Treat service ID, API type and version as scientific apparatus identifiers: a silent change can alter behaviour.
For parents, ask which checks go beyond the label before data or computation are entrusted to it.
Section 16 of 36
16. Do not mistake a base URL for every route
A self-description identifies the service, but clients still need the protocol specification to construct operations and understand errors.
Working checkpoint — API version: Resolve routes from the correct API documentation. Keep endpoint, stable ID, service type and versions, organisation, environment and retrieval time together.
For a classroom model, label a fictional instrument and add separate calibration and safety cards.
Section 17 of 36
17. Keep metadata fresh
A stale version, organisation or environment label can send clients to the wrong code path or trust decision. Metadata belongs in release management.
Working checkpoint — deployment environment: Test Service Info during every deployment. Read every advertised capability beside schema validation, live conformance checks and authentication context.
For future study, connect service discovery to science, computing and cybersecurity while checking official pathways separately.
Section 18 of 36
18. Cache with an expiry policy
Caching improves discovery speed and resilience, yet indefinite caching hides upgrades and withdrawn services.
Working checkpoint — capability discovery: Store retrieval time and revalidate before critical work. Preserve stale or conflicting responses; a current page is not the complete deployment history.
For scientific writing, cite the service identity, endpoint, API version and dated metadata.
Section 19 of 36
19. Treat public metadata as a security boundary
Discovery information may be public by design, but extensions can reveal internal hosts, software details or restricted projects.
Working checkpoint — Service Info: Review every field for disclosure risk. Separate self-description and API conformance from health, authorisation, security review and scientific validity.
For students, ask what the digital instrument calls itself, who operates it and which version it claims.
Section 20 of 36
20. Use secure transport
The specification calls for TLS 1.2 or higher when sensitive information is transported. Secure transport protects metadata and tokens in transit.
Working checkpoint — service metadata: Reject downgraded or invalid certificate connections. Treat service ID, API type and version as scientific apparatus identifiers: a silent change can alter behaviour.
For parents, ask which checks go beyond the label before data or computation are entrusted to it.
Section 21 of 36
21. Apply bearer authentication when required
A deployment can require OAuth 2 bearer credentials for protected information. Authentication changes access, not the semantics of the metadata.
Working checkpoint — service type: Use scoped, short-lived tokens and never place them in URLs. Keep endpoint, stable ID, service type and versions, organisation, environment and retrieval time together.
For a classroom model, label a fictional instrument and add separate calibration and safety cards.
Section 22 of 36
22. Keep error meaning bounded
The Service Info specification defines the successful response shape; surrounding infrastructure and embedded APIs can define additional errors.
Working checkpoint — API version: Document implementation error behaviour separately. Read every advertised capability beside schema validation, live conformance checks and authentication context.
For future study, connect service discovery to science, computing and cybersecurity while checking official pathways separately.
Section 23 of 36
23. Separate identity from health
A valid self-description can be returned while a downstream database or worker is unhealthy. Service Info is not automatically a health-check protocol.
Working checkpoint — deployment environment: Use dedicated readiness and functional probes. Preserve stale or conflicting responses; a current page is not the complete deployment history.
For scientific writing, cite the service identity, endpoint, API version and dated metadata.
Section 24 of 36
24. Separate capability from authorisation
A service may advertise a feature that a particular user cannot invoke. Capability says what exists; policy says who may use it.
Working checkpoint — capability discovery: Test both discovery and an authorised fixture. Separate self-description and API conformance from health, authorisation, security review and scientific validity.
For students, ask what the digital instrument calls itself, who operates it and which version it claims.
Section 25 of 36
25. Separate conformance from science
A perfectly conformant API can serve poorly designed or misinterpreted data. Technical interoperability does not establish scientific validity.
Working checkpoint — Service Info: Review study design and evidence independently. Treat service ID, API type and version as scientific apparatus identifiers: a silent change can alter behaviour.
For parents, ask which checks go beyond the label before data or computation are entrusted to it.
Section 26 of 36
26. Connect Service Info to WES
WES uses service information to describe workflow types, versions and implementation details relevant to portable submission.
Working checkpoint — service metadata: Archive Service Info beside each important workflow run. Keep endpoint, stable ID, service type and versions, organisation, environment and retrieval time together.
For a classroom model, label a fictional instrument and add separate calibration and safety cards.
Section 27 of 36
27. Connect Service Info to TES and TRS
TES and TRS clients also benefit from discovering the exact service and supported contract before moving tasks or workflow descriptors.
Working checkpoint — service type: Compare advertised capabilities with a small conformance fixture. Read every advertised capability beside schema validation, live conformance checks and authentication context.
For future study, connect service discovery to science, computing and cybersecurity while checking official pathways separately.
Section 28 of 36
28. Connect to Primary Science
A microscope label tells students which instrument they have, while calibration and safe-use checks answer different questions.
Working checkpoint — API version: Build a fictional label with identity, version and owner. Preserve stale or conflicting responses; a current page is not the complete deployment history.
For scientific writing, cite the service identity, endpoint, API version and dated metadata.
Section 29 of 36
29. Connect to Secondary Science
Scientific apparatus needs traceable models, versions and conditions. Software services are part of the apparatus in computational experiments.
Working checkpoint — deployment environment: Include the service identity in a digital methods section. Separate self-description and API conformance from health, authorisation, security review and scientific validity.
For students, ask what the digital instrument calls itself, who operates it and which version it claims.
Section 30 of 36
30. Connect to mathematics
Identifiers, version tuples, sets of capabilities and freshness intervals connect service discovery to logic and discrete mathematics.
Working checkpoint — capability discovery: Compare exact version components rather than names. Treat service ID, API type and version as scientific apparatus identifiers: a silent change can alter behaviour.
For parents, ask which checks go beyond the label before data or computation are entrusted to it.
Section 31 of 36
31. Connect to computing
REST discovery, JSON schemas, inheritance, TLS, bearer tokens and caching show how metadata supports interoperable systems.
Working checkpoint — Service Info: Test malformed, stale and unauthorised responses. Keep endpoint, stable ID, service type and versions, organisation, environment and retrieval time together.
For a classroom model, label a fictional instrument and add separate calibration and safety cards.
Section 32 of 36
32. Connect to pathways
Scientific service operations connect computing, data engineering, cybersecurity and research support and can illuminate STEM pathways.
Working checkpoint — service metadata: Check current official qualifications separately. Read every advertised capability beside schema validation, live conformance checks and authentication context.
For future study, connect service discovery to science, computing and cybersecurity while checking official pathways separately.
Section 33 of 36
33. Did you know?
Service Info is intentionally about one service, while Service Registry groups descriptions of multiple services. The two standards solve different discovery layers.
Working checkpoint — service type: Choose the smallest standard that matches the question. Preserve stale or conflicting responses; a current page is not the complete deployment history.
For scientific writing, cite the service identity, endpoint, API version and dated metadata.
Section 34 of 36
34. Write a reader-ready service record
Name the endpoint, stable ID, service type and version, organisation, environment, extensions, retrieval time and verification status.
Working checkpoint — API version: Keep claimed and tested capabilities in separate columns. Separate self-description and API conformance from health, authorisation, security review and scientific validity.
For students, ask what the digital instrument calls itself, who operates it and which version it claims.
Section 35 of 36
35. Build a validation ladder
Validate JSON and type, compare versions, review disclosure, test TLS and authentication, run a conformance fixture, then use the service.
Working checkpoint — deployment environment: Stop when identity or trust remains ambiguous. Treat service ID, API type and version as scientific apparatus identifiers: a silent change can alter behaviour.
For parents, ask which checks go beyond the label before data or computation are entrusted to it.
Section 36 of 36
36. Finish with a reproducible bundle
Deliver Service Info responses, schemas, timestamps, endpoint and certificate context, test results, policy notes and links to runs or data.
Working checkpoint — capability discovery: Make the digital instrument identifiable after the experiment. Keep endpoint, stable ID, service type and versions, organisation, environment and retrieval time together.
For a classroom model, label a fictional instrument and add separate calibration and safety cards.
Contents · Previous section · Continue to the Science Learning Hub