Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Add semantic information to shape trees to discriminate between different resource classes

Open
  • Is something wrong?
#277 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Stale
Domain
documentation

Research direction

Start with the Shape Trees specification's validateResource algorithm, the shape tree namespace, and the linked specification issue and hierarchy example. Determine how targetClass should be defined and used to distinguish resource classes; done means the specification consistently describes that behavior and the Task/Project examples no longer validate interchangeably.

Written by the indexing model from the issue text.

Description

A couple of months ago I bumped into what I think is a malfunction of the validateResource algorithm of the shape tree specification that I described in this issue. Basically, trying to implement a shape tree validator that would execute the algorithm on the resources of the hierarchy described in an example found in the interoperability specification, I discovered that a "Task" resource is validated with a true result against a "Project" shape tree (and viceversa). This is due to the fact that the shape validation would check for constraints on the Project shape and wouldn't find any constraint for the task resource. I think this should not be an intended behavior and users should have the possibility to discriminate between different shape trees when validating a certain resource.

My solution is to add to the shape tree namespace a property similar to this one:

:targetClass  
    a owl:ObjectProperty ;  
    rdfs:domain :ShapeTree ;  
    rdfs:range rdfs:Class ;  
    rdfs:comment "Specifies the class of the managed resource"@en ;  
    rdfs:isDefinedBy <> ;  
    rdfs:label "targetClass"@en .

And so for example the TaskShapeTree could look like this:

<#TaskTree>
  a st:ShapeTree ;
  st:expectsType st:Resource ;
  st:shape pm-shex:TaskShape ;
  st:targetClass pm:Task .

And the validateResource algorithm could check if the shape tree has a st:targetClass property and, in that case, if the targetClass is the same of the class of the resource.

Dominant language
Bikeshed
Stars
58
Forks
18
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from solid/data-interoperability-panel

All issues in solid/data-interoperability-panel

Similar issues

More Documentation issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.