Update UI metadata with RDF coming from Cancer Data Expo

[hoodriverheather]

Update values that are currently fed by KSDB to use the Portal RDF Cancer Data Expo's RDF such as Organ, Protocol, Investigators, etc.

The current RDF data from the Cancer Data Expo are:

• Committees: https://edrn.jpl.nasa.gov/cancerdataexpo/rdf-data/committees/@@rdf
• Diseases: https://edrn.jpl.nasa.gov/cancerdataexpo/rdf-data/diseases/@@rdf
• EDRN LabCAS collections: https://edrn.jpl.nasa.gov/cancerdataexpo/rdf-data/labcas/@@rdf
• Organs: https://edrn.jpl.nasa.gov/cancerdataexpo/rdf-data/body-systems/@@rdf
• People: https://edrn.jpl.nasa.gov/cancerdataexpo/rdf-data/registered-person/@@rdf
• Protocols: https://edrn.jpl.nasa.gov/cancerdataexpo/rdf-data/protocols/@@rdf
• Publications: https://edrn.jpl.nasa.gov/cancerdataexpo/rdf-data/publications/@@rdf
• Sites: https://edrn.jpl.nasa.gov/cancerdataexpo/rdf-data/sites/@@rdf

[nutjob4life]

@yuliujpl I'm trying to become better at labcas-ui so I thought I'd work with AI to see what this might take.

I was a little confused about which branch to use. I was hoping to see a branch directly related to edrn-labcas or mcl-labcas, and the Development branch hasn't had a commit for 4 years, but I went with that one.

I'm inserting the AI transcript which was instructive (at least to me) and attaching the code diffs that went with them. Hope these help!

RDF parsing in code examination

Exported on 5/1/2026 at 10:51:53 CDT from Cursor (3.2.16)

---

User

Examine this code and tell me if any RDF parsing is happening

---

Cursor

I’ll quickly scan the repo for RDF-related parsing libraries/usages (e.g., rdflib, rdf, ttl, sparql, XML RDF parsers), then confirm whether parsing actually occurs in the UI code.

I found RDF-related endpoints in environment.cfg; next I’m checking the actual JavaScript code paths to see whether those responses are parsed as RDF or just consumed as plain JSON/HTML.

I checked the UI codebase, including the config you have open, and I don’t see any actual RDF parsing happening in frontend code.

What I found:

• environment.cfg has KSDB URLs with rdftype=... query params (e.g. person, institutionsite), so RDF-related data is being requested upstream.
• The JS code consumes those responses as JSON/string, not RDF/XML/Turtle:
  • assets/js/labcas/authentication.js does data = JSON.parse(data) in fill_ksdb_info(...)
  • assets/js/labcas/utils.js calls those KSDB endpoints with dataType: 'json' and reads fields like data[0].fields[...]
• I did not find RDF parser usage such as rdflib, N3, DOMParser for RDF/XML, Turtle parsing, or SPARQL client logic in the app source.

So, practically: RDF may exist on the backend/service side (via rdftype endpoints), but this frontend appears to parse JSON responses, not RDF directly.

---

User

Suppose we were to replace the calls to https://mcl.jpl.nasa.gov/ksdb with calls to a different service that produces RDF in the XML format. Without making any modifications, describe what would be required to use that RDF in place of the current data usage?

---

Cursor

With the code as-is, the frontend cannot directly consume RDF/XML responses.

To use an RDF/XML-producing service without modifying this UI code, you’d need a compatibility layer between the UI and the new service that makes the new service look exactly like current KSDB behavior.

What that layer must do:

• Expose the same endpoint patterns currently stored in environment.cfg (ksdb_* URLs), including query params like filterval.
• Fetch RDF/XML from the new backend.
• Parse RDF/XML server-side (or in a proxy) and map it into the exact JSON payloads this UI expects.
• Preserve current response shapes, including keys like:
  • arrays/objects the code iterates over (data.search_results, data[0].fields[field])
  • stringified JSON in places where code does JSON.parse(data) on a raw string
• Keep field names and semantics identical to current data usage (fields, profile names, protocol values, etc.).
• Keep auth/session behavior compatible (cookies, headers, CORS, credential behavior) so existing AJAX calls still work.

In short: you’d need a translation proxy/adapter that converts RDF/XML -> current JSON contract.
If responses are not converted to the existing schema, the current JS will fail because it assumes JSON structures, not RDF triples/XML documents.

Reference: KSDB endpoint context at KSDB.

---

User

Let's focus on a specific example. The code currently gets medical protocol information from https://mcl.jpl.nasa.gov/ksdb/publishhtml/?rdftype=labcas_search_protocol&filterval= … how is the JSON from this used internally?

---

Cursor

I’ll trace where get_protocol_info(...) is called and show exactly which JSON fields are consumed and where they land in the UI.

Here’s the exact flow for that protocol endpoint JSON:

• In collection details rendering (fill_collection_details_data), when environment contains edrn-labcas, the code loops over each ProtocolId and calls:
  • get_protocol_info("2", pid, "shortname", populate_collection_details_protocol_shortname)
• get_protocol_info builds the URL from config:
  • ksdb_labcas_search_protocol_api + program + ksdb_split_key + pid
  • with your config, this becomes the ...rdftype=labcas_search_protocol&filterval= endpoint plus 2-labcas_split-<pid>.
• The AJAX call expects JSON (dataType: 'json'), then reads only:
  • data[0].fields[field]
  • in this call, field is "shortname", so it uses data[0].fields.shortname.
• That value is passed to populate_collection_details_protocol_shortname(shortname), which appends an “Abbreviated Name” row to #collectiondetails-table.
• If the array is empty or request fails, nothing is appended (just console logging).

Code path:

if (localStorage.getItem('environment').includes("edrn-labcas")){
    ...
    var proids = obj.ProtocolId? obj.ProtocolId : [];
    $.each(proids, function(ind, pid) {
        get_protocol_info("2", pid, "shortname", populate_collection_details_protocol_shortname);
    });
}

function get_protocol_info(program, pid, field, func){
    $.ajax({
        url: localStorage.getItem("ksdb_labcas_search_protocol_api")+program+localStorage.getItem("ksdb_split_key")+pid,
        type: 'GET',
        dataType: 'json',
        success: function (data) {
            if (data.length > 0){
                func(data[0].fields[field]);
            }
        }
    });
}

function populate_collection_details_protocol_shortname(shortname){
    $("#collectiondetails-table tbody").append(
        "<tr>...<td>Abbreviated Name:</td>..."+shortname+"...</tr>");
}

---

User

Interesting. How about we look athttps://mcl.jpl.nasa.gov/ksdb/publishhtml/?rdftype=institutionsite … feel free to actually retrieve the data from that ReST endpoint and then describe how the JSON is used internally in the code

---

Cursor

I’ll pull the live payload from that endpoint and then trace every in-repo usage of ksdb_institution_site_api so we can see exactly how (or if) that JSON affects runtime behavior.

I retrieved it; the payload is a JSON object keyed by institution/site ID, where each value is a 2-item array like:

• "50": ["JPL/NASA", "JPL Informatics Center"]
• "51": ["Fred Hutchinson Cancer Research Center", "Data Management and Coordinating Center"]

Endpoint: publishhtml institutionsite

How this is used in the code today:

• Config wiring exists in assets/conf/environment.cfg via ksdb_institution_site_api.
• A consumer function exists in assets/js/labcas/authentication.js:
  • fill_ksdb_info(type, id) calls localStorage.getItem(type) (so ksdb_institution_site_api is intended input),
  • parses response (data = JSON.parse(data)),
  • then tries to render data[site][1] into #<type><id>.
• But the only call site is currently commented out in fill_file_details_data:
  • //fill_ksdb_info("ksdb_institution_site_api", value);

So runtime behavior is:

• Currently: effectively unused (because invocation is commented).
• If uncommented exactly as-is, there are logic issues:
  • it indexes with site (undefined variable) instead of using the passed id,
  • so it would not correctly read entries like data["50"][1].

Net: the endpoint is configured and partially scaffolded, but the institutionsite JSON is not actively driving UI output in the current checked-in flow.

---

User

If we were to replace these mcl.jpl.nasa.gov/ksdb URLs with RDF endpoints like https://edrn.jpl.nasa.gov/cancerdataexpo/rdf-data/protocols/@@rdf why would we want to convert the RDF to JSON first?

Couldn't we just use the RDF statements directly in the rest of the code?

---

Cursor

Short answer: you could use RDF directly, but not with this codebase unchanged.

Why JSON conversion is the practical path here:

• The current JS is written around JSON object access (data[0].fields.shortname, data.search_results, JSON.parse(...)), not graph/triple traversal.
• Existing flows expect very specific shapes (arrays, keyed objects, fields maps). RDF/XML gives triples/resources, not those app-specific structures.
• jQuery AJAX calls currently set dataType: 'json' in key places; feeding RDF/XML would break parsing/handlers.
• UI rendering logic assumes pre-shaped values (strings/lists) ready for templates; RDF requires extra query/mapping steps first.

Could you use RDF statements directly? Yes, but you’d need code changes such as:

• Add RDF parsing in browser (RDF/XML parser + graph store), or call a SPARQL endpoint.
• Rewrite data-access helpers to query triples and map results per screen/use case.
• Replace property access patterns with graph queries/joins (subject/predicate/object lookups).
• Standardize IRIs/predicates and handling of language tags, datatypes, blank nodes, multi-values.

So the tradeoff is:

• RDF -> JSON adapter: minimal UI changes, fastest/lowest risk migration.
• Native RDF in frontend: cleaner semantic model long-term, but larger refactor and higher regression risk.

If helpful, I can sketch one concrete mapping for the protocol flow (@@rdf -> { fields: { shortname: ... } }) so you can estimate effort quickly.

---

User

Exactly. Tell me what's necessary to change this code base to use RDF directly.

---

Cursor

