ektrah / rdf-toolkit Goto Github PK

I'm a little unclear how to get the static site generator to include new files. I checked out and built a current copy of the latest code, and ran
npx rdf make site
and then
npx rdf serve

and saw the base - owl, rdfs, and rdf

Then, I downloaded a copy of Brick.ttl and put it in explorer/vocab, and from explorer/ I ran
npx rdf add file "https://brickschema.org/schema/Brick#" vocab/Brick.ttl

and then ran npx rdf list files and I got

npx rdf list files
  ╤
  ├╼ <http://www.w3.org/1999/02/22-rdf-syntax-ns> → vocab/rdf.ttl
  ├╼ <http://www.w3.org/2000/01/rdf-schema> → vocab/rdfs.ttl
  ├╼ <http://www.w3.org/2002/07/owl> → vocab/owl.ttl
  ╰╼ <https://brickschema.org/schema/Brick> → vocab/Brick.ttl

but when I restart the 'serve' and visit, I don't see any of the brick classes. I do see it listed under 'files' so I hope I was on the right track:

but I think I'm missing a step.

I am a bit confused on something - I'm not saying that you should use jQuery, but let's say there was a good reason to do so. Just as a test, I cloned the repo and ran 'npm install jquery', and then I added this to packages/explorer-site/src/main.ts - which right now is the a window click handler:

window.onclick = function (ev) {
    let target = ev.target;
    while (target instanceof Element) {
        if (target.tagName === "A") {
            const href = target.getAttribute("data-href");
            const rel = target.getAttribute("rel");
            if (!rel) {
                ev.preventDefault();
                if (href) {
                    window.location.href = href;
                }
            }
            break;
        }
        target = target.parentElement;
    }
}

$(function(){
      alert("Hello from jquery!"); 
    });

This doesn't work - the compiler complains:

> @rdf-toolkit/[email protected] prebuild
> tsc --noEmit

src/main.ts:19:1 - error TS2581: Cannot find name '$'. Do you need to install type definitions for jQuery? Try `npm i --save-dev @types/jquery`.

