balkian/balkian.github.com
1
0
Fork 0
mirror of https://github.com/balkian/balkian.github.com.git synced 2025-04-16 01:39:04 +00:00
Code Issues Releases Wiki Activity

typo collaboration

Browse Source
This commit is contained in:
J. Fernando Sánchez 2025-03-06 01:47:55 +01:00
parent ec2e9ea7cc
commit d7ecee1664
2 changed files with 64 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

62
content/post/a-reflection-on-rdf-and-the-semantic-web.md Normal file
View File

@ -0,0 +1,62 @@
---
title: "A Reflection on RDF and the Semantic Web"
description:
date: 2025-03-04T19:19:53+01:00
image:
math:
license:
hidden: false
comments: true
draft: true
---
I've been involved with semantic technologies almost for as long as I've been building software.
Before my internship at the Intelligent Systems Group in 2009, I had done very little programming.
This more or less coincidences with the rise of the semantic web.
Given GSI's background with knowledge representation and web engineering, it should be no surprise that many projects back then involved RDF and semantic technologies.
Moreover, most of the projects since then have been related to semantic technologies in some shape or form.
I remember being intrigued, then fascinated, with the idea of linked data.
Representing knowledge in a way that allows both humans and machines to consume it seemed so obvious.
In a way, it also tickled my "distributed systems" bone, with the whole "distributed and collaborative graph of knowledge".
But it would not really get involved with the semantic web until years later, as part of my PhD thesis.
First, I was tasked with extending an existing vocabulary for sentiment analysis ([Marl](https://www.gsi.upm.es/ontologies/marl/)) to include provenance information (Prov-O).
Then I applied the same ideas to define a new vocabulary for emotion analysis ([Onyx](https://www.gsi.upm.es/ontologies/onyx)).
Not long after that, I started working on a framework to allow laypeople to develop "semantic NLP services".
It was already apparent to me that developing proper semantic services was out of reach (or interest) for the average programmer.
There were too many concepts to learn (vocabularies, RDF-XML, turtle, inference...) without much push from industry to learn them.
But I was still convinced that a semantic framework would lead to interoperability and flexibility.
And those two benefits would lead to more adoption, ease of use, and more useful applications being developed.
Besides, I was less focused on the long term viability of the project and more interested in the technical and usability challenges.
Building that framework has taught me very valuable lessons, which I'll probably get into in a separate post.
On the topic of RDF and the semantic web, it made me deal with the reality of developing real semantic services that other consumers depend on, witnessing undergrads struggle with semantic annotations while developing their own services for their thesis, and building data annotation pipelines that rely on said services and their made-up annotations.
## The good
### Unique identifiers allow for federated knowledge graphs
### RDF's data model is neat
Modelling every fact as a triple is very powerful.
Moreover, it makes it possible to represent your schema/vocabularies using the same raw elements.
At the same time, it can be confusing for newcomers to grasp the difference between a vocabulary (TBox) and the data graph (ABox).
### SPARQL is quite versatile
### Linking data should provide a network effect
## The bad
### Defining vocabularies is tricky
### Vocabularies are not properly maintain
### Projects in the semantic space are not properly maintained
## The ugly
### Nobody cares about it

8
content/post/efficient-collaboration.md
View File

@ -5,14 +5,10 @@ description:
date: 2025-03-05T09:25:54+01:00
image:
math:
categories:
- Reflections
tags:
- management
license:
hidden: false
comments: true
draft: false
draft: true
---
## Background
@ -34,7 +30,7 @@ To do so, most projects rely on three types of staff: a) senior researchers (pos
The level of contribution is generally inversely propotional to the level of mastery of the contributor: PhD students design and develop the main contributions (both software and experimental) under the supervision of senior researchers (advisor/supervisor), and interns take care of tasks that are narrow in scope and not crucial to any academic contribution.
For instance, a PhD student may develop a new model for text classification, and an intern will wrap that model in an HTTP service with a nice UI.
When the service and UI part is intricate and has some potential academic merit, that task may be conducted by a PhD student as part of their thesis.
That was precisely the case with Senpy, which was part of my PhD thesis, and as since been used by dozens of students to develop services in the context of other research projects.
That was precisely the case with Senpy, which was part of my PhD thesis, and it has since been used by dozens of students to develop services in the context of other research projects.
## Reasons to form a team