The Semantic Future of the Web
stackoverflow.blog
stackoverflow.blog
The semantic web was much more than bots. It meant transformability and adaptiveness of information. Braille displays are just as important as print, web, screen and other targets.
Sadly modern day web browsers have such less support for it that they even dropped the media device targets from the CSS spec, which I think is morally wrong.
Did you know that screenreaders, palm PDAs and others all had support for it...and that publishing to a new platform was as easy as linking a new stylesheet? None of that HTML5 crap was necessary. No modernizr, no JS, no pixelperfect designs necessary. It just worked. XHTML 1.1 strict ran everywhere. And by everywhere, I mean even the mobile audiobook players that used the DAISY format. Fully automatically transformed, and voiced over content.
Imagine a web where you could train your personal assistant without any machine learning, and where information is automatically connected, researched, gathered and related.
That kind of internet is the necessary step for our species to reach a superintelligence level.
Without it, humans will stay as dumb as the internet is right now. Full of misinformation, deceit, and financial players "shaping" public opinion and manipulating the truth.
The Semantic Web also came with the idea of separating content, design and functionality; and came with the idea of having optional JS rather than integrating it to build intermixed components and (ab-?)using it to build a web page.
Personally, I think that this is a view on "how to build a website" that a lot of web developers lack these days, because they just clutter their web page full of JSX and don't care about how it looks like - as long as it is a pixelperfect implementation of what they are tasked to implement. Webpack and others just minify it anyways, so nobody cares whether or not their code can be read by humans.
The difference to how web development was perceived back then was that a handcrafted website was worth much more, and developers would argue and defend their implementations with things like "but it's validated, and it has print stylesheets!".
But anyways, with that experience comes a lot of understanding what the Web used to be: It was a web of craftsmanship, and not a web of advertisement. People were proud of what they built.
Personally, I hope that people value my craftsmanship; so my personal websites all have code that I can identify myself with and that I'm proud of. So my portfolio includes a lot of gimmicks for kids, people, and likeminded people that they can explore and be fascinated with. [1]
Coming full circle to what I hope the web could be: I think that a mixture of the Semantic aspects and today's Web Apps are necessary, and that this can only be achieved using swarm intelligence mechanisms. A centralized way is always too proprietary to outlive its creator. Combining that with a decentralized approach for training AIs on the labels could be a glimmer of hope that the web isn't lost yet. That's why I started to build Tholian and its Browser [2]
And yet none of it really worked. CSS was never good enough because the layouts you need on different platforms require a different markup hierarchy, so either you write some transformations in CSS and some awkwardly coupled XSLT or you do everything in XSLT. But XSLT was awful for humans and awful for tools; I'm all for declarative sub-Turing languages (efforts like Dhall are wonderful) but XSLT is just bad at being one of them. Even if people made a transformation that worked for some pages, it'd fail for others, because it's impossible to write a transformation correctly for arbitrary input pages and testing every m*n combination of page + transformation is tedious and unrewarding. The only way you could make XSLT or CSS do the right thing is if your page markup was reliably consistent because you generated all your pages with the same program - but if you're generating everything from a common sources it's easier and more reliable to just generate whichever different versions of your page you want (mobile/print/whatever) from that.
People don't actually know or care about the semantics of their pages. Designers want pixel-perfect layouts because they care much more about what their page looks like than what it says, and non-designers had to use the same techniques as designers because browsers were asleep at the wheel in how they handled unstyled pages.
When showing what possibilities there are, they are used no matter by whom. For instance when I showed what is possible with inline svg in React everybody in the team bought into that eventually. Also designers are (in contrast to artists) all about creating things considering a lot of constraints. Most web designers know at least basic html so it's possible to design for and therefore work with reusable markups
To me XHTML failed because it was really painful to use (and still is). You forget one closing tag and everything fails. The amount of people using IDEs (or even XML editors) are still in the minority. On the other hand React proves that XML (JSX) can be used in a modern way. That's probably mostly due to the fact that it's not used in one big blob but modularized into more digestible pieces and the barrier to write custom functionality is really low
That's not really a problem with augmented editors and software testing frameworks. It even "lints" your code/html -- documents must be well formed.
If you show someone a tool that they can use to make something look like x, they'll use it. But what they won't do is restrict themselves to things that look right under all your different XSLT/CSS transformations, unless you make that very easy to test for, and probably not even then. Designers do work within constraints, but like anyone, if they find a cool new technique for doing part of their job better, they're going to want to use it, and not worry too much about some abstract concern of whether it's "semantic".
> To me XHTML failed because it was really painful to use (and still is). You forget one closing tag and everything fails. The amount of people using IDEs (or even XML editors) are still in the minority. On the other hand React proves that XML (JSX) can be used in a modern way. That's probably mostly due to the fact that it's not used in one big blob but modularized into more digestible pieces and the barrier to write custom functionality is really low
One missing character can make everything fail in JavaScript too, so the reason React/JSX succeeds isn't that it has a looser syntax. I agree that it's because it's easier to use, but IMO that's mainly because JavaScript is a much more expressive language than XSLT - seriously, XSLT is the worst language I've ever seen anyone produce by hand. Page-global CSS is an indimidating mess as well though, agreed - we need reusable modular components that know how to style themselves, expecting to be able to style something from the outside by fiddling with its internals is a recipe for unmaintainability.
'Morally wrong'? This is an interesting phrase to use - are you able to explain more on this?
The problem with the semantic web is that the incentives are mostly wrong. People make websites to be viewed by people. Doing the semantic stuff is work that can be difficult to get right. If it doesn't bring you visitors, why would (most) people bother.
Sure you can get fancy tools that use the data (lets ignore the scaling issues that many of them have), but fancy tools separates the data from the context, further reducing incentives (for many content creators). If they ever did take off, we would have massive spam/quality problems, because we have now separated the data from the website, with all the visual indicators of how spammy it is, which is perfect for dark SEO and other spammers/phisers.
For that matter, just look at metadata on the web in general and what a mess that is. <meta name=description (or keywords) - spammers took over and nobody use them. <link rel="next" i think old opera is the only thing to ever do anything with that metadata.
The only metadata systems that have ever worked is when the site author gets something out of it: e.g. technocrati tags, <link> to rss feeds, facebook opengraph, various google things, etc. Or on the other side, when that is their whole reason for being, like https://wikidata.org and maybe some glam stuff. Everyone making arbitrary metadata out of the goodness of their heart, and having it be of consistent quality and meaning is a pipe dream.
Not to mention the negative incentive of obliterating the walled garden which as much as it sucks is something the corporate overlords like a lot.
Allowing users to access information more directly and reducing the cost + complexity of content extraction seem like worthwhile goals.
[1] Edit: clarification: even in embedded semantic web data (microformats, etc)
That is why microformats exists. With it the visual representation is at the same time semantic and parseable. https://indieweb.org/microformats
We need to stop reading the "web" in semantic web as the post-Gutenberg form of publishing and take a step back, consider it an archipelago of (semi-)independent databases. It's about schema, not about text markup.
I wish it was different that seems to be the thought process.
I mean, its clear that all knowledge probably can't (probably can't encode all knowledge in english either), but it seems intuitively obvious to me that there exists a useful subset of knowledge that can be, given sufficient effort. I think ability to encode useful knowledge in principle in semantic triples is about the only problem the semantic web doesn't have.
It is ultimately a philosophic question about the meaning of semantics (sorry), but suggest to a modern linguist that knowledge can be grounded with predicates logic and they'll tell you "Dude we haven't been trying to do this for more then a 100 years, ever since Wittgenstein had a nervous breakdown".
It is a shame the semantic web doesn't pay attention to other fields that have studied this questions, or maybe some did and left :)
“Can not” means “has the possibility of not happening”. Did you mean: “cannot”?
And what do you know... 15 years later and I'm working for TimBL himself, figuring out if we can make it work this time with personal data and changed (legislative) incentives. Who knows :)
schema.org is a godsend, because it's finally a serious attempt at standardizing semantics (much like foaf did in a rather anemic attempt). I've added the relationship data type to the Concise Encoding spec [1] and look forward to exciting times!
> schema.org is a godsend, because it's finally a serious attempt at standardizing semantics
schema.org is nothing new. It’s been around since 2011 (and was a direct follow-up to earlier efforts like microformats from 2005–2010), and has been valuable to search engine listings and thus widely used ever since.
"Semantic content" is about machines using common semantic identifiers in their public APIs so that their data sets can interoperate and be used as components for something bigger.
In my view, the semantic web is a set of interoperabilty standards for databases. If manufacturers and merchants publish data on products and prices it would be nice if they could do that in a way that lets us easily merge, repurpose and analyse that data.
The data is already structured and stored in databases. So no one needs to mark up anything. What they would have to do is create a mapping from their proprietary database schemas to a set published schemas.
In principle this is nothing new. We had structured data exchange formats for decades before the web even existed. What the semantic web standards add is a more formal way of specifying such data exchange formats.
Traditionally, each data exchange format was an island with no formal connections to other data exchange formats. The semantic web standards make it easier to combine data from different sources across different schemas because they allow us to formally describe how these different schemas are related.
Also, we need to consider what the role of machine learning should be. We have a lot of normative data that shouldn't need to be approximated.
For instance, accounting rules should not be approximated with 96% accuracy by a 175 billion parameter neural network. These rules should be specified and interpretable with 100% accuracy on a 5 year old phone.
Similarly, what goes into a gadget is decided by the manufacturer. It's not desirable to learn that information by extracting text from product descriptions on the web and applying huge NLP models. Sometimes that's the only way we have, but it's certainly not a desirable state of affairs.
Knowledge representation and reasoning languages like RDF, SPARQL etc., as well as querying languages like XQuery, go in this direction in principle. However, at least personally, I find them too inconvenient to use, too limited, and also not coherent enough to use them in actual rule-based automation tasks that involve semantic reasoning.
In my opinion, there is tremendous opportunity in making flexible rule-based reasoning about web content and interfaces more easily available in web applications, especially in heavily regulated areas such as accounting which you mentioned, and in governmental applications and legal use cases. For instance, using open standards, a government could describe for other governments how to automatically derive certain evidences and logical consequences of existing regulations, such as whether a company is eligible for a grant, whether a lawyer has certain qualifications in that country, whether and under what provisions a product can be sold in that country etc. By plugging in the pertaining data, many logical consequences can be automatically derived.
However, this demands more than the proposed semantic web technologies give us currently. As I see it, such use cases would benefit most from programming languages that let us not only express rules, but flexibly and easily reason about the rules themselves too, so that they can be easily interpreted, checked, simplified etc. automatically.
I think RDF missed a huge opportunity: In particular, Datalog syntax could have been used to describe RDF data, and that would have enabled easy reasoning about RDF triples with existing standardized programming languages that are ideal for reasoning about rules that represent knowledge, and are also expressive enough to dynamically compute and fetch more data when necessary. I hope that future work on the semantic web will lead into this direction.
It’s not Datalog, but the Apache Jena inference api caters to these concerns: https://jena.apache.org/documentation/inference/
Or is there something particular about Datalog, other than that it already exists, that is missing?
In my opinion, all these languages fall short for the reasons I mentioned: In particular, even though one can express knowledge and rules in these languages, they do not allow convenient reasoning about the rules themselves, for example in order to dynamically interpret them with custom execution strategies.
Jena suffers from the same shortcoming. The documentation you link to shows an example that illustrates the issue:
Model rdfsExample = ModelFactory.createDefaultModel();
Property p = rdfsExample.createProperty(NS, "p");
Property q = rdfsExample.createProperty(NS, "q");
rdfsExample.add(p, RDFS.subPropertyOf, q);
rdfsExample.createResource(NS+"a").addProperty(p, "foo");
InfModel inf = ModelFactory.createRDFSModel(rdfsExample);
Datalog makes this easy, because every Datalog knowledge base is also a valid Prolog program, and every Prolog program is a sequence of Prolog terms. Hence, we can use Prolog to easily reason about knowledge and rules that are stated in Datalog or Prolog syntax. This ability is what I miss most severely in the current semantic web stack.
https://jena.apache.org/documentation/ontology/#ontology-cla...
https://jena.apache.org/documentation/ontology/#ontology-pro...
where you can apply sub/super classes and define a property as disjoint/transitive/equivalent to other properties.
I guess at that point I would wonder how much more is really practically necessary for a 'web of semantic data'. Imo, that's already over-powered for the basic use case which is linking one schema and its properties to another and defining an exchange protocol via the linked data platform.
Again, I admit I'm not very familiar with these things and I appreciate you taking the time to read through this stuff.
The point is, you need these pioneers to help get the technology off the ground.
When it comes to augmenting digital assistants like Alexa or OK Google, standalone semantic knowledge bases like Wikidata [0] seem good enough. And as natural language understanding code gets better at interpreting user queries, so too does it get better at ingesting unstructured knowledge, such as raw Wikipedia articles, without need to resort to structured meta-tags.
https://searchengineland.com/wikipedia-confirms-they-are-ste...
https://news.ycombinator.com/item?id=23477201
https://hackernoon.com/how-wikipedia-lost-3-billion-organic-...
Further, getting everyone to agree on semantics is impossible.
You can already see this in action on soundcloud. Search for any music category and you won't be 5 songs in until you find a song that doesn't fit the category. Whether that's because the creator legitimately thought the tag belonged or if they just thought it would get them more listens it doesn't really matter. What matters is the tags become useless
I see this on many sites.
Stack Overflow uses tags to add semantics. It only kind of works because of a vast army of volunteers fixing the tags.
I view the SW as part of knowledge representation, thus part of AI.