Comment by burakemir | Hacker News Reader

Comment by burakemir | Hacker News Reader

RDF comes with this whole set of W3C standards, and standardization seems to be a big point in favor if you need to care about interoperability.

In terms of data model, RDF may be a bit too web centric to be approachable. Linked Data does not seem much better.

This may not be a fully informed view, but so far I think: While the whole area of (broadly) logic-based representations (including datalog, eg. Souffle, datomic, ...) seems to have a bit of a renaissance, all the semantic web stuff seems a bit more like baggage.

In other words: if I wanted to build a private knowledge base, I don't want to pick or publish URIs and the fact that all the documentation pushes me towards open/sharing is just getting in the way.

In contrast to that, relational databases tech has affected programming languages and frameworks over the decades and goes way beyond triple/quads (e.g. LINQ, or relational mappings). This seems to be a big missed change in a way since, some of the "typing" would in principle be a lot closer to class-based OOP then all the relational stuff.

> In other words: if I wanted to build a private knowledge base, I don't want to pick or publish URIs and the fact that all the documentation pushes me towards open/sharing is just getting in the way.

RDF supports "blank nodes" for this use case. These are URI-less nodes that can only be referenced within the graph where they're defined. You'd use URI for reference to outside entities, which can be very relevant even in a private knowledge store.

Blank nodes are one of the contested flame warzones of RDF.

The fact that they don't have a reified instance means that they are open to collapse with other blank nodes in certain inference scenarios and makes a lot of problems as hard as graph isomorphism.

Much better to go with plain old UUIDs instead.

RDF uses an open world assumption so "collapse" is always a possibility. That's why there are features like owl:DifferentFrom and related properties.

What you mean is the unique name assumption, which is distinct from the OWA, and may be viewed orthogonally and applied or not applied in different RDF contexts.

The problem with blank nodes is that they circumvent the UNA in every scenario, and you need something like "reified blank nodes" to resolve this, a.k.a. by using UUIDs treated as blank nodes.

See the following paper for a more in-depth discussion on the topic https://aidanhogan.com/docs/blank_nodes_jws.pdf

URIs a mostly namespaces, it has no bearing on being private data. If you know what your doing you’ll be using ontologies made by others, and like having a namespace for a library you’ll want the same for the terms/classes you use from them.

>In other words: if I wanted to build a private knowledge base, I don't want to pick or publish URIs and the fact that all the documentation pushes me towards open/sharing is just getting in the way

To be fair, i think that is kind of like saying, if i don't care about RDF's primary intended use case, then RDF is a bad choice.

I honestly don’t see it matters, it’s a nice option but being open data is totally optional.

Any opinion on SHACL?

I heard SHACL helps with specifying structure (shape), and more so than OWL which is more about meaning (and where it may be acceptable to have an incomplete but "open" specification).

Programming with these structures (triple/quad with shape constraints) would be interesting, general-purpose programs could not easily take advantage in the form of static type-checking. This is roughly the same type of problem as the "object-relational impedance mismatch." I believe some kind of type-checking (shape-checking?) for SPARQL queries might be possible, but don't know if any such thing is implemented.

Reply on news.ycombinator.com