NGI Search

[hoijui]

NOTE
This first post will not be modified after 29. July 2024 at 17:00, except typos. This can be verified by clicking on "edited" above.

In July 2024, we applied for NGI Search funding. If we get accepted, this issue will serve as the organizing hub for the technical part of the proposal.

We selected these 19 initial issues as candidates to be solved within the funding period.
We pledge to solve at least 7 of them.

• Sensitive HW project topics (ethics, safety, ...) #147
• Feature Request: "Atomize" BoMs (for Helpful Engineering) #145
• Allow to generate the JSON-Schema from the RDF #2
• Add "requiredness" info to RDF properties #8
• Naming Convention (for the ontologies RDF Terms) #13
• Modularity issues #11
• Register our standard/ontology with indices #18
• Request: New spec field for a rating (project likes, stars, ...) #21
• register OKH-LOSH at OntoCommons #22
• Document TOML -> RDF mapping in a machine-readable way (in RDF) #24
• forkOf exists in RDF, but not in the markdown spec #27
• Register JSON schema(s) with schemastore.org #34
• Image type/description/category #35
• TOML definable RDF base IRI #38
• Image description/alt-text for people who can not see #43
• Can we get rid of alternativeLicense? #45
• okh:repo - Web-View or git (clone) URL? #94
• How to ensure a documentation is uniquely defined/referencing an unmutable binary blob #98
• Standardize machine-readable project name #39

Apart from these, which are all directly related to the standard,
we will also work on related tooling:

• owl2shacl

  description

  Converts an OWL ontology (e.g. the OKH standard specification) into SHACL, which can be used to check if hardware project data in the RDF format conforms to the standard, or to automatically generate web forms to enter and edit data in this format.

  • develop current alpha to a first release;
    verified by producing meaningful results for these ontologies:

    • okh
    • okhmeta
    • vf

• owllint

  description

  Checks an OWL ontology against best-practices, as defined partly by LOV in their documents: Ontology meta best practise & Ontology HTML version best practise & related paper. Or by us, in a document that will also be created.
  • initiate development and move till beta state, optionally a first release;
    verified by checking all properties described in Metadata Recommendations For Linked
    Open Data Vocabularies

• ttl2pretty

  description

  Pretty-prints RDF/Turtle files. This can be used both for the ontology as well as for the data. This is crucial for machine- and human optimized git diffs, to reduce merge conflicts, and for humans to find their way around faster within an RDF data file or ontology.

  • initiate development and bring to a first release;
    verified by:

    1. prettifying all (valid) RDF/Turtle files in the history of this project
    2. providing a set of small before-and-after samples for visual verification
    3. provide a sample git session that produces merge conflicts, and then show how they could be avoided by applying the tool

• owl2jsonscm

  description

  Converts an [OWL] ontology into [JSON-Schema], which can be used to check if hardware project data in TOML, JSON or YAML format conforms to the standard, or to automatically generate web forms to enter and edit data in this format.

  details

  This will likely pose a big challenge, and might even prove to be overly complex to the ontology creator, to the point where it will be impractical. In that case, we would document our findings well, and close the case without further pursuing this.

  Consequently we would also have to re-consider the whole TOML & JSON & YAML secondary format idea.

  • initiate development and make a first feasibility study;
    verified by either a working alpha version, or a report explaining the infeasibility

[hoijui]

The following 4 topics we want to work in are from our NGI Search application. The sub-lists are potential software candidates. We will not be able to work on all of them:

• Linters: Checks standards for validity and adherence to best practices
  • for RDF
  • for Ontologies (OWL)
• Pretty-Printers: Consistently formats standard and data for optimal git workflows
  • ttl2pretty - RDF/Turtle
    • special case for OWL (identified if an owl:Ontology is present (NOE: or is there an other way? *.owl is XML only))
  • nt2pretty - N-Triples is a very simple, text-based RDF serialization format that is efficient to parse
• Validators for Data: Checks whether a HW projects data adheres to the standard
  • owl2shacl - SHACL can be used to validate RDF data
  • owl2jsonscm - JSON-Schema can be used to validate JSON, YAML, TOML and similar formats, and to generate GUI forms to create and edit the data.
• Converters : Translate the standard into different formats
  • owl2shacl (yes, fits here too)
  • owl2jsonscm (yes, fits here too)
  • owl2md - Human-Readable only Markdown (can then be converted to HTML and PDF as well)

[hoijui]

Milestone	Date	Deliverable No.	Deliverable Name	Budget split
2 - Development of the MVP (TODO)		2.1	TODO
		2.2	TODO
		2.3	TODO
	End of March 2025			Total: 75,000.00
3 - Completion of the Technology adoption Plan (TODO)		3.1	TODO
		3.2	TODO
		3.3	TODO
	End of June 2025			Total: 45,000.00

