plow

Plow - The ontology package manager (by field33)

Plow Alternatives

Similar projects and alternatives to plow based on common topics and language

  • Protégé

    Protege Desktop

  • w3id.org

    Website source code for w3id.org.

  • InfluxDB

    Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

    InfluxDB logo
  • manas

    Manas project aims to create a modular framework and ecosystem to create robust storage servers adhering to Solid protocol in rust.

  • LinkedDataHub

    The low-code Knowledge Graph application platform. Apache license.

  • linkml

    1 plow VS linkml

    Linked Open Data Modeling Language

  • WorkOS

    The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

    WorkOS logo
NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a better plow alternative or higher similarity.

plow reviews and mentions

Posts with mentions or reviews of plow. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2023-11-10.
  • Protégé: A free, open-source ontology editor for building intelligent systems
    3 projects | news.ycombinator.com | 10 Nov 2023
    Yes, consensus in ontology building has traditionally been a huge drag for the adoption of ontologies.

    However, I don't think the core issue is consensus itself, but instead that the prevalent form of consensus in the ontology authoring space is consensus by committee rather than consensus by usage (as is usual in the open source software space).

    That's why I've in the past been involved in creating Plow[0], a package manager for ontologies, with the aim of bringing the same "grassroots" nature and network effects that you find in other open source ecosystem to ontology engineering.

    [0]: https://plow.pm/

  • Plow: The ontology package manager
    1 project | /r/semanticweb | 27 Mar 2023
  • Ask HN: Why are URNs not more popular?
    2 projects | news.ycombinator.com | 7 Jan 2023
    I think this probably covers it the best.

    In terms of the semantic web, trying to semantically interpret the URN (as OP suggests) also seem like a conceptual mismatch, as there are other mechanisms that allow for the same thing in a more "robust" way.

    E.g. in RDF one could pack all the semantics into the datatype of a literal like `Norwegian account number "12345678902"` -> "12345678902"^^<http://example.com/accountNumber/NO> (where the IRI `http://example.com/accountNumber/NO` then serves as an identifier for a concept that can be enriched with more information).

    > Often http is used instead, where the domain name serves the role of the namespace, because usually a suitable domain name is already registered. Of course, this latter practice has the drawback that one has to infer from context that it is a name and not an HTTP web resource.

    At least in RDF-world (which admittedly isn't the only domain for URNs), this by now doesn't have to be inferred, but has over time formed into an undeniable reality.

    In RDF from the beginning IRIs have been relegated to identifiers ("It only treats IRIs as globally unique identifiers" - RDF specification[0]) though it has been mixed with a lot of weak language/suggestions to also use IRIs as locators. And a lot of people/institutions did attempt to make follow that suggestion. However, since it's a lot harder to host a system in continuity that delivers content based on an URL (as evidenced by all the link-rot in the semantic web space) than it is to just coin IRIs, using IRIs as locators so rarely worked in practice that nowadays nobody even tries to do that anymore.

    -----

    DISCLOSURE: Self-promotion

    Born out of the frustration of this issue (and some other issues, such as uncontrolled mutability when using IRIs as locators for semantics), we have built a package manager for ontologies[1] to serve as a foundation for stable semantic data systems.

    In it we replace the fickle "maybe an IRI can be dereferenced to semantics" system of RDF/OWL with a package manager that allows for stable versioning and resolution of all the ontological dependencies of your system, so you end up with a stable set of documents that you can then interpret to get to the underlying semantics of an IRI.

    Since there is a default registry[3] that even small projects can publish to, this also greatly reduces the barrier to entry for small projects to participate in building and publishing ontological definitions, as there isn't a burden of setting up and maintaining the hosting of the definitions.

    We've been using that system for close to a year now as the underpinning for our platform[2], and it's been great so far. It allows us to offer different semantics to different customers (based on the packages they chose to import), and makes managing even a big set of often-changing semantic dependencies tractable.

    [0]: https://www.w3.org/TR/rdf11-concepts/#referents

    [1]: https://plow.pm

    [2]: https://field33.com

    [3]: https://registry.field33.com

  • The sum of all knowledge and the sorry state of the web
    1 project | news.ycombinator.com | 23 Sep 2022
    (Warning: Personal plug incoming)

    I fully agree, especially when it comes to the "semantic" part of the semantic web. Reusing and publishing ontologies that define those ontologies always seemed like an afterthought of the semantic web, when it should be part of the foundation that things on the semantic web are built on.

    In most other parts that make up a website (JS and HTML) we figured out how to make reuse (mostly) work by replacing flimsy web references with package management. Ontologies never had something like that, and thus were stuck in an early 00s era of software/ontology development.

    Where I work, we are building Plow, a package manager for ontologies (https://github.com/field33/plow) as part of our tech stack to improve that situation and allow people to build applications with large-scale stable semantics at the core.

  • A note from our sponsor - WorkOS
    workos.com | 26 Apr 2024
    The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning. Learn more →

Stats

Basic plow repo stats
4
48
6.8
9 months ago

field33/plow is an open source project licensed under Apache License 2.0 which is an OSI approved license.

The primary programming language of plow is Rust.


Sponsored
SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives
www.saashub.com