Tematy projektów WSHOP -- wiosna 2025/2026

• : Possibility of extending it to master thesis
• : Quick project
• : Linked to international scientific project
• : Linked to JU-internal scientific project

• Student:
• Namespace in the wiki: FIXME
• The goal of the project:
• Technology:
• Description:
• Links:
  • 

• Student:
• Namespace in the wiki: chcloud
• The goal of the project: Validate the usability of Wikidata as a central point of cultural heritage data cloud
• Technology: RDF/Semantic Web, some programming (Python preferred)
• Description: Wikidata has many links to external sources of information (URIs/foreign keys), but are these links correct? Can additional information be extracted from these sources, or do these pages not contain any data that can be processed automatically? Previous project (chcloud) started exploration of this topic (validation of some links, basic data extraction). Now, we want to continue it and: (a) check whether this process can be automated, (b) prepare a knowledge graph that will combine this data into a single cultural heritage data cloud [for the purposes of the project, we will probably limit it to individuals associated with the University], (c) evaluate such a graph (including comparison with a graph containing only data from Wikidata)

• Student:
• Namespace in the wiki: iconclass
• The goal of the project: Extend the existing prototype of ICONCLASS-based classification and recommendation modules
• Technology: RDF/Semantic Web, Python, ML basics
• Description: Iconclass is a very complex system for classifying objects depicted in artworks, covering real objects, various scenes, and abstract concepts. It has been used for many years by experts to tag artworks. We want to help them do this, so we have created a prototype tool that first assigns tags (classification) and then recommends related artworks. As part of this project, we want to expand this tool. Directions for development: (a) Detection fine-tuning: find Iconclass-labeled datasets and fine-tune YOLO (or other object-detection model), (b) Multimodal classification: not only YOLO, but also textual metadata, iconographic labels, neural image features, and even visin-language embeddings like CLIP can help in better classification, (c) expand rule engine for abstract codes inference: rules can be mined semi-automatically from large Iconclass-labeled corpora (with frequent pattern mining over code co-occurrences), (d) recommendation module: create unified recommender (now, we have three recommenders), add explainability layer. There is also a place for your ideas :)
• Links:
  • Paper with current status: Iconographic Classification and Content-Based Recommendation for Digitized Artworks

• Student:
• Namespace in the wiki: graphrecs
• The goal of the project: Extend the existing recommendation workflow to include expert knowledge, an evaluation interface with explanations for experts, and user interface for final users
• Technology: RDF/Semantic Web, SPARQL, Python, recommendation systems, knowledge graph embeddings, XAI
• Description: We have developed a prototypical recommendation system for cultural heritage knowledge graphs and evaluated it within CHExRISH project (see this paper). Even if the results obtained are promising, it turned out that our recommendations do not coincide with those of the experts (i.e., the experts propose different nodes in the graph than the model we prepared). Why? Are experts interested in specific relationships in the graph? Do experts focus only on the significant nodes? Or do experts use some knowledge that is not reflected in the graph? (a) Investigating this is the first goal of the project. In addition: (b) based on the results of the investigation, we want to extend the recommendation module to take them into account (this may require improving SPARQL-based filtering), © we want to prepare an interface for experts that will allow them to evaluate recommendations and enter their own recommendations (by selecting nodes in the graph), (d) the whole process may ultimately become a closed workflow that iteratively improves the model in accordance with the knowledge provided by experts. We also want to (e) prepare an interface for end users: based on the selected node, it suggests several related nodes.
• Links:
  • Paper with our recommender system: A Three-stage Neuro-symbolic Recommendation Pipeline for Cultural Heritage Knowledge Graphs