[hoijui]

1. Milestones proposition

2 due end of March 2025

2.1. Linters for RDF & OWL

• with at least 3 rules each
• demonstrated with a short sample RDF
• applied on the following real-world Ontologies:
  • Open Know-How (OKH)
  • ValueFlows (VF)

2.2. OKH Indexer sample server

• maintains a LinkedData DB with meta-data about OSH projects hosted on different platforms
• hosted by OSEG
• filled with the latest available data at milestone submission from at least these platforms:
  • https://github.com
  • https://gitlab.com
  • https://appropedia.org
• with a public SPARQL endpoint, reachable through:
  • Web GUI
  • Web API

2.3. Solve 7 issues

• of the ones linked to in
  NGI Search #146

3 due end of June 2025

3.1. Turtle/RDF pretty printer

• optimized for diff minimization (=> optimized for git)
• two sets of rules:
  • simple - no special cases in sorting
  • Ontology - group class & property subjects, and maintain a fixed order for some special properties within a subject

3.2. OWL to SHACL converter

NOTE: This is highly controversial and experimental, but practical to have in most scenarios where the ontology is mostly representing a kind of distributed DB Schema.

• applied on the following real-world Ontologies, producing valid SHACL:
  • Open Know-How (OKH)
  • ValueFlows (VF)
• The generated OKH SHACL will be tested on the data gathered in Deliverable 2.2

3.3. TODO

Still free - maybe some community testing and feedback?

[hoijui]

Final milestones:

Deliverables

D 2 Implementing

Development of the MVP and (if applicable) Business Plan

Due Date: End of March 2025

D 2.1 Linters for RDF & OWL

Responsible: Robin Vobruba (@hoijui)

D 2.1.1 Description

Software that auto-checks these formats against best-practice.
This should help mediate the huge issue of quality in the RDF world,
by doing it automatically on each git commit to an ontology in CI.

D 2.1.2 Means of Verification

• with at least 3 rules each (RDF & OWL)
• demonstrated with a short sample RDF
• supporting RDF/Turtle as input
• applied on the following real-world ontologies:
  • Open Know-How (OKH)
  • ValueFlows (VF)

D 2.2 OKH Indexer sample server

Responsible: Robin Vobruba (@hoijui)

D 2.2.1 Description

Maintains a LinkedData DB with meta-data about OSH projects
hosted on different platforms,
and will be hosted and maintained by OSEG.

D 2.2.2 Means of Verification

• filled with the latest available data at milestone submission
  from at least these platforms:
  • https://github.com
  • https://gitlab.com
  • https://appropedia.org
• with a public SPARQL endpoint, reachable through:
  • Web GUI
  • Web API

D 2.3 Solve 7 OKH issues

Responsible: Robin Vobruba (@hoijui)

D 2.3.1 Description

of the ones linked to in
#146

D 2.3.2 Means of Verification

7 OKH issues closed

D 3 Adopting

Completion of the Technology Adoption Plan.

Date of Planned Delivery:
End of June 2025

D 3.1 Turtle/RDF pretty printer

Responsible: Robin Vobruba (@hoijui)

D 3.1.1 Description

A software that re-writes a turtle file
to have minimal variance/diff between changes.
This helps when different people work on the same RDF file in a repo,
and/or different GUI tools are used to edit it,
to not create a huge mess in the history.

D 3.1.2 Means of Verification

• two sets of rules:
  • simple => no special cases in sorting
• ontology => group class & property subjects,
  and maintain a fixed order
  for some special properties within a subject
• if at all possible:
  minimize Blank-Node variance between serializations

D 3.2 Hardware Browser & Demo Interface

Responsible: Timm Wille (@timmwille)

D 3.2.1 Description

A web page backed by an OKH index server,
that allows to easily search for OSH projects,
and presents all meta-data in a palatable way.
It also provides a good overview of the project ecosystem.

D 3.2.2 Means of Verification

• a project can be viewed in detail
• A landing page that links to the above search,
  and to graphical explanation of the OKH search ecosystem -
  pleasant to the human eye -
  including links to all the tools sources
• Demo: Hosts an instance of all the above an a publicly reachable web address
• Press Material & References

D 3.3 Outreach and adoption activities

Responsible: Timm Wille (@timmwille)

D 3.3.1 Description

Community targeted communication and efforts
to scale the implementation and enable collaboration.
Cross-Community posting and continuation strategy.

D 3.3.2 Means of Verification

• Information Campaign to scale the adoption shared via
  • Linked Open Vocabularies (LOV) Community
  • Social Media
  • Blog/Forum
• Implementation Concept for Continuation of the Project
  • regular public Meetups
  • motivate LOV Website implementation
  • active Developer Communication Channel