I was extremely excited by the Semantic Web back in 2003-2005 when working on a master's in Information Science. I was sure it was 5 years away, tops. I was eagerly building profile pages using FOAF and trying hard to implement other ontologies in my work. I got a job in an academic library and pushed hard for semantic technologies. Seemed like Linked Data was such a hot buzzword and topic that we all wanted to explore but could... just.. never.. get going. In 2015 I gave it all 5 more years and then would consider it essentially "vaporware". Maybe it'll catch on someday but it's 2020 and our data is siloed as much as ever. Feel like web scraping plus machine learning is the real winner in this space, but maybe that's an unfair comparison.
As I've said elsewhere I fear that it's actually worse then a lack of economic incentives, even in a Communist utopia it won't work because knowledge can not be encoded through semantic predicates.
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.
I've ranted about this before[1] and you can read it when searching for my nickname.
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 :)
"Semantics" is a very overloaded term, but i'm not sure the goal of the semantic web matches the goals of "semantics" in other fields that you are thinking of.
I have been incredibly interested in ontologies and information science recently. So I’m wondering, what are the hob prospects like? What are you doing now? Your classmates?
I had the same feeling back then, although I was in high school. By the time I'd graduated high school it was clear that it was indeed mostly a pipe dream and how, as another comment says, the incentives are all misaligned. I grew fairly sceptical of the semantic web.
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 :)
I find it ironic that this blog post is made by stackoverflow. A company whose sole purpose is questions and answers, but whose website doesn't even have a print stylesheet.
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.
Apart from it having been introduced by W3C as part of heir 1998-2004ish push for renovating the web, I can't see what XHTML and CSS media queries have to do with SemWeb, though. There's no reason to be bitter about the failure of XML/XHTML on the web as the good parts (SVG, MathML to some degree) have been incorporated into HTML5. To the contrary, one could say W3C's fixation on XML (and RDF/sparql) gave rise to WHATWG/Google, and their vision for the appification of the web.
XML was designed as a federation of interoperable notations. The notations could co-exist and independently and organically grow and enhance the web in all ways. This is a much broader vision than what HTML turned into.
Fair point, but neither is nor was XML necessary for new vocabularies or vocabulary evolution (since SGML facilitates that already), nor has RDF/sparql anything to do with it. I'd argue that the organizational lock-up W3C has created with the long XML/XHTML meta-syntax detour and unrealistic XHTML extensions such as XForms resulted in HTML not being extended at all, while everything around it (CSS, JS) was made too powerful to cater for HTML's stagnation during that period.
I think that the way HTML5 is used these days is more as a way to build a design, rather than a way to deliver semantic content. When looking at the Alexa top 1000, you'll find not a single semantic website that cares about their markup, most of them not even having an alternative text for images.
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]
> 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.
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.
> 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
> 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.
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.
> 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.
'Morally wrong'? This is an interesting phrase to use - are you able to explain more on this?
What is there to explain? The decision to deprecate it harmed blind individuals. It's wrong to harm people, even by inaction, especially when you are a multi-billion (sometimes trillion) dollar quasi-monopolist...
Wow, this feels like something out of the mid-2000s.
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.
To be honest, I think we already have the spam/quality issues[1], it's just that web spidering systems have to wade through and discard most of the presentation-layer cruft before they begin to determine the value of the content.
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)
I think it can be summed up as people show zero constraint lying to machines. Both on the the personal and on the organizational level. The meta tag was about as truthful and useful as age verification with a big "Yes (I'm 18 or older)" button that has all the UI trappings of a default operation.
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 think that the future of the semantic web is not by adapting websites to use semantic tags (even though many of them do to some degree to work well with Google’s knowledge graph) rather APIs will start to use a semantic format (JSON-LD is a likely candidate). Unlike content, for data there is a big incentive to make it as easily understandable by machines. It can enable a whole new class of applications that use data according to well known ontologies instead of a rigid data structure (think API hyperlinks but with much less hard coding)
With AI at last hitting its heyday, semantic data will finally be important enough to enter general use. It's not a replacement for the web, but rather a supplement to it, where intelligent machine agents can automatically and intelligently navigate relationship connections to find or even infer the information you're looking for using various APIs. Tim Berners Lee was way ahead of his time with this (and ahead of computers' ability to make something useful out of it), which is why it languished for so long (much like AI did).
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!
If anything, I’d have thought AI would lead to people being lazier about marking up semantic data, because if the machine learning is good enough there’s simply no call for it. So yeah, people may consume the semantic data, but the actual markup for such semantic data could become even less important than it is now.
> 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.
It's not about people marking up HTML to add semantic data; that's never going to happen (and never should). HTML is a presentation layer designed for comsumption by humans, and human presentation data is no place for semantic content because it's a view of the data meant for HUMANS, who will already understand the semantic meaning.
"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.
Fully agree with your criticism of "semantic HTML" though many frontend developers would (bogusly, IMO) assign HTML the role of "structure" rather than presentation which they believe CSS is for. But still, in practice, what's left of SemWeb (on the web) is used for marking up HTML for search engines, in the form of meta-tags, Open Graph annotations, location data, RDFa, microformats, etc. The question is, should they, when Google will preview their data in search results such that they don't get clicks? Which is exactly the problem with semantic technologies on the web.
The "semantic web" in terms of how it's been applied to HTML is effectively DOA. The real power of semantic data (which hasn't been realized yet) is in letting computer intelligences communicate in an understandable fashion. Linking databases and data sources globally has been the wet dream of distributed systems advocates for decades, but we've had neither the power nor the use cases for such things. However, once big data AI gets hungry enough, you can bet that everyone will jump headlong into the new data mining frenzy that's coming once someone writes the first successful "data connector & broker" service (much like what Lycos and Altavista did for web search).
I think the focus on semantic markup is unfortunate. The term conjures up the idea of someone going through a web page, painstakingly adding structured data to (partially) mirror the text on the page. That was never going to happen, and I agree with you that machine learning makes it even less likely to happen.
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.
Thank you for posting this, I think this expresses the situation perfectly!
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.
The various OWL dialects are intended for reasoning, in combination with RDF etc.
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");
I can now create an inference model that takes this knowledge into account:
OK, but how do I actually process these relations themselves if I want to reason about them? For example, suppose I want to write a program that tries to minimize the relations, or rewrite them for more efficient processing. How do I represent and access the rules themselves within this framework, when I want to reason about the rules instead of only using them with fixed reasoning engines?
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.
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.
I like the idea of type annotation in HTML eg itemscope="movie" , item="director" etc.
Categorizing everything in the world will be a lot of work though. Schema.org is too limiting/general.
I tend to agree with the selected Cory Doctorow quote. “Put a tag on it” is the semantic web version of IoT’s “put a chip in it” - technically feasible, yes, but to what end all that time and expense? The author here is fuzzy on applications. Feels like a solution looking for a problem.
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.
this will never work. the problem is people will add whatever semantics get them more sales. If tagging a site about dogs as "cats" gets 5% more visitors, even if they're pissed off it will still translate into more sales.
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 applied to YC a bunch of times with a prototype for a business to help create more of the semantic web. They were never interested in the slightest bit.
These folks don't want to allow anonymous users to run searches on their website which is a shame, semantic web or not. The bolg post is also strangely devoid of meaning.
53 comments
[ 3.2 ms ] story [ 105 ms ] threadI 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 :)
[1]https://news.ycombinator.com/item?id=24583798
“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 :)
I view the SW as part of knowledge representation, thus part of AI.
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]
[1] https://cookie.engineer
[2] https://tholian.network
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.
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!
[1] https://concise-encoding.org/#relationships
> 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:
I can now create an inference model that takes this knowledge into account: OK, but how do I actually process these relations themselves if I want to reason about them? For example, suppose I want to write a program that tries to minimize the relations, or rewrite them for more efficient processing. How do I represent and access the rules themselves within this framework, when I want to reason about the rules instead of only using them with fixed reasoning engines?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.
[0] https://wikidata.org/wiki/Wikidata:Main_Page
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.
https://searchengineland.com/wikipedia-confirms-they-are-ste...
https://news.ycombinator.com/item?id=23477201
https://hackernoon.com/how-wikipedia-lost-3-billion-organic-...