• Student:
• Namespace in the wiki: graphpaths
• The goal of the project: Prepare a tool that visualizes connections between two or more nodes in a graph along with their relevant context
• Technology: RDF/Semantic Web, some programming (Python is preffered), vizualization, LLMs
• Description: At the input, we have an arbitrarily large knowledge graph in RDF format and two or more nodes, e.g., a target and its recommendation as in the project described in this paper. The goal of the project is to develop visualizations that will help the user understand the real connections between these nodes. As part of the project, we want to explore the following scenarios: (a) direct paths: find the shortest path and visualize it, (b) informed-shortest path: in the above-mentioned project, the recommendation module provides information why the following node was proposed; this information can be used in the visualization, © provide the context: check which nodes in the environment are relevant (e.g., using centrality measures) and add them to the visualization, (d) use more than two nodes: e.g., use target and more than one recommendation, (e) we also want to explore the possibility of using language models to summarize the generated paths/visualizations.
• Links:
  • Paper with our recommender system: A Three-stage Neuro-symbolic Recommendation Pipeline for Cultural Heritage Knowledge Graphs

• Student:
• Namespace in the wiki: tgnnx
• The goal of the project: Celem projektu jest integracja algorytmu ACFX do generowania wyjaśnień kontrfaktyczncyh z grafowymi sieciami neuronotymi dla szergów czasowych.
• Technology: Python

* Description:

• Wybór problemu i danych (przykladowy zbiór i implementacja będą dane, ale możliwa zmiana na coś prostszego): prosta klasyfikacja/regresja na grafach czasowych (np. ruch/obciążenie, prosty syntetyczny graf czasowy lub mały benchmark z PyG-Temporal).
• Model bazowy: implementacja prostego TGN
• Adapter ACFX:
  • zdefiniowanie celu kontrfaktu (zmiana klasy / przesunięcie wartości wyjścia),
  • przestrzeń dozwolonych zmian (węzły, krawędzie, atrybuty; ograniczenia „realizmu”),
  • funkcja straty kontrfaktu (fidelity + sparsity + plausibility).
• Ewaluacja: fidelity/validity kontrfaktów, koszt (liczba zmienionych cech), stabilność w czasie (czy kontrfakt „utrzymuje” efekt w kolejnych krokach).
• Demo: notebook + krótkie CLI do wygenerowania kontrfaktu dla wskazanego węzła/czasu.

* Links:

• ACFX – dokumentacja
• PyTorch Geometric Temporal
• PyTorch Geometric

• Student:
• Namespace in the wiki: ecg
• The goal of the project: Stworzenie autoenkodera dla szeregów EKG i analiza latent‑space (UMAP/t‑SNE) pod kątem lokalizacji jednostek chorobowych, płci i innych metadanych; w drugiej części – prosta klasyfikacja na wektorach latentnych.
• Technology: Python

* Dane i preprocessing:

• wybór publicznego zbioru (np. PTB‑XL) (dostępna wersja już po preprocesingu na łame chunk równej długości)
• Model:
• 1D‑CNN/Transformer/LSTMConv autoencoder (rekonstrukcja sygnału),
• ekstrakcja wektorów latentnych.
• Analiza latent‑space:
• wizualizacja (UMAP/t‑SNE),
• klasyfikacja/klasteryzacja (LR/SVM/MLP) na latentach dla: diagnoz, płci, wieku (jeśli dostępne).
• Ewaluacja:
• rekonstrukcja (MSE/MAE),
• klasyfikacja (Accuracy/F1/AUROC lub w przypad),
• inspekcja „czytelności” latentów (separowalność klas).
• Deliverables: notebooki, raport PDF, wykresy latent‑space.

* Links:

• Publiczny zbiór danych (opis PTB‑XL)
• PTB‑XL na PhysioNet

• Student:
• Namespace in the wiki: tgnnx
• The goal of the project: Celem projektu jest dodanie funkcjonalności generowania kontrfaktów dla regresji do oprogramowania ACFX
• Technology: Python
• Description:
  • Specyfikacja regresyjna:
    • funkcja celu dla zmiany wartości wyjścia (np. osiągnięcie y\* lub przesunięcie o Δ),
  • Implementacja:
    • adapter/loss pod regresję juz istniejacego kodu (w praktyce bedzie koneiczna lekka modyfikacja juz istniejacej funkcji kosztu i wsparcie dla innego rodzaju modeli )
  • Ewaluacja:
    • zbiory tablicowe (np. UCI – małe, łatwe do replikacji),
    • metryki: validity (osiągnięcie celu), proximity, sparsity, czas obliczeń,
    • porównanie z prostymi baseline’ami (gradient/sign, DiCE – jeśli dostępny).
  • Demo: krótki notebook + integracja z dashboardem ACFX i przetestowanie czy aplikacja streamlit też działa z modelami regresyjnymi
