field33 / plow Goto Github PK

To provide a better onboarding experience, as well as faster setup in CI settings, we are looking to provide pre-built binaries for the Plow CLI.

Update:

• We now provide prebuilt binaries (under the "Releases" tab) for Linux
• Prebuilt binaries for macOS (and Windows) are blocked on getting them building in CI

When trying to set up integration tests for plow protege/plow update, I ran into the problem that apparently on the /v1/artifact/signed-url/<cksum> route, requests without a valid token are not authorized, even for public fields.

Things to do here:

• Adjust backend so that requests for fields without an Authorization header are permitted
• Adjust the logic in plow_cli/src/resolve.rs to not send an Authorization header if the field to be retrieved is public

Right now the way to browse all fields is done via listing all fields on the index page under the "recently updated" section, which won't be tractable in the long-term as the amount of fields in the registry grows.

Instead, there should be a dedicated page that allows for browsing all packages in a paginated manner (and restricting the "recently updated" section to the ~20 latest)

This URL works:

https://registry.field33.com/field/@foaf_mirror/foaf/0.99.0

This one doesn't:

https://registry.field33.com/field/@foaf_mirror/foaf

It should be possible to link to a field without having to specify an explicit version. This will make it a lot easier to allow for external sources to link to a field (e.g. also to support #20).

Right now we have two main ways that a set of field dependencies are usable:

• Via the CLI via the plow protege command (downside: format specific to Protege)
• Via the libraries (downside: not usable via the CLI)

To be better usable across a wide variety of tools it would be good to make the output of the dependency resolution and retrieval process accessible in an easy to digest way, which any other tools could integrate with.

E.g. we could have a plow install command, which places (or symlinks) the retrieved fields into a directory inside the workspace (e.g. plow_fields as an analogue to node_modules), together with metadata that would make it easy to load those fields.

To support web crawlers in discovering relevant pages, it usually helps to provide a sitemap.xml that lists all important pages on the website (in our case all individual field pages). See https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap

The Plow.lock currently contains "generated by Field33" in the auto-generated warning:

It should reference Plow and not Field33.

My suggestion would be generated by Field33 -> generated by the Plow package manager.

Plow init currently generates a registry:fieldFormatVersion, which deviates from the registry:ontologyFormatVersion, which we assume at every other location in the tooling.

The ontology registry seems like a great idea. It would be nice if I could read a bit about what types of entities and relationships the ontology describes directly on the site rather than looking up the ontology elsewhere (or following the Github link). Also, you could embed WebVOWL on a tab in the page so users could explore it visually.

It would be great to have pages like /namepsace/@fld33 which list all packages from the @fld33 namespace. For projects that maintain multiple packages rather than a few individual ones, this would provide them with a better link.

plow init currently generates an ontology document with all the required values prefilled to default values.

While this certainly provides a low-friction way towards submitting the ontology, this will likely result in all those metadata fields not being changed by most ontologies, and all those packages being published by "John Doe", etc..

I am not sure, if this repository is the right place for my request. Please move, if it isnt.

When opening an ontology in Plow Registry (like https://registry.field33.com/field/@fld33/people/0.1.5), the file given under Download has a name which consists of random letters and numbers.

Is it possible to use the name of the ontology plus the version I selected? For the mentioned link it would be people-0.1.5.ttl. That would make it easier in case someone starts to download and check a couple of your ontologies.

Description

We want to support consuming public ontologies without the need to login. However currently the private index (which requires a login) is retrieved on every plow command.

Instead the private index should only be retrieved if a package name is encountered that cannot be found in the public index.

With asdf, which has a plugin system, we could "easily" get a version manager for the plow CLI itself.

Most likely blocked by #1

Description

The goal is to extend the CLI tooling towards opening an ontology with its dependencies in a GUI-driven Editor such as Protégé. By that, we want to increase accessibility beyond editing ontologies and their dependencies in a Code Editor only.

Badges in READMEs can be a really good way to improve the developer experience for an ecosystem, as they can provide a consistently recognizable link to a website with more information (like the registry) in an otherwise unstructured (= of always varying structure) block of text.

Shields.io provides the commonly used service for that (with integrations to all the popular package managers): https://shields.io/category/version

Examples for what the badge could look like:

This is a twin issue to bazel-contrib/bcr-ui#29 which I want to tackle at some point. Depending on where I get around to implementing it first, I think we can benefit from the experience.

right now crates.io does not show the README.md for any of the crates published.

Hey @hobofan, feel free to submit a PR to showcase your project!

• SeaQL/sea-orm#403

Would be great to have tests covering macOS (both aarch64 and amd64) in CI.

More or less a blocker for providing prebuilt binaries for macOS in #1.

This may be simplified by removing the dependency on OpenSSL (maybe switching to rustls where possible).