3 ms·

CSS/HTML are not meaningfully semantic; they encode presentational attributes of documents and applications. Syntax validation is not semantic; it's syntactic.

by lambda 11y ago

CSS/HTML are not meaningfully semantic; they encode presentational attributes of documents and applications. Syntax validation is not semantic; it's syntactic. DOM is not either; it's an API for manipulating HTML, generally used for presentational purposes. RDF is designed for semantics, but no one of interest uses it. HTTP is a transport protocol; it's a way to take an opaque URL plus some persistent state and get a blob of text or binary data back, along with just the barest of semantics about which requests are intended to make persistent changes server side. MathML is this weird semantic/presentational hybrid, of which I have only ever seen the presentational side used; I am aware of no real-world systems that produce or consume the semantic subset of MathML. PNG is an image encoding format. So out of all of that, RDF and MathML are the only things that even attempt to define any kind of semantic encoding, and as far as I can tell they completely fail at that in the real world. For the vast majority of real world services, if you want to extract semantic data out of them you use JSON.

icebraining 11y ago
For the vast majority of real world services, if you want to extract semantic data out of them you use JSON. JSON is just the encoding, not the data model; it doesn't work at the same level. That's why RDF/JSON and JSON-LD exist. Without disputing the idea that the implementation of the Semantic Web is a failure, this idea that JSON (or XML, for that matter) is a data format is holding us back. Every provider is saying that they output in a "standard" format (JSON), while we keep writing new clients for each and every service out there, because every data format is different and it's impossible to write common handlers. Except for a few attributes, a Github user and a HN user could have the same structure, since conceptually they're quite similar concepts. Yet, try handling [1] and [2] with the same code. The regular claim that programmers can handle more abstraction than regular people just sounds like a sad joke whenever I think about the shortsightedness and lack of self-awareness that has led to the current situation. [1] https://hacker-news.firebaseio.com/v0/user/jl.json?print=pretty https://hacker-news.firebaseio.com/v0/user/jl.json?print=pre... [2] https://api.github.com/users/octocat https://api.github.com/users/octocat
- nitwit005 11y ago
  Github users are tied to social interaction, job hiring, integration with multiple version control systems, and a pile of other crap, including systems not part of the website itself. Hacker News users are pretty much just tied to posts and comments on the site. The only piece of data that seems in common is that they both have user names. There is no reason user data should be similar across different systems. Products are generally unique, or they don't have much value. That means the data tied to a user is often also unique.
  - icebraining 11y ago
    Each site has a set of attributes, which partially overlaps. The data formats should reflect this, allowing for software clients that know the base attributes to interact with both, while still having their non-overlapping attributes. Why can't I add both profiles to my PIM software without special adapters? This is what RDF allows you to do: instead of designing a custom format, or being tied to a rigid standard one, you can simply add standard attributes to the element in an ad-hoc fashion, so the client can use whatever attributes it supports while allowing for the ones it doesn't. And if there is no standard attribute, fine, you can add custom ones as well. There's no reason the same code shouldn't be able to process HN, Slashdot and Reddit threads, for example - and even a Github issue.

by lambda 11y ago

icebraining 11y ago

For the vast majority of real world services, if you want to extract semantic data out of them you use JSON. JSON is just the encoding, not the data model; it doesn't work at the same level. That's why RDF/JSON and JSON-LD exist. Without disputing the idea that the implementation of the Semantic Web is a failure, this idea that JSON (or XML, for that matter) is a data format is holding us back. Every provider is saying that they output in a "standard" format (JSON), while we keep writing new clients for each and every service out there, because every data format is different and it's impossible to write common handlers. Except for a few attributes, a Github user and a HN user could have the same structure, since conceptually they're quite similar concepts. Yet, try handling [1] and [2] with the same code. The regular claim that programmers can handle more abstraction than regular people just sounds like a sad joke whenever I think about the shortsightedness and lack of self-awareness that has led to the current situation. [1] https://hacker-news.firebaseio.com/v0/user/jl.json?print=pretty https://hacker-news.firebaseio.com/v0/user/jl.json?print=pre... [2] https://api.github.com/users/octocat https://api.github.com/users/octocat

nitwit005 11y ago
Github users are tied to social interaction, job hiring, integration with multiple version control systems, and a pile of other crap, including systems not part of the website itself. Hacker News users are pretty much just tied to posts and comments on the site. The only piece of data that seems in common is that they both have user names. There is no reason user data should be similar across different systems. Products are generally unique, or they don't have much value. That means the data tied to a user is often also unique.
- icebraining 11y ago
  Each site has a set of attributes, which partially overlaps. The data formats should reflect this, allowing for software clients that know the base attributes to interact with both, while still having their non-overlapping attributes. Why can't I add both profiles to my PIM software without special adapters? This is what RDF allows you to do: instead of designing a custom format, or being tied to a rigid standard one, you can simply add standard attributes to the element in an ad-hoc fashion, so the client can use whatever attributes it supports while allowing for the ones it doesn't. And if there is no standard attribute, fine, you can add custom ones as well. There's no reason the same code shouldn't be able to process HN, Slashdot and Reddit threads, for example - and even a Github issue.