• Links:
  • ACFX
  • Streamplit dashboard

• Student:
• Namespace in the wiki: tgnnx
• The goal of the project: Celem projektu jest zintegrowanie w całość ewaluacji generowania kontrfaktó dla algorytmów detekcji anonalii
• Technology: Python, PyTorch
• Description: W szczególności chodzi o integracje w jeden ewaluacyjny pipeline nastepujacych algorytmów i wykonanie analizy danych na bazie tej ewalyacji które pozwoli określić
  1. Algorytmy: RIAD, InTra, AMI-Net,FAIR,DFMGAN,AnoStyler.
  2. Algorytm detekcji anomalii PatchCore, Padim, DFM, i inne z paczki anomalib
  3. Budujemy detektor anomalii, nastepnie dla każdego detektora budujemy kontrfakty każym algorytmem wymienionym wopisie, następnie przeprowadzamy ewaluację wyników. Kontrfakty maja działąć w dwie strony (dl kalsy normal generują abnormal, dla klasy abnormal generują normal)
• Links:
  • Zestaw gotowych implementacji (prawie wszystkich)

• Student:
• Namespace in the wiki: winclip
• The goal of the project: Zbudować prosty pipeline demonstracyjny, w którym model WinCLIP (zero-/few-shot na bazie CLIP) wykrywa i segmentuje anomalie na wybranych klasach z MVTec AD i/lub VisA, a wynik modelu jest od razu IRI węzła w małym grafie wiedzy (RDF). Następnie, z poziomu UI można wykonać zapytania (SPARQL) o zalecane działania/mitigacje dla danej anomalii
• Technology:
• Description:
  1. Wybór danych (mały wycinek): na start 2 klasy z MVTec AD (np. bottle, screw) lub z VisA (np. candle, capsules) – tak, by mieć parę typów defektów (np. scratch, contamination, missing part).
     1. Inference WinCLIP (zero-/few-shot): uruchomienie gotowej implementacji WinCLIP z prostą ensemble‑prompting dla stanów „normalny/anomalny + typ” (bez trenowania). Dla demonstracji wystarczy zero‑shot; ewentualnie few‑shot z 1–2 obrazami „good”.
     2. Mapowanie → węzeł KG: wynik (etykieta/typ defektu) zamieniamy na konkretny IRI, np. ex:defect/visa/scratch lub ex:defect/mvtec/contamination. W RDF tworzymy minimalne klasy:

    ex:DefectType (np. scratch, contamination),
    ex:Cause (np. abrasive_contact),
    ex:Action (np. line_stop, replace_guide_rail).
    

1. Zapytania / rekomendacje: proste kwerendy SPARQL: „podaj ex:recommendedAction dla danego ex:DefectType” + wyświetlenie w UI wraz z podglądem maski.
2. Ewaluacja (lekka): dla wybranej klasy raportujemy i‑AUROC/p‑AUROC oraz zrzuty ekranu; celem jest działający demo‑flow, nie bicie SOTA. (WinCLIP raportuje wysokie wyniki na MVTec/VisA w warunkach zero/few-shot – nasz cel to tylko potwierdzić działanie na małej próbce). ONtologia, rekomendacje/akcje – moga byc nieprawdziwe, chodzi tylkok o demo mozliwosci.

* Links:

• WinCLIP (poszukaj arXiv/implementacji – do uzupełnienia)
• MVTec AD
• VisA
• SOSA/SSN
• SAREF4INMA
• RDFLib
• Apache Jena Fuseki