19 $(function(){

So I took its suggestion of adding the types and ran npm install as it suggets, but then all heck broke loose:

> @rdf-toolkit/[email protected] build
> tsc --build


> @rdf-toolkit/[email protected] build
> tsc --noEmit

../../node_modules/@types/jquery/JQuery.d.ts:5:29 - error TS2552: Cannot find name 'HTMLElement'. Did you mean 'TElement'?

5 interface JQuery<TElement = HTMLElement> extends Iterable<TElement> {
                              ~~~~~~~~~~~

../../node_modules/@types/jquery/JQuery.d.ts:85:45 - error TS2304: Cannot find name 'Element'.

85     add(selector: JQuery.Selector, context: Element): this;
                                               ~~~~~~~

../../node_modules/@types/jquery/JQuery.d.ts:230:80 - error TS2304: Cannot find name 'Element'.

230     add(selector_elements_html_selection: JQuery.Selector | JQuery.TypeOrArray<Element> | JQuery.htmlString | JQuery | JQuery.Node): this;
                                                                                   ~~~~~~~

../../node_modules/@types/jquery/JQuery.d.ts:534:34 - error TS2304: Cannot find name 'Document'.

(lots more not included)

There are a lot of types in explorer-views/src/jsx/ - was that you building out some minimal subset of what types you needed for the little bits of JSX you're using? Are there other libraries for those you'd consider using that might be more jquery-friendly?

This might not matter if jquery never gets added, but I was just wondering about how the code in explorer-views relates to the bigger picture.

• What is "schema" compared to "properties"? I loaded our internal ontology and all the properties are repeated at the schema. I'd like to understand the reasoning behind "schema" and possible hide it optionally?

• I see stars and question marks left to every property. Could you explain what they mean?

• Can we make the tree frame horizontally configurable? If the hierarchy is too deep, the text gets ugly. E.g.,
  

• I agree with #1 and maybe we can specify the top level classes we are interested in inside package.json and ignore the rest in the tree view?

• I have properties whose values are actually an enum (and I'm surprised that those are well-visualized!) but the number of values of the enum can be long. Can we make each cell collapsible if it's too long?

For all those questions above, I'd be happy to ask my company's engineer to contribute if you can share any pointers.

I think as a good start towards making the UI more precise, perhaps the first step is filtering out some of the classes. Maybe that could be entirely based on namespace - like, I don't think in main class browser the owl classes are critical to display in the tree viewer.

(Maybe they're worth keeping around in the detailed view for individual classes, to be able to say what something is inherited from)

By way of setup - the current Brick ontology site (https://brickschema.org/ontology/1.3/ ) has a search bar that's specifically for the classes/relationships/properties in the ontology. I said earlier it uses lunr, I was wrong - it uses fuse.js ( https://github.com/krisk/fuse ) and then a vue-fuse wrapper (https://github.com/shayneo/vue-fuse ) to do a client-side search. The Brick website loads a JSON document for the search terms - the code is here ( https://github.com/BrickSchema/brick-website/blob/master/src/components/OntologySearchInput.vue ) and the JSON it loads is here: https://brickschema.org/ontology/1.3/search.json?version=1672180766783 )

Related, the Ontology page builds its nav bar from a related-but-smaller JSON document here: https://brickschema.org/ontology/1.3/tree.json?version=1672180766783 and then a Vue component builds all of that out from here: https://github.com/BrickSchema/brick-website/blob/master/src/pages/Ontology.vue

tree.json is pretty bare-bones. search.json includes a couple of fields that are indexed and used in the search - besides the class name, it includes the description of the class
(I don't think there's any reason we had to have the tree and search as separate documents, probably just made coding easier)

The Brick website is kind of an adventure - it uses Gridsome as its static site generator. Gridsome is a very different beast than something like Hugo/Jeykell/Pelican/other static site blog generators - Gridsome builds out a full backend with graphql and everything and then bakes out a static site from that.

It's very confusing, and I think this is what's happening, but I might be wrong. I think the full lifecycle is:

There's a python script that we run first - generate_doc_src.py - but all of the interesting parts happen in https://github.com/BrickSchema/brick-website/blob/master/util.py - this runs queries over Brick.ttl to find all of the classes/relationships/etc. It writes its output into a set of files in static/ontology/ and creates the tree.json and search.json that get read for the ontology.

The actual pages for each class/relationship/etc get read and built in the Gridsome and outputted after someone runs gridsome build to create the site, Gridsome reads those files and creates a tree of pages for each class in https://github.com/BrickSchema/brick-website/blob/cb4aa58b92dc437e6b0813e2768ef30f5fcaa621/gridsome.server.js

(Where I am a bit confused - there are two searches on the brick site -one for the ontology, and one for the rest of the pages. I think the search index that's being built in gridsome.server.js is only for the main site webpages and not the ontology pages)

After gridsome build, we copy over dist/ to the webserver. In each subdir for each version of Brick in ontology/, there's a classes.json and relationships.json (created by the python script) that you can fetch but I don't think any code in the website uses it, I think that's all driven from tree.json - but if you want them, they're there at https://brickschema.org/ontology/1.3/classes.json or https://brickschema.org/ontology/1.3/tree.json or even https://brickschema.org/ontology/all_classes.json

So anyway, we might want to do something similar - both for outputting a JSON tree that we can have a nav component load, as well as a JSON full of "documents" that includes we can load into lunr.js or fuse.js or some client side search on the names and descriptions. Maybe they're the same file or maybe we make them separate, I'm not sure what would be best - we could skip the nav bar component and go with the iframe approach but still have search with a backend JSON file.

@jbkoh

Hi Klaus,

I hope this message finds you well. I am Krish, Dr. Gabe Fierro's mentee. We used to meet during the Brick meetings on Thursdays.

I am currently trying to implement a search functionality within the navigation view.

Request:

I would like to connect with you to further complete the search functionality.

Thank you for your time and assistance.

Best regards,
Krish
[email protected]