TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Make the “semantic web” web 3.0 again – with the help of SQLite

461 点作者 sekao超过 3 年前

45 条评论

fleddr超过 3 年前
The semantic web is not a technical problem, it&#x27;s an incentive problem.<p>RSS can be considered a primitive separation of data and UI, yet was killed everywhere. When you hand over your data to the world, you lose all control of it. Monetization becomes impossible and you leave the door wide open for any competitor to destroy you.<p>That pretty much limits the idea to the &quot;common goods&quot; like Wikipedia and perhaps the academic world.<p>Even something silly as a semantic recipe for cooking is controversial. Somebody built a recipe scraping app and got a massive backlash from food bloggers. Their ad-infested 7000 word lectures intermixed with a recipe is their business model.<p>Unfortunately, we have very little common good data, that is free from personal or commercial interests. You can think of a million formats and databases but it won&#x27;t take off without the right incentives.
评论 #29900269 未加载
评论 #29898850 未加载
评论 #29898942 未加载
dgudkov超过 3 年前
I have a similar idea with PDF documents. Instead of having the royal PITA of parsing generated PDFs (e.g. invoices), things would be much simpler if every generated PDF came with a built-in SQLite or JSON that contains the structured data of that PDF.<p>One day I will do it.<p>Speaking more broadly, whether we talk about HTML or PDF it&#x27;s the same problem: documents should have two representations - human-friendly and machine-friendly until AI gets <i>so</i> good that only having the human-friendly representation is enough.
评论 #29903353 未加载
评论 #29902452 未加载
评论 #29915454 未加载
评论 #29905125 未加载
评论 #29900296 未加载
评论 #29902181 未加载
评论 #29902936 未加载
评论 #29900094 未加载
评论 #29902786 未加载
评论 #29902583 未加载
评论 #29902910 未加载
galaxyLogic超过 3 年前
SQLite is a relational database. Wouldn&#x27;t it be a better fit to use a graph-database as the backend for anything &quot;web&quot;?<p>The idea is good, that a web-page should be generated from some data somewhere. But &quot;web&quot; is much about not a single document but the links between the documents, which allow you to to represent a &quot;semantic net&quot;. The data should be about the links between them. Now where is such a database? And how can it &quot;sharded&quot; into multiple databases running in thousands of locations on the internet?
评论 #29903070 未加载
评论 #29904325 未加载
评论 #29903423 未加载
评论 #29948907 未加载
fizx超过 3 年前
Effectively, this is a pretty cool way to get an OSS version of something like <a href="https:&#x2F;&#x2F;www.snowflake.com&#x2F;guides&#x2F;public-data" rel="nofollow">https:&#x2F;&#x2F;www.snowflake.com&#x2F;guides&#x2F;public-data</a>. Also something like a lighter version of <a href="https:&#x2F;&#x2F;datasette.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;datasette.io&#x2F;</a>.<p>The thing it&#x27;s kinda missing for me is the ability to compose multiple SQLite databases, possibly provided by different domains.<p>It&#x27;d be nice to join together different public datasets. In a weird personal example, if Strava exposed SQLite, I&#x27;d love to do a join to weather.com and see when the last time I biked in the rain was.<p>It&#x27;d be cool if one half of some table was at foo.com and I could add a few rows to it on my bar.com domain, and then the combined dataset was queryable as a single unit.
评论 #29900777 未加载
SergeAx超过 3 年前
What is the difference between this idea and exposing a read-only MongoDB (JSON in, JSON out) via HTTP endpoint? In the end, 50 ranged HTTP requests is not that great for unstable connection, 1 request is way better, and you need a server anyway.<p>Okay, offline first, what does that mean? Should I download the entire 600mb SQLite database? Should I do it every time it changes? Who will pay for the bandwidth? We can not employ standard HTTP proxy and caching mechanism here, it is not for 600mb files.
评论 #29902267 未加载
togaen超过 3 年前
Terrible idea. Why would anyone want to deal with interfacing a bunch of randomly structured databases whose tables can change at any time without warning. Nightmare.
评论 #29902957 未加载
评论 #29901528 未加载
评论 #29901800 未加载
评论 #29914224 未加载
评论 #29907170 未加载
xmly超过 3 年前
I do not understand this conclusion: &quot;Data on the web will only be &quot;semantic&quot; if that is the default, and with this technique it will be.&quot;<p>Why would it be semantic?
评论 #29899873 未加载
评论 #29932234 未加载
评论 #29899581 未加载
0xbadcafebee超过 3 年前
Among the 30-odd technologies that make up the Semantic Web[1] (it never died, it&#x27;s just a collection of tech, lots of organizations use it daily) are graph databases[2]. Graph databases are necessary to implement semantic web databases.<p>SQLite is not a graph database. Even if you used SQLite to <i>implement</i> a graph database, it would not solve any significant problems of the semantic web, such as access to data, taxonomies, ontologies, lexicons, tagging, user interfaces to semantic data management, etc.<p>It&#x27;s a really odd suggestion that you would just copy around a database or leave it on the internet for people to copy from. For the BBS mentioned here, that might actually be <i>illegal</i>, as it might contain PII, and on other sites possibly PHI. Many countries now have laws that require user data to remain in-country. Besides the challenges of just organizing data semantically, there still needs to be work done on data security controls to prevent leaking sensitive information.<p>The funny thing is, that isn&#x27;t even hard to do with the semantic web. You classify the data that needs protecting and build functions and queries to match. You can tie that data to a unique ID so that people can &quot;own&quot; their data wherever it goes, and sign it with a user&#x27;s digital certificate which can also expire.<p>But all of that (afaik) doesn&#x27;t exist yet. Everyone is more concerned with blockchains and SQL, either because the fancy new tech is sexier, or the old boring tech doesn&#x27;t require any work to implement. The Semantic Web never caught on because it&#x27;s really fucking hard to get right. No companies are investing in making it easier. Maybe in 20 years somebody will get bored enough over a holiday to make a simple website creation tool that implicitly creates semantic web sites that are easy to reason about. It&#x27;ll probably be a WordPress plugin.<p>[1] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Semantic_Web" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Semantic_Web</a> [2] <a href="https:&#x2F;&#x2F;graphdb.ontotext.com&#x2F;documentation&#x2F;enterprise&#x2F;introduction-to-semantic-web.html" rel="nofollow">https:&#x2F;&#x2F;graphdb.ontotext.com&#x2F;documentation&#x2F;enterprise&#x2F;introd...</a>
评论 #29899106 未加载
评论 #29898915 未加载
评论 #29899777 未加载
评论 #29900811 未加载
评论 #29899089 未加载
评论 #29899566 未加载
评论 #29899344 未加载
gibsonf1超过 3 年前
Well, then again the original idea is taking off with <a href="https:&#x2F;&#x2F;solidproject.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;solidproject.org&#x2F;</a> with millions of pods by Tim Berner-Lee&#x27;s Inrupt to go online starting this Spring.
评论 #29902649 未加载
评论 #29903302 未加载
评论 #29900622 未加载
fjfaase超过 3 年前
SQL is not better than XML or JSON for representing data. They are all mappings of much richer data structures on a limited data model. But even setting aside these problems, there are some problems with a distrubted semantic web that are barely ever mentioned: the step from going from data to &#x27;semantic&#x27; facts, how to deal identifying sources, and versioning&#x2F;updates. I think it is very important to record who (person or institution) is the source of a certain fact or the &#x27;linking&#x27; of facts between multiple sources. Cryptographic keys, just as in blockchains, could help to link data of distruted sources such that it is possible to verify the source of a fact to sources&#x2F;authorities and correct errors or deal with updates in case they occur.
评论 #29900045 未加载
评论 #29902672 未加载
uoaei超过 3 年前
This may be more likely to happen if there was a compromise between the two: query the database, but maintain a database that is queryable using SPARQL and can export to TTL files. Then the linked data revolution can continue and we don&#x27;t have to maintain finnicky webpages but rather a relatively static database.
z3t4超过 3 年前
One problem is that it&#x27;s the one hosting the data that pays the bandwidth. Yes when you download a video from Youtube, Google has to pay your ISP! (Google will strong-arm peering agreements though, but that doesn&#x27;t take away from my point)<p>Someone have to pay for the infrastructure. Right now the one hosting (not the consumer) pays for the infrastructure. So there are not really any incentive to host data for free - like a kiosk offering free goods and services.<p>The problem is if you would get paid by sending stuff, everyone would be spamming data everywhere. Imagine if you would have to pay 10c every time someone sent you an e-mail.<p>Something that I think would help are micro transactions. And a built into browsers so that you could easily make a micro-transaction. We already have Bitcoin and other crypto currencies, but they are too big to run inside the browser of a mobile phone, if it wasn&#x27;t for the high transaction costs - the ledger&#x2F;blockchain would be even bigger...<p>Today publishers - those that publish stuff on the web earn money by showing ads. And ads initially worked very well for a few years around 2000 before people started cheating with bots. But you can still make individual deals with webmasters and choose to trust them.<p>Also a lot of &quot;the web&quot; has moved to videos and Youtube. The average web user choose to watch a video rather then reading a text article covering the topic of interest.
评论 #29902261 未加载
评论 #29900348 未加载
评论 #29900455 未加载
jsight超过 3 年前
Is there really that much web safely exposable data in sqlite for this to make sense? I&#x27;m not really seeing how this is obviously better than the metadata ideas that preceded it.
评论 #29898417 未加载
vmception超过 3 年前
if &quot;exposing and parsing metadata&quot; never took off as the meaning for web 3.0, by the author&#x27;s own admission, why try to resurrect it with this title? clickbait?<p>we love web3 labeled articles here<p>fortunately the more popular variant of web 3.0 doesn&#x27;t even need the developer to make a database or anything on the backend. just frontend development, and deploying code once to the nearest node. frontend is optional depending on your userbase.
tingletech超过 3 年前
&quot;The semantic web is the future of the web, and always will be.&quot; -- Peter Norvig<p><a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=LNjJTgXujno&amp;t=1257s" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=LNjJTgXujno&amp;t=1257s</a>
评论 #29900486 未加载
kdunglas超过 3 年前
API Platform is a popular and easy to use semantic web framework:<p>1. You design your data model as a set of PHP classes, or you generate the class from any RDF vocabulary such as Schema.org<p>2. API Platform uses the classes to expose a JSON-LD API with with all the typical features (sorting, filtering, pagination…)<p>3. You use the provided &quot;smart clients&quot; to build a dynamic admin interface or to scaffold Next, Nuxt or React Native apps (these tools rely on the Hydra API description vocabulary, and work with any Hydra-enabled API)<p>In addition to RDF&#x2F;JSON-LD&#x2F;Hydra, API Platform also supports ActivityPub.<p><a href="https:&#x2F;&#x2F;api-platform.com" rel="nofollow">https:&#x2F;&#x2F;api-platform.com</a>
评论 #29901117 未加载
firechickenbird超过 3 年前
Isn’t this Web 1.0 instead? You are only reading data, yeah ok with sql, but you still can’t modify it. And also there are already very good standards like Rdf, Owl2, spraql, which are more expressive than sql for consuming the info
mro_name超过 3 年前
I don&#x27;t get it, why the data and the final visual have to be both present&#x2F;created ON THE SERVER.<p>There&#x27;s been a technology around for so long, that it is forgotten meanwhile (like the semweb itself): xslt.<p>A lot can be done by just publishing raw xml data plus a visual representation generated in the browser right before display.<p>I&#x27;m doing so with RDF <a href="https:&#x2F;&#x2F;demo.mro.name&#x2F;geohash.cgi&#x2F;about" rel="nofollow">https:&#x2F;&#x2F;demo.mro.name&#x2F;geohash.cgi&#x2F;about</a>, GPX <a href="https:&#x2F;&#x2F;demo.mro.name&#x2F;geohash.cgi&#x2F;u154c" rel="nofollow">https:&#x2F;&#x2F;demo.mro.name&#x2F;geohash.cgi&#x2F;u154c</a>, homegrown xml <a href="http:&#x2F;&#x2F;rec.mro.name&#x2F;stations&#x2F;b2&#x2F;2022&#x2F;01&#x2F;12&#x2F;1005" rel="nofollow">http:&#x2F;&#x2F;rec.mro.name&#x2F;stations&#x2F;b2&#x2F;2022&#x2F;01&#x2F;12&#x2F;1005</a> or atom feeds <a href="https:&#x2F;&#x2F;demo.mro.name&#x2F;shaarligo" rel="nofollow">https:&#x2F;&#x2F;demo.mro.name&#x2F;shaarligo</a> and on and on.<p>The server is a source of data, its filesystem the database, and the client has to make sense of it. There is no API but GET requests. Works wonders for all but big data queries, naturally.<p>So you publish raw data (TimBL, you want it that way) plus a recipe for a visual representation and the browser shows a sensible view to begin with.
jhoelzel超过 3 年前
Well yes and no. I can see this working in theory, but in reality semantic means standardised as much as it means accessible.<p>In a world where my blogpost objet has the same information as your blogpost object, this works without a problem.<p>In a world where I actually want to up my database to you, we could agree on a format.<p>Both of these cases, from where i stand, seem very unlikely and we have not even talked about the pople that would clone your data 1 to 1 just to host an ad filled alternative of your site in real time.
simonw超过 3 年前
I&#x27;ve been exploring the idea of using SQLite to publish data online via my Datasette project for a few years now: <a href="https:&#x2F;&#x2F;datasette.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;datasette.io&#x2F;</a><p>Similar to the OP, one of the things I&#x27;ve realized is that while the dream of getting everyone to use the exact same standards for their data has proved almost impossible to achieve, having a SQL-powered API actually provides a really useful alternative.<p>The great thing about SQL APIs is that you can use them to alter the shape of the data you are querying.<p>Let&#x27;s say there&#x27;s a database with power plants in it. You need them as &quot;name, lat, lng&quot; - but the database you are querying has &quot;latitude&quot; and &quot;longitude&quot; columns.<p>If you can query it with a SQL query, you can do this:<p><pre><code> select name, latitude as lat, longitude as lng from [global-power-plants] </code></pre> Here&#x27;s a demo using exactly that query: <a href="https:&#x2F;&#x2F;global-power-plants.datasettes.com&#x2F;global-power-plants?sql=select+name%2C+latitude+as+lat%2C+longitude+as+lng+from+%5Bglobal-power-plants%5D+limit+100" rel="nofollow">https:&#x2F;&#x2F;global-power-plants.datasettes.com&#x2F;global-power-plan...</a><p>That URL gives you back an HTML page, but if you change the extension to .json you get back JSON data:<p><a href="https:&#x2F;&#x2F;global-power-plants.datasettes.com&#x2F;global-power-plants.json?sql=select+name%2C+latitude+as+lat%2C+longitude+as+lng+from+%5Bglobal-power-plants%5D+limit+100&amp;_shape=array" rel="nofollow">https:&#x2F;&#x2F;global-power-plants.datasettes.com&#x2F;global-power-plan...</a><p>Or use .csv to get back the data as CSV:<p><a href="https:&#x2F;&#x2F;global-power-plants.datasettes.com&#x2F;global-power-plants.csv?sql=select+name%2C+latitude+as+lat%2C+longitude+as+lng+from+%5Bglobal-power-plants%5D+limit+100" rel="nofollow">https:&#x2F;&#x2F;global-power-plants.datasettes.com&#x2F;global-power-plan...</a><p>But what if you need some other format, like Atom or ICS or RDF?<p>Datasette supports plugins which let you do that. I&#x27;m running the <a href="https:&#x2F;&#x2F;datasette.io&#x2F;plugins&#x2F;datasette-atom" rel="nofollow">https:&#x2F;&#x2F;datasette.io&#x2F;plugins&#x2F;datasette-atom</a> datasette-atom plugin on this other site. That plugin lets you define atom feeds using a SQL query like this one:<p><pre><code> select issues.updated_at as atom_updated, issues.id as atom_id, issues.title as atom_title, issues.body as atom_content, repos.html_url || &#x27;&#x2F;issues&#x2F;&#x27; || number as atom_link from issues join repos on issues.repo = repos.id order by issues.updated_at desc limit 30 </code></pre> Try that query here: <a href="https:&#x2F;&#x2F;github-to-sqlite.dogsheep.net&#x2F;github?sql=select%0D%0A++issues.updated_at+as+atom_updated%2C%0D%0A++issues.id+as+atom_id%2C%0D%0A++issues.title+as+atom_title%2C%0D%0A++issues.body+as+atom_content%2C%0D%0A++repos.html_url++%7C%7C+%27%2Fissues%2F%27+%7C%7C+number+as+atom_link%0D%0Afrom%0D%0A++issues+join+repos+on+issues.repo+%3D+repos.id%0D%0Aorder+by%0D%0A++issues.updated_at+desc%0D%0Alimit%0D%0A++30" rel="nofollow">https:&#x2F;&#x2F;github-to-sqlite.dogsheep.net&#x2F;github?sql=select%0D%0...</a><p>The plugin notices that columns with those names are returned, and adds a link to the .atom feed. Here&#x27;s that URL - you can subscribe to that in your feed reader to get a feed of new GitHub issues across all of the projects I&#x27;m tracking in that Datasette instance: <a href="https:&#x2F;&#x2F;github-to-sqlite.dogsheep.net&#x2F;github.atom?sql=select%0D%0A++issues.updated_at+as+atom_updated%2C%0D%0A++issues.id+as+atom_id%2C%0D%0A++issues.title+as+atom_title%2C%0D%0A++issues.body+as+atom_content%2C%0D%0A++repos.html_url++%7C%7C+%27%2Fissues%2F%27+%7C%7C+number+as+atom_link%0D%0Afrom%0D%0A++issues+join+repos+on+issues.repo+%3D+repos.id%0D%0Aorder+by%0D%0A++issues.updated_at+desc%0D%0Alimit%0D%0A++30" rel="nofollow">https:&#x2F;&#x2F;github-to-sqlite.dogsheep.net&#x2F;github.atom?sql=select...</a><p>As you can see, there&#x27;s a LOT of power in being able to use SQL as an API language to reshape data into the format that you need to consume.
评论 #29901327 未加载
评论 #29900589 未加载
lmm超过 3 年前
I&#x27;m not a fan of SQL, but I do think exposing your original source data in its original form is valuable (though it has little to do with being semantic). I carefully set up my blog to expose the raw markdown that is the source form of my blog posts in the source HTML itself, with the minimum necessary cruft around it to render it as a viewable webpage.
评论 #29903262 未加载
echelon超过 3 年前
What a lot of folks don&#x27;t realize is that the Semantic Web was poised to be a P2P and distributed web. Your forum post would be marked up in a schema that other client-side &quot;forum software&quot; could import and understand. You could sign your comments, share them, grow your network in a distributed fashion. For all kinds of applications. Save recipes in a catalog, aggregate contacts, you name it.<p>Ontologies were centrally published (and had URLs when not - &quot;URIs&#x2F;URNs are cool&quot;), so it was easy to understand data models. The entity name was the location was the definition. Ridiculously clever.<p>Furthermore, HTML was headed back to its &quot;markup&quot; &#x2F; &quot;document&quot; roots. It focused around meaning and information conveyance, where applications could be layered on top. Almost more like JSON, but universally accessible and non-proprietary, and with a built in UI for structured traversal.<p>Remember CSS Zen Garden? That was from a time where documents were treated as information, not thick web applications, and the CSS and Javascript were an ethereal cloak. The Semantic Web folks concurrently worked on making it so that HTML wasn&#x27;t just &quot;a soup of tags for layout&quot;, so that it wasn&#x27;t just browsers that would understand and present it. RSS was one such first step. People were starting to mark up a lot of other things. Authorship and consumption tools were starting to arise.<p>The reason this grand utopia didn&#x27;t happen was that this wave of innovation coincided with the rise of VC-fueled tech startups. Google, Facebook. The walled gardens. As more people got on the internet (it was previously just us nerds running Linux, IRC, and Bittorrent), focus shifted and concentrated into the platforms. Due to the ease of Facebook and the fact that your non-tech friends were there, people not only stopped publishing, but they stopped innovating in this space entirely. There are a few holdouts, but it&#x27;s nothing like it once was. (No claims of &quot;you can still do this&quot; will bring back the palpable energy of that day.)<p>Google later delivered HTML5, which &quot;saved us&quot; from XHTML&#x27;s strictness. Unfortunately this also strongly deemphasized the semantic layer and made people think of HTML as more of a GUI &#x2F; Application design language. If we&#x27;d exchanged schemas and semantic data instead, we could have written desktop apps and sharable browser extensions to parse the documents. Natively save, bookmark, index, and share. But now we have SPAs and React.<p>It&#x27;s also worth mentioning that semantic data would have made the search problem easier and more accessible. If you could trust the author (through signing), then you could quickly build a searchable database of facts and articles. There was benefit for Google in having this problem remain hard. Only they had the infrastructure and wherewithal to deal with the unstructured mess and web of spammers. And there&#x27;s a lot of money in that moat.<p>In abandoning the Semantic Web, we found a local optima. It worked out great for a handful of billionaires and many, many shareholders and early engineers. It was indeed faster and easier to build for the more constrained sandboxiness of platforms, and it probably got more people online faster. But it&#x27;s a far less robust system that falls well short of the vision we once had.
评论 #29899765 未加载
评论 #29898986 未加载
评论 #29899352 未加载
评论 #29899111 未加载
评论 #29899292 未加载
netcan超过 3 年前
Whether or not it has legs, at least this is an interesting idea.
luhn超过 3 年前
The author seems to assume that everybody is using SQLite, but SQLite for a production database is an extremely niche choice. Attempting to expose more popular options like PostgreSQL or MySQL as SQLite would be extremely difficult because SQLite only supports a subset of SQL, whereas PostgreSQL and MySQL both implement their unique superset (for the most part) of SQL.<p>But it doesn&#x27;t matter. The API doesn&#x27;t matter. Web 3.0 was never about APIs, it was about <i>data</i>. A standardized API is only useful if it outputs standardized data. Having a bunch of bespoke SQLite tables scattered across the web gets us no closer to the ideal of Web 3.0.
评论 #29900441 未加载
评论 #29898659 未加载
评论 #29899040 未加载
评论 #29899204 未加载
评论 #29899245 未加载
评论 #29899669 未加载
shp0ngle超过 3 年前
.... the original SQLite-over-HTTP-ranges was a clever hack to host database-like data on github.<p>But I don&#x27;t think it should be <i>actually used</i> for anything serious.<p>And I don&#x27;t really get the connection with &quot;semantic web&quot;, which was essentially idealistic vaporware of the 2000s.
visarga超过 3 年前
&gt; Data on the web will only be &quot;semantic&quot; if that is the default, and with this technique it will be.<p>Not going to work unless imposed by some external force. The semantics of the web can more practically be extracted with neural nets, but it&#x27;s a long tail and there are errors. Lots of good work recently in parsing tables, document layouts and key-value extraction. LayoutLM and its kin comes to mind.[1]<p>[1] <a href="https:&#x2F;&#x2F;scholar.google.com&#x2F;scholar?cites=9435785928704193879&amp;as_sdt=2005&amp;sciodt=0,5&amp;hl=en" rel="nofollow">https:&#x2F;&#x2F;scholar.google.com&#x2F;scholar?cites=9435785928704193879...</a>
bokchoi超过 3 年前
I never got on the semantic web train, but a translation layer does allow you to make underlying schema changes.<p>I poked around the ANSIWAVE BBS and it looks fun!
pietroppeter超过 3 年前
Very nice indeed! I am sorry I did not notice before the discussion about previous blogpost on the subject [0] “Using the SQLite-over-HTTP &quot;hack&quot; to make backend-less, offline-friendly apps”<p>Are there more than 2 blogposts? Cannot find a posts page.<p>[0]: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=29758613" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=29758613</a>
recursivedoubts超过 3 年前
Humans, as of now (and as far as I&#x27;m aware, being outside the AI labs at the big tech companies and DARPA) have agency, and so are in a unique position to take advantage of the uniform interface of REST&#x2F;the web in a flexible manner. I wrote an article about this on the intercooler.js blog, entitled &quot;HATEOAS is for Humans&quot;:<p><a href="https:&#x2F;&#x2F;intercoolerjs.org&#x2F;2016&#x2F;05&#x2F;08&#x2F;hatoeas-is-for-humans.html" rel="nofollow">https:&#x2F;&#x2F;intercoolerjs.org&#x2F;2016&#x2F;05&#x2F;08&#x2F;hatoeas-is-for-humans.h...</a><p>The idea that metadata can be provided and utilized in a similar manner doesn&#x27;t strike me as realistic. If it is code consuming the metadata, the flexibility of the uniform interface is wasted. If it is a human consuming the metadata, they want something nice like HTML.<p>For code, why not just a structured and standardized JSON API?<p>This appears to be what we have settled on, and I don&#x27;t see any big advantage extending REST-ful web concepts on top of it. The machines just ignore all that meta-data crap.
评论 #29899606 未加载
评论 #29900608 未加载
tzury超过 3 年前
A more readable version<p><a href="https:&#x2F;&#x2F;outline.com&#x2F;E5J2Ft" rel="nofollow">https:&#x2F;&#x2F;outline.com&#x2F;E5J2Ft</a>
punnerud超过 3 年前
This post came 3months before phiresky, and should get credit for being first to making it practical: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=25842999" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=25842999</a>
wombatmobile超过 3 年前
&gt; The semantic web will never happen if it requires additional manual labor.<p>Is manual labor the reason things turned out the way they did, with google spending whatever it took to index and monetise the whole web the way it did?<p>Or might money have something to do with it?
phh超过 3 年前
I think the author missed the &quot;semantic&quot; part. If you push your own SQLite, then no, I don&#x27;t have the semantic meaning of the website. Only a standardized semantic file format ala RDF can achieve that.
评论 #29904313 未加载
hankman86超过 3 年前
Not going to happen. The reason for the Semantic Web never taking off were never technical. Websites already spend a lot of money on technical SEO and would happily add all sorts of metadata if only it helped them rank better. Of course, many sites’ metadata would blatantly “lie” and hence, the likes of Google would never trust it.<p>Re exposing an entire database of static content: again, reality gets in the way. Websites want to keep control over how they present their data. Not to mention that many news sites segregate their content as public and paywalled. Making raw content available as a structured and query able database may work for the likes of Wikipedia or arxiv.org. But it’ll not likely going to be adopted by commercial sites.
sharperguy超过 3 年前
I wonder if combining this idea with some kind of microtransactional currency such as the bitcoin Lightning Network or even a simple Chaumian e-cash system (1) would help to get around the issue of requiring clickbait, advertising and SEO with every single piece of data.<p>Would be great if providers could offer data in raw form without the overhead of all the gunk that gets them paid.<p>1. <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Ecash" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Ecash</a>
serverholic超过 3 年前
It&#x27;s clear that people want web apps, not the semantic web. I really don&#x27;t see why people care so much about this.
eoo超过 3 年前
Needs cost-based querying paid for with lightning network to be viable at scale.
评论 #29905169 未加载
__MatrixMan__超过 3 年前
But how are we going to make sure that users see ads between each query?
moigagoo超过 3 年前
Feel kinda disappointed that the blog isn&#x27;t hosted on Ansiwave :-)
hankman86超过 3 年前
Btw, it’s funny how the failed “semantic” web is now labelled Web 3.0
dustractor超过 3 年前
Range requests. Hmm. That would lead to some interesting semantics.
fiatjaf超过 3 年前
What is this data we want to semantically link by the way?
seumars超过 3 年前
This could be a nifty way of getting RSS back.
WolfOliver超过 3 年前
How does this relates to an headless CMS?
jillesvangurp超过 3 年前
I think both the capital S Semantic Web and the lowercase semantic web (microformats) kind of just fizzled out towards the end of last decade without changing much at all on the actual web.<p>The lower case variety kind of survives as a smart thing to do to &quot;help&quot; search engines a little but otherwise has very little real world relevance. All talk of doing anything with on page information in browsers evaporated a long time ago. E.g. MS had some plans with this with early versions of Edge and there were some nice extensions for Chrome and Firefox as well. Not a thing any more. Most of that got unceremoniously ripped out of browsers a long time ago. At this point it&#x27;s basically just good SEO practice to use microformats as search engines can use all the help they need to figure out what is what on a page. Other than that, whether you render your data to a canvas, a table, or nice semantic HTML has very little relevance for anyone. It&#x27;s all just pixels that hit your eyeballs in the end. There&#x27;s nothing else that looks at that information. With the exception of search engines. And they were part of web 1.0 already.<p>The capital S Semantic Web with ontologies, triple databases, etc. never really got out of the gates and is perpetually stuck in people doing very academic stuff or specialist niche stuff that largely does not matter to anyone else. The exception is graph databases, which are still used in some data&#x2F;backend teams for some stuff. And of course a few of those also pay lip service to some of the Semantic Web W3C standards from the early 2000s even though that is not the main thing they do anymore. Either way, too much of a specialist thing to call it a semantic web (capital or lower case). Most of the web uses exactly none of this stuff. But nice tools to have if you need them. You could argue a lot of the people involved moved their focus to AI and machine learning, which certainly looks like it is having a very large impact on e.g. search engines.<p>I guess web3 has that in common with web 3.0 (other than the number 3). There are a few people who desperately (and loudly) want the web to go their way and insist it must be the future. But most people couldn&#x27;t care less. In the end people just vote with their feet and gravitate to technologies that work for them or solve a problem they have and ignore things that don&#x27;t do anything useful for them. In the case of Semantic Web, there was nothing there that you could coherently explain (i.e. without using all sorts of abstractions, complex stuff, and simplistic hyperbole). There were a few startups and lots of hype. They did a bunch of stuff. Most of those startups no longer exist or have faded into irrelevance. And the few that survived carved out a few interesting niches but did not end up producing any mainstream, must have technology. Certainly no unicorns there. Wolfram Alpha probably is one of the more well-known ones that actually shipped something useful. But it&#x27;s a destination and not the web.<p>Web3 has the same issues. Most threads on HN on web3 devolve into people talking about what it is, ought to be, or isn&#x27;t and why that is or isn&#x27;t important. That seems to be impossible to do without using a lot of hyperbole and BS. Very little substance in terms of widely adopted technology or even in terms of what that technology looks like or should look like. It&#x27;s Web 1.0 all over again. Step 1 Blockchain, Step 2: ????, Step 3: Profit (or not).<p>Most of the web is just a slightly slicker version of what we had 15 years ago (web 2.0). AJAX definitely became common place. We now have mature versions of HTML, SVG, CSS, etc. that actually work. And with WASM we can finally engineer some proper software without having to worry about polyfills and other crazy hacks to make javascript do stuff it clearly is not very good at. I&#x27;m looking forward to the next 15 years. It&#x27;s going to be interesting and possibly a wild ride.