• Student:
• Namespace in the wiki: xaifungi
• The goal of the project: Celem pracy jest wykorzystanie zbioru dancyh XAI-FUNGI do klasyfikacji grupy osób na bazie dialogów/akcji użytkownika.
• Technology: Python, text analysis,
• Description: Zbiór XAI-FUNGI zawiera transkrypcje wywaidów z ekspertami, studentami informatykami i studentami studiów nieinformatycznych. Każdy transkrypt jest plikiem CSV, z wydzielonymi fragmentami w których uczestnik analizuje na głos wybrany element charaktecryzujacy model do klasyfikacji grzybów. Celem jest zbudownaie klasyfikatora, który będzie staral się określić do jakiej grupy należy dany użytkownik, bazujać na tych transkrypcjach.
• Links:
  • 

• Student:
• Namespace in the wiki: pytracker
• The goal of the project: Celem pracy jest przetestowanie funkconoalności narzędzia do mapowania wzroku (uwagi) użytkownika na różne modelaności (tekst, obraz, szeregi czasowe), oraz implementacja customowego daatsetu dla EKG,
• Technology:
• Description: Nowy ECGTSDataset który będzie dziedziczył po istniejąceym TimeSereisDataset, ale skupiał sie będzie na poprawnej wizuzalizacji EKG z wykorzystaniem wizualizacji mitującej papier milimetrowy i z zachowaniem skali i odstępów niezb ednych do porpawnej analizy. Przykłady, wizualizacje, analizy wyników.
• Links:
  • 

• Student:
• Namespace in the wiki: llm_ctx_attr
• The goal of the project: Zbudować działający pipeline do ilościowego i wizualnego badania, jak poprzednia tura (t‑1) wpływa na odpowiedź w turze (t) w LLM. Projekt łączy atrybucję gradientową (Integrated Gradients/SHAP, toolkit Inseq) z testami przyczynowymi (activation/causal patching na TransformerLens/causal‑tracer), raportując m.in. „udział t‑1” w logitach odpowiedzi oraz logit‑difference w testach interwencyjnych.
• Technology:
  • Hugging Face Transformers (małe modele dekoderowe; inference + logprobs/score)
  • Inseq – IG/Grad×Input dla LLM (wizualizacja atrybucji kontekst→odpowiedź)
  • TransformerLens – hooki, cache aktywacji; causal/activation patching (best‑practices)
  • causal‑tracer – „causal flow/patching” i heatmapy
• Description:
  • Dane (mały, kontrolowany korpus): pary *(t‑1, t)*, gdzie w *t‑1* znajduje się fakt/warunek potrzebny do odpowiedzi w *t* (np. „Hasło: ALFA” → „Podaj hasło”).
  • Modele i uruchomienie: niewielki model dekoderowy (GPT‑2‑klasa / mały LLaMA) z dostępem do aktywacji/logprobs.
  • Baseline zachowania (2 warianty):
    • (a) `[t‑1 || t]` (pełny kontekst),
    • (b) `[t]` (bez *t‑1*),
    • (c ) sesyjny z KV‑reuse (prefill *t‑1*, potem *t*)
  • Atrybucja IG/SHAP (Inseq): IG dla kluczowych tokenów odpowiedzi względem tokenów wejścia (w tym *t‑1*); metryka „udział t‑1” = % sumarycznej atrybucji przypisanej tokenom *t‑1*; heatmapy (kontekst→odpowiedź).
  • Causal/activation patching – test przyczynowy (faithfulness):
    • „Corrupt → Clean”: zaszum/wyzeruj kluczowe tokeny w *t‑1* (prompt „corrupt”), następnie patch czystych aktywacji tylko dla tych tokenów (per warstwa/głowa).
    • Metryka: logit‑difference dla poprawnych tokenów odpowiedzi; silny wzrost po patchingu = dowód przyczynowego użycia fragmentów *t‑1*.
• Porównanie: korelacja rankingów ważności tokenów *t‑1* (IG vs patching); różnice między (a)/(b).
  • Raport: metryki (udział t‑1, logit‑difference, zmiana logprobs, zgodność IGpatching )

Links:

• Inseq – feature attribution for generative LMs
• TransformerLens – mechanistic interpretability / hooki
• causal‑tracer – causal tracing/patching
• Logprobs – przykłady