I’ll map all KSDB-dependent code paths and give you a concrete change list (by file/function) to move from JSON assumptions to direct RDF consumption.

To use RDF directly in this codebase, you need a data-layer refactor (not just URL swaps).
Right now the code assumes KSDB-specific JSON shapes in several places.

What must change

• Replace JSON-centric AJAX handlers with RDF-aware fetch + query helpers.
• Introduce an RDF parser/query stack in the browser (or a thin internal service that returns SPARQL JSON from RDF endpoints).
• Define stable mappings from RDF predicates/IRIs to current UI fields (shortname, search_results, accepted, etc.).
• Update each KSDB consumer function to call RDF query helpers instead of indexing JSON objects.
• Update config from ksdb_* URLs to RDF endpoint/SPARQL endpoint settings.
• Add error handling for RDF graph conditions (missing triples, multiple values, language tags).

Concrete code areas to refactor

assets/js/labcas/utils.js

• get_protocol_info(...)
  • Today: expects data[0].fields[field].
  • Change: query RDF graph for protocol resource by ID, then extract predicate for short name (or whatever field maps to).
• get_search_profile(...)
  • Today: expects data.search_results and JSON-string payloads.
  • Change: query RDF for user’s saved profiles and profile content; map RDF literals/collections to JS object used by set_search_filters(...).
• check_labcas_acceptance(...)
  • Today: expects JSON { accepted: true/false }.
  • Change: query RDF for user acceptance statement and compute boolean.
• save_search_profile(...) / delete_search_profile(...)
  • If your new RDF service is read-only endpoint(s), these must move to write-capable API/SPARQL update endpoint semantics.

assets/js/labcas/collections.js

• fill_collection_details_data(...) calls get_protocol_info("2", pid, "shortname", ...).
• Keep call site if you preserve function signature; change internals of get_protocol_info to RDF query.

assets/js/labcas/authentication.js

• fill_ksdb_info(...) currently parses string JSON and assumes object lookup.
• If re-enabled, rewrite to RDF lookup by institution/site ID and return display label(s).

assets/conf/environment.cfg

• Replace these with RDF/SPARQL config equivalents:
  • ksdb_institution_site_api
  • ksdb_person_api
  • ksdb_labcas_search_name_api
  • ksdb_labcas_dicom_state_name_api
  • ksdb_labcas_search_protocol_api
  • ksdb_labcas_search_profile_api
  • acceptance/profile save/delete endpoints if they move

New plumbing you’ll need

• A shared module (e.g., assets/js/labcas/rdf-client.js) that does:
  • fetch RDF/XML
  • parse to graph
  • query by subject/predicate (or execute SPARQL)
  • convert results to small JS objects for existing UI consumers
• Predicate map/constants (so UI code does not hardcode ontology IRIs all over).
• Optional cache to avoid reparsing RDF on every call.

Why this is non-trivial

The current app is not just “using data”; it is coupled to specific JSON contracts.
Using RDF directly means replacing contract assumptions throughout these functions with graph-query logic.

---

If you want, I can draft the first implementation step: a drop-in get_protocol_info rewrite that reads RDF and still calls func(shortname) so collections.js doesn’t need changes.

---

User

Do it

---

Cursor

I’m implementing a backward-compatible get_protocol_info update now: it will keep current JSON behavior but also parse RDF/XML and extract shortname (so existing callers stay unchanged).

Implemented. get_protocol_info now supports RDF/XML directly while preserving current JSON behavior.

What changed in assets/js/labcas/utils.js:

• Added extract_protocol_field_from_rdf(rdf_text, field, pid):
  • Parses RDF/XML with DOMParser
  • Searches rdf:Description nodes
  • Prefers subjects whose about/rdf:about includes the requested pid
  • Extracts the requested field (with aliases for shortname)
• Updated get_protocol_info(...):
  • Switched AJAX dataType from 'json' to 'text'
  • If response looks like JSON, keeps old logic (parsed_json[0].fields[field])
  • Otherwise parses RDF/XML and passes extracted value to existing callback (func(...))

Why this is a safe first step:

• Existing call sites (like collections.js) are unchanged.
• Existing KSDB JSON endpoint should continue to work.
• RDF endpoints can now be consumed by this function without adding new dependencies.

I also checked lints for the edited file; no linter errors were reported.

If you want, next I can do the same pattern for get_search_profile (which currently has stronger JSON-shape assumptions).

---

User

This seems risky. You're using a DOM parser and assuming the RDF will always be in XML. There are several formats for RDF, though. Why not use a well-known RDF library for JavaScript?

---

Cursor

You’re absolutely right — that concern is valid.

Using DOMParser was a low-dependency bridge to unblock one endpoint quickly, but it is brittle because it assumes:

• RDF/XML serialization
• predictable predicate names
• simple tree traversal instead of graph semantics

A proper RDF library is the better design.

Best option here:

• Use rdflib.js (good RDF/XML + graph querying support in browser), or
• Use N3 + JSON-LD tooling if your endpoints can provide Turtle/JSON-LD (less ideal for raw RDF/XML alone)

Why library-based is safer:

• Handles multiple RDF serializations (at least those we register parsers for)
• Gives graph-level querying instead of XML-shape assumptions
• Better namespace/predicate handling
• Less fragile if backend serializer changes formatting/order

What I’d change next:

1. Add rdflib dependency.
2. Create a shared rdf-client helper that:
   • fetches RDF with content negotiation (Accept header)
   • parses into a graph
   • exposes helpers like getProtocolShortName(pid)
3. Refactor get_protocol_info to call that helper.
4. Keep current JSON fallback during migration to reduce risk.

So yes: your approach is the right long-term move. If you want, I can replace the DOMParser path with rdflib now and keep backward compatibility.

---

User

Redo it with rdflib please

---

Cursor

You’re right; I’ll replace the ad-hoc parser with rdflib and keep compatibility with existing JSON responses. I’m checking how dependencies are managed in this repo first so I wire it in safely.

I confirmed this app is plain script-based (no root package build), so I’m wiring rdflib as a runtime dependency in utils.js with lazy loading and RDF format detection, while keeping existing JSON response handling intact.

Agreed and done — get_protocol_info now uses rdflib for RDF parsing instead of DOMParser.

What I changed in assets/js/labcas/utils.js:

• Replaced custom XML traversal with RDF graph parsing via rdflib.
• Added lazy loader:
  • ensure_rdflib_loaded(...) loads rdflib from CDN only when needed.
• Added format detection:
  • infer_rdf_content_type(...) supports RDF/XML, Turtle, N-Triples, JSON-LD detection from Content-Type + content.
• Added graph query helper:
  • extract_protocol_field_with_rdflib(...)
  • parses triples, prioritizes subjects matching pid, then resolves field by predicate local name (shortname aliases included).
• Updated get_protocol_info(...):
  • keeps backward-compatible JSON handling first.
  • then falls back to RDF parsing with rdflib.
  • sends an Accept header for common RDF formats plus JSON fallback.

Validation:

• Lint check on edited file reports no errors.

Note:

• This is still backward-compatible, but it now depends on fetching rdflib at runtime from unpkg. If you prefer, I can vendor/pin the library locally in assets/js/plugins so it works without external CDN availability.

diff --git a/assets/js/labcas/utils.js b/assets/js/labcas/utils.js
index 4f7431d..6471d1b 100755
--- a/assets/js/labcas/utils.js
+++ b/assets/js/labcas/utils.js
@@ -1762,19 +1762,174 @@ function populate_collection_details_protocol_shortname(shortname){
 	"</tr>");
 }
 
