I hadn't heard of RDF. I've tried to review its W3C material right now but the documentation is so abstract that I'm struggling to understand what idea it's trying to convey, or problem to solve.
I think the concepts this document is trying to convey would be a lot clearer with an example of how one might use the concept to build a concrete system, and what problem the RDF technology helps solve.
The overall description is "RDF is a standard model for data interchange on the Web." That seems to fall short from defining services and APIs, and then code generating client and/or server logic, which is the goal of Taxi and Smithy: https://awslabs.github.io/smithy/
RDF appears to be a data format, and I don't understand what benefit I'd get from using it, except perhaps that automated reasoning tools could potentially interact with my data more easily. But that is rarely a problem I have when building systems: maybe I'd consider this if I was in charge of building a government system that publishes official data to the public (and then also offer a CSV/JSON feed which everyone would probably use in practice), but when working in a private (corporate/organizational) environment, the benefits of RDF seem lackluster. The only immediate benefit I can think of would be that, using unique IRIs to represent business data types, I could perhaps see what systems across a company handle a particular type of data: but this would also be possible when using Smithy or Taxi (if appropriately reusing types and models across many interacting systems).
The data format also appears to be reasonably verbose due to the inclusion of the field name and type for every field. But many of the systems I build are RPC and the client and service already have a shared model of the data that they will be exchanging. Including RDF's additional information would seem to result in a wire format that's lower performance than something built on a toolkit like Apache Thrift/gRPC/Capn'Proto, or even hand-coded HTTP APIs (as much as I despise that approach).
What benefits would one get using RDF vs. defining an API using Taxi or Smithy, and then binding it to an efficient binary or text HTTP protocol representation? (E.g., BSON, FlatBuffers, etc.)
If I wanted to serve self-describing data I'd be more inclined to use a technology like Ion, which is very concrete and simple to understand: https://amzn.github.io/ion-docs/
The documents on SHACL are a bit clearer due to the inclusion of concrete examples, but I'm still not sure (1) what engineering problem I would face when building a system that these technologies would help me solve, and (2) is the actually usable (cross-platform) and robust, or is it largely a set conceptual ideas? There didn't seem to be many actively maintained open source projects focused on RDF.
Please feel free to let me know if I'm underestimating or misunderstanding RDF. From my skim of its docs it seems like a data format, not a way to model APIs (and get down to business of giving them concrete protocols), which seems like a very crucial distinction from the problem that Taxi and Smithy solve.
I suppose since RDF can describe "any" data, one could invent a set of data types that express operations, models, types, etc., but unless there's a standard set of types for expressing operations, models, types, and bindings to protocol interfaces, already, then you're leaving it to the developers of each service to define their own RDF representations of these things, which means that there wouldn't be similarity to modeling of these concepts across services, preventing universal automated reasoning or transformation. (Let me know if there's a spec for using RDF for defining service interfaces ... there are a lot of docs associated with that WG and I can't read them all before writing an HN comment :-)
From all of what I've read, it looks like RDF is trying to define a data format that can be understood "universally" through the definition of well known IRIs; that feels like a different problem than defining a service interface, service stubs, and client libraries, that might be used privately within an organization for building client/server systems.
RDF and similar tech does suffer from documentation that is hard to digest, and hard to see how they combine.
The semantic stack is fundamentally about how you share data, integrate it etc
Taxi seems to try and differentiate itself by describing data better (I've not looked at it deeply just some of the comments here describing it) for interchange. Also the restrictions on data, i.e. its shape (mush have property x) is what Shacl supports, which is also declarative in RDF.
There are a bunch of tools, extensions and what not out there for all this, most of which isn't grasped by average devs (don't mean that in a bad way).
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.
I think they are fixating too much on the vr aspect (ie the virtual model/graphics), I think the world you perceive via sight and sound being processed/mined and providing useful personal context aware applications is the key. For example an app that can whisper in you ear the name of every person you meet.
My prescription glasses are ray bans, I need a new pair and I’m quite tempted to get these. I like the built in headphones and I’m interested in being able to take pics of my kids easily or even anything else to be honest, but I’m not a creep and have no interest in taking pics of random people.
Yet, will it be assumed I am a glass hole for wearing these, peer pressure from the paranoid! Done nothing wrong yet judged and punished ...
