166_batch_annotate_gene_list: Given a batch list of UniProt accessions, retrieve one row per entry with its recommended protein name, function description, and reviewed status in a single query. This is the classic 'annotate my differential-expression gene list' BioMart workflow (attributes=c(\"name\",\"description\",\"reviewed\") in one getBM() call)

167_batch_canonical_sequence_retrieval: Given a batch list of UniProt accessions, retrieve the amino acid sequence for each in a single query, matching BioMart's classic bulk "peptide" attribute pull

168_batch_ensembl_transcript_cross_references: Given a batch of UniProt accessions, map each to its cross-referenced Ensembl transcript(s) in one query. This relationship is one-to-many (a protein can have several Ensembl transcripts), which is a recurring biomaRt pain point since getBM() is reported to drop or omit rows for it -- with SPARQL, a one-to-many mapping simply produces more result rows

169_batch_kegg_cross_references: Given a batch of UniProt accessions, retrieve each one's KEGG gene cross-reference in a single query. Note: if building metabolic pathways we recommend looking at how Rhea is used in UniProt.

170_batch_ensembl_gene_and_protein_ids: Given a batch of UniProt accessions, resolve each to its Ensembl gene ID and Ensembl protein ID in one query. UniProt's rdfs:seeAlso cross-reference to Ensembl only reaches the transcript level directly; the transcript resource itself links on to the gene it was transcribed from (up:transcribedFrom, an ENSG id) and the protein it was translated to (up:translatedTo, an ENSP id), so no federation with an external Ensembl endpoint is needed to reach gene-level identifiers. Similar pattern appears for the other Ensembl like databases such as EnsemblBacteria

171_batch_id_mapping_style_lookup: Given a batch of UniProt accessions, resolve each to its mnemonic entry name, recommended protein name, and organism in one query -- the SPARQL equivalent of the columns (EntryName, ProteinName, Organism) UniProt's own web-based ID mapping/retrieve service returns

172_reviewed_members_of_a_reference_proteome: For a given taxon (Escherichia coli K12), find its reference proteome and list the reviewed proteins that are members of it. This goes one step further than finding just the proteome resource: a protein's up:proteome value identifies a component (e.g. a chromosome) of a proteome, whose IRI is the proteome's own IRI with a '#' fragment appended. The relation between a component and a proteome is via skos:narrower

173_batch_ec_number_lookup: Given a batch of Enzyme Commission (EC) numbers, list the reviewed UniProt entries classified with each one, in a single query. A protein can be linked to an EC number three different ways: directly (up:enzyme), through a catalytic activity annotation's Rhea-linked enzyme classification (up:catalyticActivity/up:enzymeClass), or as a plain string in a structured protein name (up:ecName) -- the ?mappedVia column states which

174_pdb_structures_via_pdbj_federation: Starting from human tumor suppressor TP53 (P04637), federate live with PDBj/RDF Portal's wwPDB RDF to list the extended, versioned wwPDB identifier (e.g. pdb_00002bq0, not the legacy 4-character code) of every PDB entry that has been experimentally solved for it. This goes through PDBj's own pdbo:link_to_uniprot cross-reference rather than UniProt's local rdfs:seeAlso/database cross-reference, so it is a genuine two-endpoint federated query, not a locally-built PDB identifier

175_uniprot_identity_of_a_pdb_entry_via_pdbj: Starting from PDB entry pdb_00002bq0 (the extended, versioned wwPDB identifier for legacy entry 2BQ0), federate live with PDBj/RDF Portal's wwPDB RDF to retrieve the recommended or submitted protein name and organism of the UniProt entity it was solved from -- the reverse direction of resolving a protein to its PDB structures

176_taxon_names_not_unique: Find up:scientificName values that label more than one taxon. The same string can genuinely be reused for unrelated nodes in UniProt's taxonomy: a higher-rank name is sometimes also reused at genus rank (e.g. Acanthocephala, a phylum of thorny-headed worms, is also an insect genus elsewhere in the tree); "environmental samples" is a special case, a placeholder reused thousands of times under many different higher taxa for unclassified/metagenomic entries

177_subcellular_location_go_direct_match: Find UniProt's subcellular-location ontology terms (up:Cellular_Component, the http://purl.uniprot.org/locations/ terms behind section G's per-protein annotations) and the Gene Ontology cellular-component term each one exactly matches, via skos:exactMatch

178_subcellular_location_go_indirect_match: Find Gene Ontology terms that are a looser match to a UniProt subcellular-location term than the direct skos:exactMatch: GO terms reached from the directly-matched term via rdfs:subClassOf+ (is-a), or via a BFO_0000050 (part_of) owl:Restriction on top of it. GO's own part_of axioms are loaded in the UniProt endpoint as an owl:Restriction blank node (a rdfs:subClassOf [ a owl:Restriction ; owl:onProperty obo:BFO_0000050 ; owl:someValuesFrom b ] means a is part_of b), so combining a property path with that restriction pattern is what it takes to follow "is-a-or-part-of" one more step

179_subcellular_location_names: List every term in UniProt's subcellular-location ontology (up:Cellular_Component) with its preferred name and description

180_subcellular_location_ancestors: Find every broader subcellular location reachable from a given one (here, Endosome membrane, locations:100). The location hierarchy mixes rdfs:subClassOf (is-a) and up:partOf (part-of) edges, so both have to be chained together - rdfs:subClassOf*/up:partOf+/rdfs:subClassOf* - to reach the full set of ancestors; using only one of the two misses e.g. Endosome (is-a) or Membrane (part-of, then is-a)

181_subcellular_locations_that_are_membranes: Find every subcellular location that is itself a kind of membrane, by reasoning back to locations:162 ("Membrane") over the same mixed rdfs:subClassOf/up:partOf hierarchy as #180. Nothing states directly that e.g. Endosome membrane "is a membrane" - it has to be derived by following the location hierarchy up to the Membrane term

182_reviewed_proteins_by_ec_class: Count reviewed proteins classified anywhere under EC class 2.7 (transferases that transfer phosphorus-containing groups, e.g. kinases), matched either directly via up:enzyme or through a catalytic-activity annotation's Rhea-linked enzyme classification. EC subclasses are materialized in UniProt's data, so this is done with a plain rdfs:subClassOf join against the whole 2.7.-.- subtree rather than an rdfs:subClassOf+ transitive path or a STRSTARTS string-prefix filter on the EC IRI

183_protein_count_by_clade_single_hop: Compare the number of reviewed proteins in two named taxonomic clades (Primates, Rodentia), using a single-hop ?organism rdfs:subClassOf ?clade rather than the transitive rdfs:subClassOf+ or rdfs:subClassOf* form. UniProt's taxonomy is pre-flattened: every taxon carries a direct rdfs:subClassOf edge to every one of its ancestors, not only its immediate parent (verified live: taxon 9606, Homo sapiens, has 30 direct rdfs:subClassOf triples, one per ancestor up to cellular organisms), so a single hop already reaches every member of a clade at any depth and is far cheaper than the transitive path

184_multiple_annotation_types_via_faldo: Retrieve several different kinds of positional annotation (modified residues, domains, binding sites) together in one query, each one's sequence range resolved through FALDO in the same WHERE clause, instead of writing one query per annotation type. The candidate types are listed with VALUES rather than bound to a variable and checked with FILTER(?annotType IN (...)): live against sparql.uniprot.org, the FILTER(IN) form was slow and unstable (anywhere from 14s to over a minute, sometimes timing out outright), while VALUES consistently answered in a few seconds

185_proteins_by_keyword_complete_enumeration: Count reviewed proteins classified with the controlled-vocabulary keyword Kinase (keywords:418) via up:classifiedWith. This is the complete route to "every kinase": a free-text search over protein names or comments for the word "kinase" would miss proteins named with the synonym "Phosphotransferase" (keywords:418's own skos:altLabel) instead, while curator-assigned keyword classification catches both consistently

186_ensembl_gene_biotype_and_location: Given a UniProt protein (human TP53, P04637), federate out to Ensembl's own RDF at RDF Portal to retrieve its gene's biotype and genomic location (begin/end via FALDO). UniProt only holds the Ensembl gene identifier locally (up:transcribedFrom); the gene's own attributes - biotype, genomic coordinates - only exist in Ensembl's RDF, not UniProt's. Note: up:transcribedFrom's object is a *versioned* Ensembl gene IRI (e.g. .../ENSG00000141510.20), but RDF Portal's Ensembl graph identifies the gene by its *unversioned* IRI, so a direct IRI join between the two silently returns nothing; matching via rdfs:seeAlso from the protein (as done here), filtered to the ensembl:EnsemblGene type to exclude transcripts, avoids that mismatch

187_reactome_pathways_via_ensembl_gene: Given a UniProt protein (human TP53, P04637), list the Reactome pathways it participates in, reached via its Ensembl gene's own rdfs:seeAlso links at RDF Portal. This is a federated alternative to any pathway cross-references UniProt exposes directly: the Ensembl gene resource carries rdfs:seeAlso triples both back to the UniProt protein and out to each Reactome pathway identifier, so matching on the shared gene resource joins the two

188_batch_gene_symbol_to_uniprot_and_ensembl: Given a batch of human gene symbols (TP53, BRCA1, EGFR), resolve each to its Ensembl gene ID and reviewed UniProt accession in one federated query - the closest direct analogue to biomaRt's getBM() across two live SPARQL endpoints instead of one local database. Gene symbols and the Ensembl gene resource itself only exist in Ensembl's own RDF, so the symbol-to-gene match happens inside the SERVICE clause; restricting to human (RO_0002162, in-taxon) avoids matching the same symbol used for orthologous genes in other species, and the up:reviewed true filter (evaluated locally, since ?protein is already bound to a UniProt IRI) keeps one canonical accession per gene rather than every isoform

189_pseudokinases: Find reviewed human pseudokinases: proteins with an annotated protein kinase domain but no annotated kinase (phosphotransferase) catalytic activity at all - a real, well-known biological category (catalytically-dead kinase domains repurposed for scaffolding/allosteric regulation, e.g. Tribbles homologs). The kinase domain itself is a up:Domain_Extent_Annotation whose rdfs:comment names it ("Protein kinase", sometimes qualified "; inactive" or "; truncated")

190_ion_channels_associated_with_disease: Find reviewed proteins classified with the Ion channel keyword that are also linked to a disease, and name the disease - combining a structural/functional classification with clinical relevance

191_calcium_dependent_enzymes_with_binding_site: Find reviewed enzymes that both require Ca(2+) as a cofactor and have an annotated calcium-binding site - two distinct annotation types (a stated cofactor requirement vs. an explicit structural binding-site position) corroborating each other for the same ion. Both sides are matched by the actual ChEBI identity of calcium(2+) (CHEBI:29108), not by name text: up:cofactor points directly at the ChEBI IRI, while a binding site's up:ligand is an instance further typed via rdfs:subClassOf to the ChEBI class