Fix keyword rendering for DefinedTerm objects

[ywkim312]

Fix keyword rendering for DefinedTerm objects

Fixes #216

Changes

• Extract name property from DefinedTerm objects in keywords/variables on dataset pages
• Update SPARQL queries to extract keywords from DefinedTerm objects
• Render keywords as clickable links when URLs are available

Testing

1. Start client with deepoceans config:
   PC

   cd client
   $env:VITE_FACETS_CONFIG_FILE = "config/config_deepoceans.yaml"; npm run dev

   Ubuntu

   cd client
   export VITE_FACETS_CONFIG_FILE=config/config_deepoceans.yaml 
   npm run dev

2. Search for "BODC":

   • Navigate to search page
   • Enter "BODC" in search box
   • Verify keywords display correctly in search results (no "[object Object]")
   • Check Keywords facet shows extracted keyword names with counts

3. Verify dataset pages:

   • Click on any dataset from search results
   • Check Keywords section displays as readable text
   • Verify keywords with URLs render as clickable links
   • Confirm variableMeasured fields display correctly

4. Test with the specific BODC dataset from issue BODC bad rendering Keywords that are list of DefinedTerm #216:

   cd client
   export VITE_FACETS_CONFIG_FILE=config/config_qlever_test.yaml
   npm run dev

   I pushed the new test config file named config_qlever_test.yaml for this test

   • Navigate to: http://localhost:5173/#/dataset/urn:gleaner.io:eco:bodc:data:99c10d8deeeb174480dce0de1a75ac21b4f3860a
   • Before fix: Keywords show "[object Object], [object Object]..." (17 times)
   • After fix: Keywords display correctly as clickable links (e.g., "Temperature of the water column", "Reference numbers", etc.)

Verification

Fix verified: Tested with the specific BODC dataset from issue #216. All 17 keywords from DefinedTerm objects now display correctly as clickable links instead of "[object Object]" text. The fix successfully extracts the name property from DefinedTerm objects and preserves URLs for rendering as links.

Review Time Estimate

Please give your idea of how soon this pull request needs to be reviewed by selecting one of the options below. This can be based on the criticality of the issue at hand and/or other relevant factors.

• Immediately
• Within a week
• When possible

Type of changes

Please select a relevant option:

• Bug fix (non-breaking change which fixes an issue).
• New feature (non-breaking change which adds functionality).
• Breaking change (fix or feature that would cause existing functionality to not work as expected).
• Other (any another change that does not fall in one of the above categories.)

Checklist:

Please select all applicable options:

• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• My change requires updating the documentation.
• I have made necessary changes to the documentation.
• I have added tests related to my changes.
• My changes generate no new warnings.
• New and existing unit tests pass locally with my changes.
• Any dependent changes have been merged and published in downstream modules.