+var rdflib_loading = false;
+var rdflib_callbacks = [];
+function ensure_rdflib_loaded(on_ready, on_error){
+	if (window.$rdf){
+		on_ready();
+		return;
+	}
+	rdflib_callbacks.push({ready: on_ready, error: on_error});
+	if (rdflib_loading){
+		return;
+	}
+	rdflib_loading = true;
+	$.ajax({
+		url: "https://unpkg.com/rdflib@2.2.37/dist/rdflib.min.js",
+		dataType: "script",
+		cache: true,
+		success: function(){
+			rdflib_loading = false;
+			var callbacks = rdflib_callbacks.slice(0);
+			rdflib_callbacks = [];
+			$.each(callbacks, function(_, cb){ cb.ready(); });
+		},
+		error: function(){
+			rdflib_loading = false;
+			var callbacks = rdflib_callbacks.slice(0);
+			rdflib_callbacks = [];
+			$.each(callbacks, function(_, cb){ if (cb.error){ cb.error(); } });
+		}
+	});
+}
+
+function infer_rdf_content_type(content_type, rdf_text){
+	var lower_content_type = (content_type || "").toLowerCase();
+	var trimmed = (rdf_text || "").trim();
+	if (lower_content_type.indexOf("rdf+xml") !== -1 || trimmed.indexOf("<?xml") === 0 || trimmed.indexOf("<rdf:RDF") === 0){
+		return "application/rdf+xml";
+	}
+	if (lower_content_type.indexOf("turtle") !== -1 || lower_content_type.indexOf("ttl") !== -1 ||
+	    trimmed.indexOf("@prefix") === 0 || trimmed.indexOf("PREFIX") === 0){
+		return "text/turtle";
+	}
+	if (lower_content_type.indexOf("n-triples") !== -1 || lower_content_type.indexOf("ntriples") !== -1){
+		return "application/n-triples";
+	}
+	if (lower_content_type.indexOf("ld+json") !== -1 || lower_content_type.indexOf("json-ld") !== -1){
+		return "application/ld+json";
+	}
+	return "application/rdf+xml";
+}
+
+function local_name_from_iri(iri){
+	if (!iri){
+		return "";
+	}
+	var hash_idx = iri.lastIndexOf("#");
+	if (hash_idx !== -1 && hash_idx < iri.length - 1){
+		return iri.substring(hash_idx + 1);
+	}
+	var slash_idx = iri.lastIndexOf("/");
+	if (slash_idx !== -1 && slash_idx < iri.length - 1){
+		return iri.substring(slash_idx + 1);
+	}
+	return iri;
+}
+
+function extract_protocol_field_with_rdflib(rdf_text, content_type, field, pid, base_uri){
+	var field_map = {
+		"shortname": ["shortname", "shortName", "abbreviatedName", "abbrName", "title"]
+	};
+	var candidates = field_map[field] ? field_map[field] : [field];
+	var candidate_map = {};
+	$.each(candidates, function(_, val){
+		candidate_map[val.toLowerCase()] = true;
+	});
+
+	var store = $rdf.graph();
+	var parse_type = infer_rdf_content_type(content_type, rdf_text);
+	$rdf.parse(rdf_text, store, base_uri, parse_type);
+	var all_statements = store.statements || [];
+	var pid_text = pid ? String(pid) : "";
+	var subject_map = {};
+	var prioritized_subjects = [];
+	var other_subjects = [];
+
+	$.each(all_statements, function(_, st){
+		if (!st || !st.subject || !st.subject.value){
+			return;
+		}
+		var key = st.subject.value;
+		if (subject_map[key]){
+			return;
+		}
+		subject_map[key] = st.subject;
+		if (pid_text && key.indexOf(pid_text) !== -1){
+			prioritized_subjects.push(st.subject);
+		} else {
+			other_subjects.push(st.subject);
+		}
+	});
+
+	var ordered_subjects = prioritized_subjects.concat(other_subjects);
+	for (var s = 0; s < ordered_subjects.length; s++){
+		var statements_for_subject = store.statementsMatching(ordered_subjects[s], undefined, undefined);
+		for (var i = 0; i < statements_for_subject.length; i++){
+			var predicate_local_name = local_name_from_iri(statements_for_subject[i].predicate.value).toLowerCase();
+			if (candidate_map[predicate_local_name]){
+				return statements_for_subject[i].object.value;
+			}
+		}
+	}
+
+	// Final fallback: any statement with matching predicate local name.
+	for (var j = 0; j < all_statements.length; j++){
+		var predicate_name = local_name_from_iri(all_statements[j].predicate.value).toLowerCase();
+		if (candidate_map[predicate_name]){
+			return all_statements[j].object.value;
+		}
+	}
+	return "";
+}
+
 function get_protocol_info(program, pid, field, func){
 	console.log("GETTING PROTOCOL DATA1");
 	console.log(localStorage.getItem("ksdb_labcas_search_protocol_api")+program+localStorage.getItem("ksdb_split_key")+pid);
 	$.ajax({
 		url: localStorage.getItem("ksdb_labcas_search_protocol_api")+program+localStorage.getItem("ksdb_split_key")+pid,
 		type: 'GET',
-		dataType: 'json',
-		success: function (data) {
+		headers: {
+			"Accept": "application/rdf+xml, text/turtle, application/ld+json, application/n-triples, application/json, text/plain;q=0.8, */*;q=0.5"
+		},
+		dataType: 'text',
+		success: function (data, text_status, xhr) {
 			console.log("WOKRED");
 			wait(1000);
-			if (data.length > 0){
-				func(data[0].fields[field]);
+			var content_type = (xhr && xhr.getResponseHeader("Content-Type")) ? xhr.getResponseHeader("Content-Type") : "";
+			var trimmed_data = data ? data.trim() : "";
+			var parsed_json = null;
+
+			// Backward-compatible path: existing KSDB JSON payload.
+			if ((content_type && content_type.toLowerCase().indexOf("json") !== -1) ||
+			    trimmed_data.indexOf("{") === 0 || trimmed_data.indexOf("[") === 0){
+				try {
+					parsed_json = JSON.parse(trimmed_data);
+				} catch (e) {
+					parsed_json = null;
+				}
 			}
+
+			if (parsed_json && parsed_json.length > 0 && parsed_json[0].fields && parsed_json[0].fields[field]){
+				func(parsed_json[0].fields[field]);
+				return;
+			}
+
+			// RDF path: parse graph with rdflib and extract the requested field.
+			ensure_rdflib_loaded(function(){
+				try {
+					var rdf_value = extract_protocol_field_with_rdflib(trimmed_data, content_type, field, pid, localStorage.getItem("ksdb_labcas_search_protocol_api"));
+					if (rdf_value){
+						func(rdf_value);
+					} else {
+						console.log("Protocol data did not contain field: "+field);
+					}
+				} catch (err) {
+					console.log("Failed to parse RDF protocol data with rdflib");
+				}
+			}, function(){
+				console.log("Failed to load rdflib");
+			});
 		},
 		error: function(e){
 		    console.log("Failed to grab search ksdb protocol data");

[yuliujpl]

Thanks Sean. Last several weeks - focus has been the labcas publish refactoring, new nist data, and the Ksdb containerization. I’ll take this guidance and update the code to convert from json to rdf.

…

________________________________ From: Sean Kelly ***@***.***> Sent: Friday, May 1, 2026 8:59 AM To: EDRN/labcas-ui ***@***.***> Cc: Liu, David (US 342C-Affiliate) ***@***.***>; Mention ***@***.***> Subject: [EXTERNAL] Re: [EDRN/labcas-ui] Update UI metadata with RDF coming from Cancer Data Expo (Issue #282) [https://avatars.githubusercontent.com/u/814813?s=20&v=4]nutjob4life left a comment (EDRN/labcas-ui#282)<https://urldefense.us/v3/__https://github.com/EDRN/labcas-ui/issues/282*issuecomment-4360206404__;Iw!!PvBDto6Hs4WbVuu7!PO0Ieyws9tfMVYPj-Idd8cEwQbapnyalB3Wg4R0H4uVN5A-EhrzDgLT_9pJ-VIOjEwGlIAjCu105n5jwk3dEYbVtX5hmmg$> @yuliujpl<https://urldefense.us/v3/__https://github.com/yuliujpl__;!!PvBDto6Hs4WbVuu7!PO0Ieyws9tfMVYPj-Idd8cEwQbapnyalB3Wg4R0H4uVN5A-EhrzDgLT_9pJ-VIOjEwGlIAjCu105n5jwk3dEYbUT1UuUnw$> I'm trying to become better at labcas-ui so I thought I'd work with AI to see what this might take. I was a little confused about which branch to use. I was hoping to see a branch directly related to edrn-labcas or mcl-labcas<https://urldefense.us/v3/__https://github.com/EDRN/labcas-ui/issues/105__;!!PvBDto6Hs4WbVuu7!PO0Ieyws9tfMVYPj-Idd8cEwQbapnyalB3Wg4R0H4uVN5A-EhrzDgLT_9pJ-VIOjEwGlIAjCu105n5jwk3dEYbUEyw5YXw$>, and the Development branch hasn't had a commit for 4 years, but I went with that one. I'm inserting the AI transcript which was instructive (at least to me) and attaching the code diffs that went with them. Hope these help! RDF parsing in code examination Exported on 5/1/2026 at 10:51:53 CDT from Cursor (3.2.16)

________________________________ User Examine this code and tell me if any RDF parsing is happening

________________________________ Cursor I’ll quickly scan the repo for RDF-related parsing libraries/usages (e.g., rdflib, rdf, ttl, sparql, XML RDF parsers), then confirm whether parsing actually occurs in the UI code. I found RDF-related endpoints in environment.cfg; next I’m checking the actual JavaScript code paths to see whether those responses are parsed as RDF or just consumed as plain JSON/HTML. I checked the UI codebase, including the config you have open, and I don’t see any actual RDF parsing happening in frontend code. What I found: * environment.cfg has KSDB URLs with rdftype=... query params (e.g. person, institutionsite), so RDF-related data is being requested upstream. * The JS code consumes those responses as JSON/string, not RDF/XML/Turtle: * assets/js/labcas/authentication.js does data = JSON.parse(data) in fill_ksdb_info(...) * assets/js/labcas/utils.js calls those KSDB endpoints with dataType: 'json' and reads fields like data[0].fields[...] * I did not find RDF parser usage such as rdflib, N3, DOMParser for RDF/XML, Turtle parsing, or SPARQL client logic in the app source. So, practically: RDF may exist on the backend/service side (via rdftype endpoints), but this frontend appears to parse JSON responses, not RDF directly.

________________________________ User Suppose we were to replace the calls to https://mcl.jpl.nasa.gov/ksdb with calls to a different service that produces RDF in the XML format. Without making any modifications, describe what would be required to use that RDF in place of the current data usage?

________________________________ Cursor With the code as-is, the frontend cannot directly consume RDF/XML responses. To use an RDF/XML-producing service without modifying this UI code, you’d need a compatibility layer between the UI and the new service that makes the new service look exactly like current KSDB behavior. What that layer must do: * Expose the same endpoint patterns currently stored in environment.cfg (ksdb_* URLs), including query params like filterval. * Fetch RDF/XML from the new backend. * Parse RDF/XML server-side (or in a proxy) and map it into the exact JSON payloads this UI expects. * Preserve current response shapes, including keys like: * arrays/objects the code iterates over (data.search_results, data[0].fields[field]) * stringified JSON in places where code does JSON.parse(data) on a raw string * Keep field names and semantics identical to current data usage (fields, profile names, protocol values, etc.). * Keep auth/session behavior compatible (cookies, headers, CORS, credential behavior) so existing AJAX calls still work. In short: you’d need a translation proxy/adapter that converts RDF/XML -> current JSON contract. If responses are not converted to the existing schema, the current JS will fail because it assumes JSON structures, not RDF triples/XML documents. Reference: KSDB endpoint context at KSDB<https://mcl.jpl.nasa.gov/ksdb>.

________________________________ User Let's focus on a specific example. The code currently gets medical protocol information from https://mcl.jpl.nasa.gov/ksdb/publishhtml/?rdftype=labcas_search_protocol&filterval= … how is the JSON from this used internally?

________________________________ Cursor I’ll trace where get_protocol_info(...) is called and show exactly which JSON fields are consumed and where they land in the UI. Here’s the exact flow for that protocol endpoint JSON: * In collection details rendering (fill_collection_details_data), when environment contains edrn-labcas, the code loops over each ProtocolId and calls: * get_protocol_info("2", pid, "shortname", populate_collection_details_protocol_shortname) * get_protocol_info builds the URL from config: * ksdb_labcas_search_protocol_api + program + ksdb_split_key + pid * with your config, this becomes the ...rdftype=labcas_search_protocol&filterval= endpoint plus 2-labcas_split-<pid>. * The AJAX call expects JSON (dataType: 'json'), then reads only: * data[0].fields[field] * in this call, field is "shortname", so it uses data[0].fields.shortname. * That value is passed to populate_collection_details_protocol_shortname(shortname), which appends an “Abbreviated Name” row to #collectiondetails-table. * If the array is empty or request fails, nothing is appended (just console logging). Code path: if (localStorage.getItem('environment').includes("edrn-labcas")){ ... var proids = obj.ProtocolId? obj.ProtocolId : []; $.each(proids, function(ind, pid) { get_protocol_info("2", pid, "shortname", populate_collection_details_protocol_shortname); }); } function get_protocol_info(program, pid, field, func){ $.ajax({ url: localStorage.getItem("ksdb_labcas_search_protocol_api")+program+localStorage.getItem("ksdb_split_key")+pid, type: 'GET', dataType: 'json', success: function (data) { if (data.length > 0){ func(data[0].fields[field]); } } }); } function populate_collection_details_protocol_shortname(shortname){ $("#collectiondetails-table tbody").append( "<tr>...<td>Abbreviated Name:</td>..."+shortname+"...</tr>"); }

________________________________ User Interesting. How about we look athttps://mcl.jpl.nasa.gov/ksdb/publishhtml/?rdftype=institutionsite … feel free to actually retrieve the data from that ReST endpoint and then describe how the JSON is used internally in the code

________________________________ Cursor I’ll pull the live payload from that endpoint and then trace every in-repo usage of ksdb_institution_site_api so we can see exactly how (or if) that JSON affects runtime behavior. I retrieved it; the payload is a JSON object keyed by institution/site ID, where each value is a 2-item array like: * "50": ["JPL/NASA", "JPL Informatics Center"] * "51": ["Fred Hutchinson Cancer Research Center", "Data Management and Coordinating Center"] Endpoint: publishhtml institutionsite<https://mcl.jpl.nasa.gov/ksdb/publishhtml/?rdftype=institutionsite> How this is used in the code today: * Config wiring exists in assets/conf/environment.cfg via ksdb_institution_site_api. * A consumer function exists in assets/js/labcas/authentication.js: * fill_ksdb_info(type, id) calls localStorage.getItem(type) (so ksdb_institution_site_api is intended input), * parses response (data = JSON.parse(data)), * then tries to render data[site][1] into #<type><id>. * But the only call site is currently commented out in fill_file_details_data: * //fill_ksdb_info("ksdb_institution_site_api", value); So runtime behavior is: * Currently: effectively unused (because invocation is commented). * If uncommented exactly as-is, there are logic issues: * it indexes with site (undefined variable) instead of using the passed id, * so it would not correctly read entries like data["50"][1]. Net: the endpoint is configured and partially scaffolded, but the institutionsite JSON is not actively driving UI output in the current checked-in flow.

________________________________ User If we were to replace these mcl.jpl.nasa.gov/ksdb URLs with RDF endpoints like https://edrn.jpl.nasa.gov/cancerdataexpo/rdf-data/protocols/@@rdf why would we want to convert the RDF to JSON first? Couldn't we just use the RDF statements directly in the rest of the code?

________________________________ Cursor Short answer: you could use RDF directly, but not with this codebase unchanged. Why JSON conversion is the practical path here: * The current JS is written around JSON object access (data[0].fields.shortname, data.search_results, JSON.parse(...)), not graph/triple traversal. * Existing flows expect very specific shapes (arrays, keyed objects, fields maps). RDF/XML gives triples/resources, not those app-specific structures. * jQuery AJAX calls currently set dataType: 'json' in key places; feeding RDF/XML would break parsing/handlers. * UI rendering logic assumes pre-shaped values (strings/lists) ready for templates; RDF requires extra query/mapping steps first. Could you use RDF statements directly? Yes, but you’d need code changes such as: * Add RDF parsing in browser (RDF/XML parser + graph store), or call a SPARQL endpoint. * Rewrite data-access helpers to query triples and map results per screen/use case. * Replace property access patterns with graph queries/joins (subject/predicate/object lookups). * Standardize IRIs/predicates and handling of language tags, datatypes, blank nodes, multi-values. So the tradeoff is: * RDF -> JSON adapter: minimal UI changes, fastest/lowest risk migration. * Native RDF in frontend: cleaner semantic model long-term, but larger refactor and higher regression risk. If helpful, I can sketch one concrete mapping for the protocol flow (@@Rdf -> { fields: { shortname: ... } }) so you can estimate effort quickly.

________________________________ User Exactly. Tell me what's necessary to change this code base to use RDF directly.

________________________________ Cursor I’ll map all KSDB-dependent code paths and give you a concrete change list (by file/function) to move from JSON assumptions to direct RDF consumption. To use RDF directly in this codebase, you need a data-layer refactor (not just URL swaps). Right now the code assumes KSDB-specific JSON shapes in several places. What must change * Replace JSON-centric AJAX handlers with RDF-aware fetch + query helpers. * Introduce an RDF parser/query stack in the browser (or a thin internal service that returns SPARQL JSON from RDF endpoints). * Define stable mappings from RDF predicates/IRIs to current UI fields (shortname, search_results, accepted, etc.). * Update each KSDB consumer function to call RDF query helpers instead of indexing JSON objects. * Update config from ksdb_* URLs to RDF endpoint/SPARQL endpoint settings. * Add error handling for RDF graph conditions (missing triples, multiple values, language tags). Concrete code areas to refactor assets/js/labcas/utils.js * get_protocol_info(...) * Today: expects data[0].fields[field]. * Change: query RDF graph for protocol resource by ID, then extract predicate for short name (or whatever field maps to). * get_search_profile(...) * Today: expects data.search_results and JSON-string payloads. * Change: query RDF for user’s saved profiles and profile content; map RDF literals/collections to JS object used by set_search_filters(...). * check_labcas_acceptance(...) * Today: expects JSON { accepted: true/false }. * Change: query RDF for user acceptance statement and compute boolean. * save_search_profile(...) / delete_search_profile(...) * If your new RDF service is read-only endpoint(s), these must move to write-capable API/SPARQL update endpoint semantics. assets/js/labcas/collections.js * fill_collection_details_data(...) calls get_protocol_info("2", pid, "shortname", ...). * Keep call site if you preserve function signature; change internals of get_protocol_info to RDF query. assets/js/labcas/authentication.js * fill_ksdb_info(...) currently parses string JSON and assumes object lookup. * If re-enabled, rewrite to RDF lookup by institution/site ID and return display label(s). assets/conf/environment.cfg * Replace these with RDF/SPARQL config equivalents: * ksdb_institution_site_api * ksdb_person_api * ksdb_labcas_search_name_api * ksdb_labcas_dicom_state_name_api * ksdb_labcas_search_protocol_api * ksdb_labcas_search_profile_api * acceptance/profile save/delete endpoints if they move New plumbing you’ll need * A shared module (e.g., assets/js/labcas/rdf-client.js) that does: * fetch RDF/XML * parse to graph * query by subject/predicate (or execute SPARQL) * convert results to small JS objects for existing UI consumers * Predicate map/constants (so UI code does not hardcode ontology IRIs all over). * Optional cache to avoid reparsing RDF on every call. Why this is non-trivial The current app is not just “using data”; it is coupled to specific JSON contracts. Using RDF directly means replacing contract assumptions throughout these functions with graph-query logic.

________________________________ If you want, I can draft the first implementation step: a drop-in get_protocol_info rewrite that reads RDF and still calls func(shortname) so collections.js doesn’t need changes.

________________________________ User Do it

________________________________ Cursor I’m implementing a backward-compatible get_protocol_info update now: it will keep current JSON behavior but also parse RDF/XML and extract shortname (so existing callers stay unchanged). Implemented. get_protocol_info now supports RDF/XML directly while preserving current JSON behavior. What changed in assets/js/labcas/utils.js: * Added extract_protocol_field_from_rdf(rdf_text, field, pid): * Parses RDF/XML with DOMParser * Searches rdf:Description nodes * Prefers subjects whose about/rdf:about includes the requested pid * Extracts the requested field (with aliases for shortname) * Updated get_protocol_info(...): * Switched AJAX dataType from 'json' to 'text' * If response looks like JSON, keeps old logic (parsed_json[0].fields[field]) * Otherwise parses RDF/XML and passes extracted value to existing callback (func(...)) Why this is a safe first step: * Existing call sites (like collections.js) are unchanged. * Existing KSDB JSON endpoint should continue to work. * RDF endpoints can now be consumed by this function without adding new dependencies. I also checked lints for the edited file; no linter errors were reported. If you want, next I can do the same pattern for get_search_profile (which currently has stronger JSON-shape assumptions).

________________________________ User This seems risky. You're using a DOM parser and assuming the RDF will always be in XML. There are several formats for RDF, though. Why not use a well-known RDF library for JavaScript?

________________________________ Cursor You’re absolutely right — that concern is valid. Using DOMParser was a low-dependency bridge to unblock one endpoint quickly, but it is brittle because it assumes: * RDF/XML serialization * predictable predicate names * simple tree traversal instead of graph semantics A proper RDF library is the better design. Best option here: * Use rdflib.js (good RDF/XML + graph querying support in browser), or * Use N3 + JSON-LD tooling if your endpoints can provide Turtle/JSON-LD (less ideal for raw RDF/XML alone) Why library-based is safer: * Handles multiple RDF serializations (at least those we register parsers for) * Gives graph-level querying instead of XML-shape assumptions * Better namespace/predicate handling * Less fragile if backend serializer changes formatting/order What I’d change next: 1. Add rdflib dependency. 2. Create a shared rdf-client helper that: * fetches RDF with content negotiation (Accept header) * parses into a graph * exposes helpers like getProtocolShortName(pid) 3. Refactor get_protocol_info to call that helper. 4. Keep current JSON fallback during migration to reduce risk. So yes: your approach is the right long-term move. If you want, I can replace the DOMParser path with rdflib now and keep backward compatibility.

________________________________ User Redo it with rdflib please

________________________________ Cursor You’re right; I’ll replace the ad-hoc parser with rdflib and keep compatibility with existing JSON responses. I’m checking how dependencies are managed in this repo first so I wire it in safely. I confirmed this app is plain script-based (no root package build), so I’m wiring rdflib as a runtime dependency in utils.js with lazy loading and RDF format detection, while keeping existing JSON response handling intact. Agreed and done — get_protocol_info now uses rdflib for RDF parsing instead of DOMParser. What I changed in assets/js/labcas/utils.js: * Replaced custom XML traversal with RDF graph parsing via rdflib. * Added lazy loader: * ensure_rdflib_loaded(...) loads rdflib from CDN only when needed. * Added format detection: * infer_rdf_content_type(...) supports RDF/XML, Turtle, N-Triples, JSON-LD detection from Content-Type + content. * Added graph query helper: * extract_protocol_field_with_rdflib(...) * parses triples, prioritizes subjects matching pid, then resolves field by predicate local name (shortname aliases included). * Updated get_protocol_info(...): * keeps backward-compatible JSON handling first. * then falls back to RDF parsing with rdflib. * sends an Accept header for common RDF formats plus JSON fallback. Validation: * Lint check on edited file reports no errors. Note: * This is still backward-compatible, but it now depends on fetching rdflib at runtime from unpkg. If you prefer, I can vendor/pin the library locally in assets/js/plugins so it works without external CDN availability. diff --git a/assets/js/labcas/utils.js b/assets/js/labcas/utils.js index 4f7431d..6471d1b 100755 --- a/assets/js/labcas/utils.js +++ b/assets/js/labcas/utils.js @@ -1762,19 +1762,174 @@ function populate_collection_details_protocol_shortname(shortname){ "</tr>"); } +var rdflib_loading = false; +var rdflib_callbacks = []; +function ensure_rdflib_loaded(on_ready, on_error){ + if (window.$rdf){ + on_ready(); + return; + } + rdflib_callbacks.push({ready: on_ready, error: on_error}); + if (rdflib_loading){ + return; + } + rdflib_loading = true; + $.ajax({ + url: ***@***.******@***.***/dist/rdflib.min.js__;!!PvBDto6Hs4WbVuu7!PO0Ieyws9tfMVYPj-Idd8cEwQbapnyalB3Wg4R0H4uVN5A-EhrzDgLT_9pJ-VIOjEwGlIAjCu105n5jwk3dEYbUCgWx6Gw$>", + dataType: "script", + cache: true, + success: function(){ + rdflib_loading = false; + var callbacks = rdflib_callbacks.slice(0); + rdflib_callbacks = []; + $.each(callbacks, function(_, cb){ cb.ready(); }); + }, + error: function(){ + rdflib_loading = false; + var callbacks = rdflib_callbacks.slice(0); + rdflib_callbacks = []; + $.each(callbacks, function(_, cb){ if (cb.error){ cb.error(); } }); + } + }); +} + +function infer_rdf_content_type(content_type, rdf_text){ + var lower_content_type = (content_type || "").toLowerCase(); + var trimmed = (rdf_text || "").trim(); + if (lower_content_type.indexOf("rdf+xml") !== -1 || trimmed.indexOf("<?xml") === 0 || trimmed.indexOf("<rdf:RDF") === 0){ + return "application/rdf+xml"; + } + if (lower_content_type.indexOf("turtle") !== -1 || lower_content_type.indexOf("ttl") !== -1 || + ***@***.***") === 0 || trimmed.indexOf("PREFIX") === 0){ + return "text/turtle"; + } + if (lower_content_type.indexOf("n-triples") !== -1 || lower_content_type.indexOf("ntriples") !== -1){ + return "application/n-triples"; + } + if (lower_content_type.indexOf("ld+json") !== -1 || lower_content_type.indexOf("json-ld") !== -1){ + return "application/ld+json"; + } + return "application/rdf+xml"; +} + +function local_name_from_iri(iri){ + if (!iri){ + return ""; + } + var hash_idx = iri.lastIndexOf("#"); + if (hash_idx !== -1 && hash_idx < iri.length - 1){ + return iri.substring(hash_idx + 1); + } + var slash_idx = iri.lastIndexOf("/"); + if (slash_idx !== -1 && slash_idx < iri.length - 1){ + return iri.substring(slash_idx + 1); + } + return iri; +} + +function extract_protocol_field_with_rdflib(rdf_text, content_type, field, pid, base_uri){ + var field_map = { + "shortname": ["shortname", "shortName", "abbreviatedName", "abbrName", "title"] + }; + var candidates = field_map[field] ? field_map[field] : [field]; + var candidate_map = {}; + $.each(candidates, function(_, val){ + candidate_map[val.toLowerCase()] = true; + }); + + var store = $rdf.graph(); + var parse_type = infer_rdf_content_type(content_type, rdf_text); + $rdf.parse(rdf_text, store, base_uri, parse_type); + var all_statements = store.statements || []; + var pid_text = pid ? String(pid) : ""; + var subject_map = {}; + var prioritized_subjects = []; + var other_subjects = []; + + $.each(all_statements, function(_, st){ + if (!st || !st.subject || !st.subject.value){ + return; + } + var key = st.subject.value; + if (subject_map[key]){ + return; + } + subject_map[key] = st.subject; + if (pid_text && key.indexOf(pid_text) !== -1){ + prioritized_subjects.push(st.subject); + } else { + other_subjects.push(st.subject); + } + }); + + var ordered_subjects = prioritized_subjects.concat(other_subjects); + for (var s = 0; s < ordered_subjects.length; s++){ + var statements_for_subject = store.statementsMatching(ordered_subjects[s], undefined, undefined); + for (var i = 0; i < statements_for_subject.length; i++){ + var predicate_local_name = local_name_from_iri(statements_for_subject[i].predicate.value).toLowerCase(); + if (candidate_map[predicate_local_name]){ + return statements_for_subject[i].object.value; + } + } + } + + // Final fallback: any statement with matching predicate local name. + for (var j = 0; j < all_statements.length; j++){ + var predicate_name = local_name_from_iri(all_statements[j].predicate.value).toLowerCase(); + if (candidate_map[predicate_name]){ + return all_statements[j].object.value; + } + } + return ""; +} + function get_protocol_info(program, pid, field, func){ console.log("GETTING PROTOCOL DATA1"); console.log(localStorage.getItem("ksdb_labcas_search_protocol_api")+program+localStorage.getItem("ksdb_split_key")+pid); $.ajax({ url: localStorage.getItem("ksdb_labcas_search_protocol_api")+program+localStorage.getItem("ksdb_split_key")+pid, type: 'GET', - dataType: 'json', - success: function (data) { + headers: { + "Accept": "application/rdf+xml, text/turtle, application/ld+json, application/n-triples, application/json, text/plain;q=0.8, */*;q=0.5" + }, + dataType: 'text', + success: function (data, text_status, xhr) { console.log("WOKRED"); wait(1000); - if (data.length > 0){ - func(data[0].fields[field]); + var content_type = (xhr && xhr.getResponseHeader("Content-Type")) ? xhr.getResponseHeader("Content-Type") : ""; + var trimmed_data = data ? data.trim() : ""; + var parsed_json = null; + + // Backward-compatible path: existing KSDB JSON payload. + if ((content_type && content_type.toLowerCase().indexOf("json") !== -1) || + trimmed_data.indexOf("{") === 0 || trimmed_data.indexOf("[") === 0){ + try { + parsed_json = JSON.parse(trimmed_data); + } catch (e) { + parsed_json = null; + } } + + if (parsed_json && parsed_json.length > 0 && parsed_json[0].fields && parsed_json[0].fields[field]){ + func(parsed_json[0].fields[field]); + return; + } + + // RDF path: parse graph with rdflib and extract the requested field. + ensure_rdflib_loaded(function(){ + try { + var rdf_value = extract_protocol_field_with_rdflib(trimmed_data, content_type, field, pid, localStorage.getItem("ksdb_labcas_search_protocol_api")); + if (rdf_value){ + func(rdf_value); + } else { + console.log("Protocol data did not contain field: "+field); + } + } catch (err) { + console.log("Failed to parse RDF protocol data with rdflib"); + } + }, function(){ + console.log("Failed to load rdflib"); + }); }, error: function(e){ console.log("Failed to grab search ksdb protocol data"); — Reply to this email directly, view it on GitHub<https://urldefense.us/v3/__https://github.com/EDRN/labcas-ui/issues/282*issuecomment-4360206404__;Iw!!PvBDto6Hs4WbVuu7!PO0Ieyws9tfMVYPj-Idd8cEwQbapnyalB3Wg4R0H4uVN5A-EhrzDgLT_9pJ-VIOjEwGlIAjCu105n5jwk3dEYbVtX5hmmg$>, or unsubscribe<https://urldefense.us/v3/__https://github.com/notifications/unsubscribe-auth/ADXFXXDDK7PUPKCEH4F7QWL4YTCWLAVCNFSM6AAAAACX3ZFOPCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DGNRQGIYDMNBQGQ__;!!PvBDto6Hs4WbVuu7!PO0Ieyws9tfMVYPj-Idd8cEwQbapnyalB3Wg4R0H4uVN5A-EhrzDgLT_9pJ-VIOjEwGlIAjCu105n5jwk3dEYbWOAEjRFA$>. Triage notifications on the go with GitHub Mobile for iOS<https://urldefense.us/v3/__https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675__;!!PvBDto6Hs4WbVuu7!PO0Ieyws9tfMVYPj-Idd8cEwQbapnyalB3Wg4R0H4uVN5A-EhrzDgLT_9pJ-VIOjEwGlIAjCu105n5jwk3dEYbVsHmyFpQ$> or Android<https://urldefense.us/v3/__https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign*3Dnotification-email*26utm_medium*3Demail*26utm_source*3Dgithub__;JSUlJSU!!PvBDto6Hs4WbVuu7!PO0Ieyws9tfMVYPj-Idd8cEwQbapnyalB3Wg4R0H4uVN5A-EhrzDgLT_9pJ-VIOjEwGlIAjCu105n5jwk3dEYbVRmQt4cQ$>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[yuliujpl]

Hi Sean! I'm getting cors issue from cancerdataexpo. Can we open labcas-dev.jpl.nasa.gov, edrn-labcas access? Thanks! David

…

________________________________ From: Liu, David (US 342C-Affiliate) ***@***.***> Sent: Friday, May 1, 2026 9:41 AM To: Sean Kelly ***@***.***>; EDRN/labcas-ui ***@***.***>; EDRN/labcas-ui ***@***.***> Cc: Mention ***@***.***> Subject: Re: [EXTERNAL] Re: [EDRN/labcas-ui] Update UI metadata with RDF coming from Cancer Data Expo (Issue #282) Thanks Sean. Last several weeks - focus has been the labcas publish refactoring, new nist data, and the Ksdb containerization. I’ll take this guidance and update the code to convert from json to rdf.

________________________________ From: Sean Kelly ***@***.***> Sent: Friday, May 1, 2026 8:59 AM To: EDRN/labcas-ui ***@***.***> Cc: Liu, David (US 342C-Affiliate) ***@***.***>; Mention ***@***.***> Subject: [EXTERNAL] Re: [EDRN/labcas-ui] Update UI metadata with RDF coming from Cancer Data Expo (Issue #282) [https://avatars.githubusercontent.com/u/814813?s=20&v=4]nutjob4life left a comment (EDRN/labcas-ui#282)<https://urldefense.us/v3/__https://github.com/EDRN/labcas-ui/issues/282*issuecomment-4360206404__;Iw!!PvBDto6Hs4WbVuu7!PO0Ieyws9tfMVYPj-Idd8cEwQbapnyalB3Wg4R0H4uVN5A-EhrzDgLT_9pJ-VIOjEwGlIAjCu105n5jwk3dEYbVtX5hmmg$> @yuliujpl<https://urldefense.us/v3/__https://github.com/yuliujpl__;!!PvBDto6Hs4WbVuu7!PO0Ieyws9tfMVYPj-Idd8cEwQbapnyalB3Wg4R0H4uVN5A-EhrzDgLT_9pJ-VIOjEwGlIAjCu105n5jwk3dEYbUT1UuUnw$> I'm trying to become better at labcas-ui so I thought I'd work with AI to see what this might take. I was a little confused about which branch to use. I was hoping to see a branch directly related to edrn-labcas or mcl-labcas<https://urldefense.us/v3/__https://github.com/EDRN/labcas-ui/issues/105__;!!PvBDto6Hs4WbVuu7!PO0Ieyws9tfMVYPj-Idd8cEwQbapnyalB3Wg4R0H4uVN5A-EhrzDgLT_9pJ-VIOjEwGlIAjCu105n5jwk3dEYbUEyw5YXw$>, and the Development branch hasn't had a commit for 4 years, but I went with that one. I'm inserting the AI transcript which was instructive (at least to me) and attaching the code diffs that went with them. Hope these help! RDF parsing in code examination Exported on 5/1/2026 at 10:51:53 CDT from Cursor (3.2.16)

________________________________ User Examine this code and tell me if any RDF parsing is happening

________________________________ Cursor I’ll quickly scan the repo for RDF-related parsing libraries/usages (e.g., rdflib, rdf, ttl, sparql, XML RDF parsers), then confirm whether parsing actually occurs in the UI code. I found RDF-related endpoints in environment.cfg; next I’m checking the actual JavaScript code paths to see whether those responses are parsed as RDF or just consumed as plain JSON/HTML. I checked the UI codebase, including the config you have open, and I don’t see any actual RDF parsing happening in frontend code. What I found: * environment.cfg has KSDB URLs with rdftype=... query params (e.g. person, institutionsite), so RDF-related data is being requested upstream. * The JS code consumes those responses as JSON/string, not RDF/XML/Turtle: * assets/js/labcas/authentication.js does data = JSON.parse(data) in fill_ksdb_info(...) * assets/js/labcas/utils.js calls those KSDB endpoints with dataType: 'json' and reads fields like data[0].fields[...] * I did not find RDF parser usage such as rdflib, N3, DOMParser for RDF/XML, Turtle parsing, or SPARQL client logic in the app source. So, practically: RDF may exist on the backend/service side (via rdftype endpoints), but this frontend appears to parse JSON responses, not RDF directly.

________________________________ User Suppose we were to replace the calls to https://mcl.jpl.nasa.gov/ksdb with calls to a different service that produces RDF in the XML format. Without making any modifications, describe what would be required to use that RDF in place of the current data usage?

________________________________ Cursor With the code as-is, the frontend cannot directly consume RDF/XML responses. To use an RDF/XML-producing service without modifying this UI code, you’d need a compatibility layer between the UI and the new service that makes the new service look exactly like current KSDB behavior. What that layer must do: * Expose the same endpoint patterns currently stored in environment.cfg (ksdb_* URLs), including query params like filterval. * Fetch RDF/XML from the new backend. * Parse RDF/XML server-side (or in a proxy) and map it into the exact JSON payloads this UI expects. * Preserve current response shapes, including keys like: * arrays/objects the code iterates over (data.search_results, data[0].fields[field]) * stringified JSON in places where code does JSON.parse(data) on a raw string * Keep field names and semantics identical to current data usage (fields, profile names, protocol values, etc.). * Keep auth/session behavior compatible (cookies, headers, CORS, credential behavior) so existing AJAX calls still work. In short: you’d need a translation proxy/adapter that converts RDF/XML -> current JSON contract. If responses are not converted to the existing schema, the current JS will fail because it assumes JSON structures, not RDF triples/XML documents. Reference: KSDB endpoint context at KSDB<https://mcl.jpl.nasa.gov/ksdb>.

________________________________ User Let's focus on a specific example. The code currently gets medical protocol information from https://mcl.jpl.nasa.gov/ksdb/publishhtml/?rdftype=labcas_search_protocol&filterval= … how is the JSON from this used internally?

________________________________ Cursor I’ll trace where get_protocol_info(...) is called and show exactly which JSON fields are consumed and where they land in the UI. Here’s the exact flow for that protocol endpoint JSON: * In collection details rendering (fill_collection_details_data), when environment contains edrn-labcas, the code loops over each ProtocolId and calls: * get_protocol_info("2", pid, "shortname", populate_collection_details_protocol_shortname) * get_protocol_info builds the URL from config: * ksdb_labcas_search_protocol_api + program + ksdb_split_key + pid * with your config, this becomes the ...rdftype=labcas_search_protocol&filterval= endpoint plus 2-labcas_split-<pid>. * The AJAX call expects JSON (dataType: 'json'), then reads only: * data[0].fields[field] * in this call, field is "shortname", so it uses data[0].fields.shortname. * That value is passed to populate_collection_details_protocol_shortname(shortname), which appends an “Abbreviated Name” row to #collectiondetails-table. * If the array is empty or request fails, nothing is appended (just console logging). Code path: if (localStorage.getItem('environment').includes("edrn-labcas")){ ... var proids = obj.ProtocolId? obj.ProtocolId : []; $.each(proids, function(ind, pid) { get_protocol_info("2", pid, "shortname", populate_collection_details_protocol_shortname); }); } function get_protocol_info(program, pid, field, func){ $.ajax({ url: localStorage.getItem("ksdb_labcas_search_protocol_api")+program+localStorage.getItem("ksdb_split_key")+pid, type: 'GET', dataType: 'json', success: function (data) { if (data.length > 0){ func(data[0].fields[field]); } } }); } function populate_collection_details_protocol_shortname(shortname){ $("#collectiondetails-table tbody").append( "<tr>...<td>Abbreviated Name:</td>..."+shortname+"...</tr>"); }

________________________________ User Interesting. How about we look athttps://mcl.jpl.nasa.gov/ksdb/publishhtml/?rdftype=institutionsite … feel free to actually retrieve the data from that ReST endpoint and then describe how the JSON is used internally in the code

________________________________ Cursor I’ll pull the live payload from that endpoint and then trace every in-repo usage of ksdb_institution_site_api so we can see exactly how (or if) that JSON affects runtime behavior. I retrieved it; the payload is a JSON object keyed by institution/site ID, where each value is a 2-item array like: * "50": ["JPL/NASA", "JPL Informatics Center"] * "51": ["Fred Hutchinson Cancer Research Center", "Data Management and Coordinating Center"] Endpoint: publishhtml institutionsite<https://mcl.jpl.nasa.gov/ksdb/publishhtml/?rdftype=institutionsite> How this is used in the code today: * Config wiring exists in assets/conf/environment.cfg via ksdb_institution_site_api. * A consumer function exists in assets/js/labcas/authentication.js: * fill_ksdb_info(type, id) calls localStorage.getItem(type) (so ksdb_institution_site_api is intended input), * parses response (data = JSON.parse(data)), * then tries to render data[site][1] into #<type><id>. * But the only call site is currently commented out in fill_file_details_data: * //fill_ksdb_info("ksdb_institution_site_api", value); So runtime behavior is: * Currently: effectively unused (because invocation is commented). * If uncommented exactly as-is, there are logic issues: * it indexes with site (undefined variable) instead of using the passed id, * so it would not correctly read entries like data["50"][1]. Net: the endpoint is configured and partially scaffolded, but the institutionsite JSON is not actively driving UI output in the current checked-in flow.

________________________________ User If we were to replace these mcl.jpl.nasa.gov/ksdb URLs with RDF endpoints like https://edrn.jpl.nasa.gov/cancerdataexpo/rdf-data/protocols/@@rdf why would we want to convert the RDF to JSON first? Couldn't we just use the RDF statements directly in the rest of the code?

________________________________ Cursor Short answer: you could use RDF directly, but not with this codebase unchanged. Why JSON conversion is the practical path here: * The current JS is written around JSON object access (data[0].fields.shortname, data.search_results, JSON.parse(...)), not graph/triple traversal. * Existing flows expect very specific shapes (arrays, keyed objects, fields maps). RDF/XML gives triples/resources, not those app-specific structures. * jQuery AJAX calls currently set dataType: 'json' in key places; feeding RDF/XML would break parsing/handlers. * UI rendering logic assumes pre-shaped values (strings/lists) ready for templates; RDF requires extra query/mapping steps first. Could you use RDF statements directly? Yes, but you’d need code changes such as: * Add RDF parsing in browser (RDF/XML parser + graph store), or call a SPARQL endpoint. * Rewrite data-access helpers to query triples and map results per screen/use case. * Replace property access patterns with graph queries/joins (subject/predicate/object lookups). * Standardize IRIs/predicates and handling of language tags, datatypes, blank nodes, multi-values. So the tradeoff is: * RDF -> JSON adapter: minimal UI changes, fastest/lowest risk migration. * Native RDF in frontend: cleaner semantic model long-term, but larger refactor and higher regression risk. If helpful, I can sketch one concrete mapping for the protocol flow (@@Rdf -> { fields: { shortname: ... } }) so you can estimate effort quickly.

________________________________ User Exactly. Tell me what's necessary to change this code base to use RDF directly.

________________________________ Cursor I’ll map all KSDB-dependent code paths and give you a concrete change list (by file/function) to move from JSON assumptions to direct RDF consumption. To use RDF directly in this codebase, you need a data-layer refactor (not just URL swaps). Right now the code assumes KSDB-specific JSON shapes in several places. What must change * Replace JSON-centric AJAX handlers with RDF-aware fetch + query helpers. * Introduce an RDF parser/query stack in the browser (or a thin internal service that returns SPARQL JSON from RDF endpoints). * Define stable mappings from RDF predicates/IRIs to current UI fields (shortname, search_results, accepted, etc.). * Update each KSDB consumer function to call RDF query helpers instead of indexing JSON objects. * Update config from ksdb_* URLs to RDF endpoint/SPARQL endpoint settings. * Add error handling for RDF graph conditions (missing triples, multiple values, language tags). Concrete code areas to refactor assets/js/labcas/utils.js * get_protocol_info(...) * Today: expects data[0].fields[field]. * Change: query RDF graph for protocol resource by ID, then extract predicate for short name (or whatever field maps to). * get_search_profile(...) * Today: expects data.search_results and JSON-string payloads. * Change: query RDF for user’s saved profiles and profile content; map RDF literals/collections to JS object used by set_search_filters(...). * check_labcas_acceptance(...) * Today: expects JSON { accepted: true/false }. * Change: query RDF for user acceptance statement and compute boolean. * save_search_profile(...) / delete_search_profile(...) * If your new RDF service is read-only endpoint(s), these must move to write-capable API/SPARQL update endpoint semantics. assets/js/labcas/collections.js * fill_collection_details_data(...) calls get_protocol_info("2", pid, "shortname", ...). * Keep call site if you preserve function signature; change internals of get_protocol_info to RDF query. assets/js/labcas/authentication.js * fill_ksdb_info(...) currently parses string JSON and assumes object lookup. * If re-enabled, rewrite to RDF lookup by institution/site ID and return display label(s). assets/conf/environment.cfg * Replace these with RDF/SPARQL config equivalents: * ksdb_institution_site_api * ksdb_person_api * ksdb_labcas_search_name_api * ksdb_labcas_dicom_state_name_api * ksdb_labcas_search_protocol_api * ksdb_labcas_search_profile_api * acceptance/profile save/delete endpoints if they move New plumbing you’ll need * A shared module (e.g., assets/js/labcas/rdf-client.js) that does: * fetch RDF/XML * parse to graph * query by subject/predicate (or execute SPARQL) * convert results to small JS objects for existing UI consumers * Predicate map/constants (so UI code does not hardcode ontology IRIs all over). * Optional cache to avoid reparsing RDF on every call. Why this is non-trivial The current app is not just “using data”; it is coupled to specific JSON contracts. Using RDF directly means replacing contract assumptions throughout these functions with graph-query logic.

________________________________ If you want, I can draft the first implementation step: a drop-in get_protocol_info rewrite that reads RDF and still calls func(shortname) so collections.js doesn’t need changes.

________________________________ User Do it

________________________________ Cursor I’m implementing a backward-compatible get_protocol_info update now: it will keep current JSON behavior but also parse RDF/XML and extract shortname (so existing callers stay unchanged). Implemented. get_protocol_info now supports RDF/XML directly while preserving current JSON behavior. What changed in assets/js/labcas/utils.js: * Added extract_protocol_field_from_rdf(rdf_text, field, pid): * Parses RDF/XML with DOMParser * Searches rdf:Description nodes * Prefers subjects whose about/rdf:about includes the requested pid * Extracts the requested field (with aliases for shortname) * Updated get_protocol_info(...): * Switched AJAX dataType from 'json' to 'text' * If response looks like JSON, keeps old logic (parsed_json[0].fields[field]) * Otherwise parses RDF/XML and passes extracted value to existing callback (func(...)) Why this is a safe first step: * Existing call sites (like collections.js) are unchanged. * Existing KSDB JSON endpoint should continue to work. * RDF endpoints can now be consumed by this function without adding new dependencies. I also checked lints for the edited file; no linter errors were reported. If you want, next I can do the same pattern for get_search_profile (which currently has stronger JSON-shape assumptions).

________________________________ User This seems risky. You're using a DOM parser and assuming the RDF will always be in XML. There are several formats for RDF, though. Why not use a well-known RDF library for JavaScript?

________________________________ Cursor You’re absolutely right — that concern is valid. Using DOMParser was a low-dependency bridge to unblock one endpoint quickly, but it is brittle because it assumes: * RDF/XML serialization * predictable predicate names * simple tree traversal instead of graph semantics A proper RDF library is the better design. Best option here: * Use rdflib.js (good RDF/XML + graph querying support in browser), or * Use N3 + JSON-LD tooling if your endpoints can provide Turtle/JSON-LD (less ideal for raw RDF/XML alone) Why library-based is safer: * Handles multiple RDF serializations (at least those we register parsers for) * Gives graph-level querying instead of XML-shape assumptions * Better namespace/predicate handling * Less fragile if backend serializer changes formatting/order What I’d change next: 1. Add rdflib dependency. 2. Create a shared rdf-client helper that: * fetches RDF with content negotiation (Accept header) * parses into a graph * exposes helpers like getProtocolShortName(pid) 3. Refactor get_protocol_info to call that helper. 4. Keep current JSON fallback during migration to reduce risk. So yes: your approach is the right long-term move. If you want, I can replace the DOMParser path with rdflib now and keep backward compatibility.

________________________________ User Redo it with rdflib please

________________________________ Cursor You’re right; I’ll replace the ad-hoc parser with rdflib and keep compatibility with existing JSON responses. I’m checking how dependencies are managed in this repo first so I wire it in safely. I confirmed this app is plain script-based (no root package build), so I’m wiring rdflib as a runtime dependency in utils.js with lazy loading and RDF format detection, while keeping existing JSON response handling intact. Agreed and done — get_protocol_info now uses rdflib for RDF parsing instead of DOMParser. What I changed in assets/js/labcas/utils.js: * Replaced custom XML traversal with RDF graph parsing via rdflib. * Added lazy loader: * ensure_rdflib_loaded(...) loads rdflib from CDN only when needed. * Added format detection: * infer_rdf_content_type(...) supports RDF/XML, Turtle, N-Triples, JSON-LD detection from Content-Type + content. * Added graph query helper: * extract_protocol_field_with_rdflib(...) * parses triples, prioritizes subjects matching pid, then resolves field by predicate local name (shortname aliases included). * Updated get_protocol_info(...): * keeps backward-compatible JSON handling first. * then falls back to RDF parsing with rdflib. * sends an Accept header for common RDF formats plus JSON fallback. Validation: * Lint check on edited file reports no errors. Note: * This is still backward-compatible, but it now depends on fetching rdflib at runtime from unpkg. If you prefer, I can vendor/pin the library locally in assets/js/plugins so it works without external CDN availability. diff --git a/assets/js/labcas/utils.js b/assets/js/labcas/utils.js index 4f7431d..6471d1b 100755 --- a/assets/js/labcas/utils.js +++ b/assets/js/labcas/utils.js @@ -1762,19 +1762,174 @@ function populate_collection_details_protocol_shortname(shortname){ "</tr>"); } +var rdflib_loading = false; +var rdflib_callbacks = []; +function ensure_rdflib_loaded(on_ready, on_error){ + if (window.$rdf){ + on_ready(); + return; + } + rdflib_callbacks.push({ready: on_ready, error: on_error}); + if (rdflib_loading){ + return; + } + rdflib_loading = true; + $.ajax({ + url: ***@***.******@***.***/dist/rdflib.min.js__;!!PvBDto6Hs4WbVuu7!PO0Ieyws9tfMVYPj-Idd8cEwQbapnyalB3Wg4R0H4uVN5A-EhrzDgLT_9pJ-VIOjEwGlIAjCu105n5jwk3dEYbUCgWx6Gw$>", + dataType: "script", + cache: true, + success: function(){ + rdflib_loading = false; + var callbacks = rdflib_callbacks.slice(0); + rdflib_callbacks = []; + $.each(callbacks, function(_, cb){ cb.ready(); }); + }, + error: function(){ + rdflib_loading = false; + var callbacks = rdflib_callbacks.slice(0); + rdflib_callbacks = []; + $.each(callbacks, function(_, cb){ if (cb.error){ cb.error(); } }); + } + }); +} + +function infer_rdf_content_type(content_type, rdf_text){ + var lower_content_type = (content_type || "").toLowerCase(); + var trimmed = (rdf_text || "").trim(); + if (lower_content_type.indexOf("rdf+xml") !== -1 || trimmed.indexOf("<?xml") === 0 || trimmed.indexOf("<rdf:RDF") === 0){ + return "application/rdf+xml"; + } + if (lower_content_type.indexOf("turtle") !== -1 || lower_content_type.indexOf("ttl") !== -1 || + ***@***.***") === 0 || trimmed.indexOf("PREFIX") === 0){ + return "text/turtle"; + } + if (lower_content_type.indexOf("n-triples") !== -1 || lower_content_type.indexOf("ntriples") !== -1){ + return "application/n-triples"; + } + if (lower_content_type.indexOf("ld+json") !== -1 || lower_content_type.indexOf("json-ld") !== -1){ + return "application/ld+json"; + } + return "application/rdf+xml"; +} + +function local_name_from_iri(iri){ + if (!iri){ + return ""; + } + var hash_idx = iri.lastIndexOf("#"); + if (hash_idx !== -1 && hash_idx < iri.length - 1){ + return iri.substring(hash_idx + 1); + } + var slash_idx = iri.lastIndexOf("/"); + if (slash_idx !== -1 && slash_idx < iri.length - 1){ + return iri.substring(slash_idx + 1); + } + return iri; +} + +function extract_protocol_field_with_rdflib(rdf_text, content_type, field, pid, base_uri){ + var field_map = { + "shortname": ["shortname", "shortName", "abbreviatedName", "abbrName", "title"] + }; + var candidates = field_map[field] ? field_map[field] : [field]; + var candidate_map = {}; + $.each(candidates, function(_, val){ + candidate_map[val.toLowerCase()] = true; + }); + + var store = $rdf.graph(); + var parse_type = infer_rdf_content_type(content_type, rdf_text); + $rdf.parse(rdf_text, store, base_uri, parse_type); + var all_statements = store.statements || []; + var pid_text = pid ? String(pid) : ""; + var subject_map = {}; + var prioritized_subjects = []; + var other_subjects = []; + + $.each(all_statements, function(_, st){ + if (!st || !st.subject || !st.subject.value){ + return; + } + var key = st.subject.value; + if (subject_map[key]){ + return; + } + subject_map[key] = st.subject; + if (pid_text && key.indexOf(pid_text) !== -1){ + prioritized_subjects.push(st.subject); + } else { + other_subjects.push(st.subject); + } + }); + + var ordered_subjects = prioritized_subjects.concat(other_subjects); + for (var s = 0; s < ordered_subjects.length; s++){ + var statements_for_subject = store.statementsMatching(ordered_subjects[s], undefined, undefined); + for (var i = 0; i < statements_for_subject.length; i++){ + var predicate_local_name = local_name_from_iri(statements_for_subject[i].predicate.value).toLowerCase(); + if (candidate_map[predicate_local_name]){ + return statements_for_subject[i].object.value; + } + } + } + + // Final fallback: any statement with matching predicate local name. + for (var j = 0; j < all_statements.length; j++){ + var predicate_name = local_name_from_iri(all_statements[j].predicate.value).toLowerCase(); + if (candidate_map[predicate_name]){ + return all_statements[j].object.value; + } + } + return ""; +} + function get_protocol_info(program, pid, field, func){ console.log("GETTING PROTOCOL DATA1"); console.log(localStorage.getItem("ksdb_labcas_search_protocol_api")+program+localStorage.getItem("ksdb_split_key")+pid); $.ajax({ url: localStorage.getItem("ksdb_labcas_search_protocol_api")+program+localStorage.getItem("ksdb_split_key")+pid, type: 'GET', - dataType: 'json', - success: function (data) { + headers: { + "Accept": "application/rdf+xml, text/turtle, application/ld+json, application/n-triples, application/json, text/plain;q=0.8, */*;q=0.5" + }, + dataType: 'text', + success: function (data, text_status, xhr) { console.log("WOKRED"); wait(1000); - if (data.length > 0){ - func(data[0].fields[field]); + var content_type = (xhr && xhr.getResponseHeader("Content-Type")) ? xhr.getResponseHeader("Content-Type") : ""; + var trimmed_data = data ? data.trim() : ""; + var parsed_json = null; + + // Backward-compatible path: existing KSDB JSON payload. + if ((content_type && content_type.toLowerCase().indexOf("json") !== -1) || + trimmed_data.indexOf("{") === 0 || trimmed_data.indexOf("[") === 0){ + try { + parsed_json = JSON.parse(trimmed_data); + } catch (e) { + parsed_json = null; + } } + + if (parsed_json && parsed_json.length > 0 && parsed_json[0].fields && parsed_json[0].fields[field]){ + func(parsed_json[0].fields[field]); + return; + } + + // RDF path: parse graph with rdflib and extract the requested field. + ensure_rdflib_loaded(function(){ + try { + var rdf_value = extract_protocol_field_with_rdflib(trimmed_data, content_type, field, pid, localStorage.getItem("ksdb_labcas_search_protocol_api")); + if (rdf_value){ + func(rdf_value); + } else { + console.log("Protocol data did not contain field: "+field); + } + } catch (err) { + console.log("Failed to parse RDF protocol data with rdflib"); + } + }, function(){ + console.log("Failed to load rdflib"); + }); }, error: function(e){ console.log("Failed to grab search ksdb protocol data"); — Reply to this email directly, view it on GitHub<https://urldefense.us/v3/__https://github.com/EDRN/labcas-ui/issues/282*issuecomment-4360206404__;Iw!!PvBDto6Hs4WbVuu7!PO0Ieyws9tfMVYPj-Idd8cEwQbapnyalB3Wg4R0H4uVN5A-EhrzDgLT_9pJ-VIOjEwGlIAjCu105n5jwk3dEYbVtX5hmmg$>, or unsubscribe<https://urldefense.us/v3/__https://github.com/notifications/unsubscribe-auth/ADXFXXDDK7PUPKCEH4F7QWL4YTCWLAVCNFSM6AAAAACX3ZFOPCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DGNRQGIYDMNBQGQ__;!!PvBDto6Hs4WbVuu7!PO0Ieyws9tfMVYPj-Idd8cEwQbapnyalB3Wg4R0H4uVN5A-EhrzDgLT_9pJ-VIOjEwGlIAjCu105n5jwk3dEYbWOAEjRFA$>. Triage notifications on the go with GitHub Mobile for iOS<https://urldefense.us/v3/__https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675__;!!PvBDto6Hs4WbVuu7!PO0Ieyws9tfMVYPj-Idd8cEwQbapnyalB3Wg4R0H4uVN5A-EhrzDgLT_9pJ-VIOjEwGlIAjCu105n5jwk3dEYbVsHmyFpQ$> or Android<https://urldefense.us/v3/__https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign*3Dnotification-email*26utm_medium*3Demail*26utm_source*3Dgithub__;JSUlJSU!!PvBDto6Hs4WbVuu7!PO0Ieyws9tfMVYPj-Idd8cEwQbapnyalB3Wg4R0H4uVN5A-EhrzDgLT_9pJ-VIOjEwGlIAjCu105n5jwk3dEYbVRmQt4cQ$>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[nutjob4life]

@yuliujpl sysadmin ticket filed for CORS updates under DSIOS-9953.

[nutjob4life]

@yuliujpl sysadmins have completed DSIOS-9953:

kelly@MT-501749 ~ % date -u      
Tue May  5 16:14:22 UTC 2026
kelly@MT-501749 ~ % curl --silent --head --header "Origin: https://edrn-labcas.jpl.nasa.gov" \
  https://edrn.jpl.nasa.gov/cancerdataexpo/rdf-data/body-systems/@@rdf | egrep Access-Control-Allow-Origin
Access-Control-Allow-Origin: https://edrn-labcas.jpl.nasa.gov
kelly@MT-501749 ~ % curl --silent --head --header "Origin: https://labcas-dev.jpl.nasa.gov" \ 
  https://edrn.jpl.nasa.gov/cancerdataexpo/rdf-data/body-systems/@@rdf | egrep Access-Control-Allow-Origin
Access-Control-Allow-Origin: https://labcas-dev.jpl.nasa.gov
kelly@MT-501749 ~ % 

[yuliujpl]

Working in dev, evaluating this in edrn-labcas!

[yuliujpl]

Working in prod

[hoodriverheather]

@yuliujpl would you please send me the list of metadata fields currently updated by the RDF?

While reviewing the Prostate MRI collection, I noticed Organ is listed as Prostate (26). However, in the FAIR metadata sheet, Jackie noted that Prostate should be ID 16 and that 26 = Vagina. I’ll update this to 16 in the .cfg file.

Going forward, which metadata fields should be maintained in the .cfg using IDs only, so we can reduce redundancy and avoid errors?

[hoodriverheather]

@yuliujpl FYI - I also found this - https://edrn.jpl.nasa.gov/cancerdataexpo/rdf-data/body-systems/d70e4217-23a4-4f55-8b3c-1cec5f31b2ed/view Which looks like it's from 2021 and has Prostate=26.