Mozilla Fathom: Find meaning in the web
github.com
github.com
TCP/IP: "It's not the wires, it's the computers!"
HTTP/HTML: "It's not the computers, it's the documents!"
Semantic Web (/Fathom): "It's not the documents, it's the things that they are about!"
https://www.w3.org/DesignIssues/Abstractions.html
I look forward to the day when the idea of discrete, atomic documents is finally abstracted away in the same manner that we abstracted away the physical machines that host them.
There does seem to be some overloading of the term 'semantic web' though. Sometimes the term is used to refer to semantic markup, such as using the <em> HTML tag instead of using the <i> HTML tag...
https://en.m.wikipedia.org/wiki/Semantic_HTML
Other times, the term semantic web is used to refer to structured meaning transmitted through specialised metadata...
https://en.m.wikipedia.org/wiki/Semantic_Web
Fathom seems to sit across the two, though I'd suggest it's closer to the first, unless it's used as a tool to analyse the design of existing web pages for the benefit of new website designs (combined with site usage data, e.g. bounce rates, etc...).
That is the reason why we currently work on http://link.fish which is a smart bookmark manager and allows people to work with the information behind the urls. We are currently in a closed beta but am happy about anybody who gives honest feedback.
Here is a short 2 min (low quality) demo video which shows how it works: https://youtu.be/Chfy3le5gY0
I'd note that Google's Knowledge Vault paper[1] found that "semantic web"-type technologies (very widely interpreted as anything that used metadata) was pretty useless as a source of data: only 0.25M out of 140M total "facts" extracted using those annotations were classified as high confidence (ie 0.2%).
This is in contrast to a DOM-rules based approach (which seems similar to Fathom) which extracted 94M out of 1200M total (ie 8%).
The Semantic Web is dead, and the KV paper buried it.
We want to use Fathom as the engine for applying a series of rules to look for various forms of metadata in pages and collect them in a consistent fashion. This can be used for storing/querying rich data about pages, presenting nice previews of pages to users, and other applications.
My hope is that this repository acts as a collection point for people to continue to contribute rules for various forms of metadata, from basic page representation, to more domain specific things like product data, media data, location data, etc.
The project can be found here:
https://github.com/mozilla/page-metadata-parser
This library is designed to be used either as a node package within a server side node ecosystem, or client side through npm and webpack/browserify/etc, it's currently tested against node and Firefox.
Soon I hope to wrap it in a RESTful API with a Docker container, which will be found here (still needs docs/tests):
https://github.com/mozilla/page-metadata-service
I recently found a very similar project called `Manifestation` which does almost the exact same thing, so I hope to collaborate with Patrick and integrate the projects if possible.
Fortunately, we usually don't need to process web pages using fancy yet hardly accurate algorithms in order to extract machine-readable text from web pages. Why? It's because we agreed to use character codes to codify letters and most of the time text is encoded using some character code, which makes it unnecessary to OCR pictures of hand-written letters to programatically process text from web pages.
These kinds of program wouldn't be needed if only the same thing had happened for page structures, if HTTP included page semantics.
As for rel=next/previous, I don't use them because Google makes it clear that these will make it treat the whole sequence like one paginated document in the index, contrary to their original semantics. I'd love if someone could correct me on this.
[0] http://webmasters.stackexchange.com/questions/61573/is-it-ju...
[1] https://www.w3.org/TR/html401/struct/links.html#h-12.3
[2] https://webmasters.googleblog.com/2011/09/pagination-with-re...
Otherwise I'd be curious to hear how or why including web page layout semantics in HTTP would be useful.
zero gain. There is just no application. Google works perfectly fine. Give it up already.
And just to take this to another tangent.. Word won the office space. There are no normal people writing LaTeX for their party invitation. And hell, even the people writing LaTeX don't want to bother with the "machine-understandable" thing so they went ahead and made it into a proper Turing complete programming language.
Even simple stuff like asking the writer to clarify which piece of a text that a written date applies to would be helpful, and to define what parts of long sentences with many commas belong together (which subsentences are interjections, for example?).
https://github.com/mozilla/page-metadata-parser
This repo is exactly what you describe, meant to be a collection of 'recipes' or 'rules' for extracting various forms of metadata from pages. It's very early in its infancy but we are nearing deploying a first version of this to users via Test Pilot:
https://testpilot.firefox.com/
I would love feedback or contributions!
I use dataset extensively. Once each DOM element is assigned a unique key id, many things get simplified: DOM manipulation, client server state sync, event handling, etc. Now if an additional data layer can resolve key id to semantic metadata, the only problem left would be to expose that data so third parties can read from it. So, the problem could be solved with three data points: url, dom key and the resolved metadata value.
What's really needed isn't a new protocol or set of rules and conditions. OpenGraph probably works just fine. It's a dedicated global database of metadata. A web white pages directory. As OpenGraph is perhaps dominant, it may make sense for someone like Facebook to provide this. Historically, third party non-profit services have not been popular.
All of this is of course contingent on the assumption that content hosters provide that metadata to begin with ;)
Still worried about the extensions ecosystem though.
It is said to be similar to chromes. And chrome doesn't support real extensions like tree style tabs etc.
Happy if you can tell me I am misinformed.
- network effects (chrome is more popular than ff)
- chrome extensions are so much easier to write than XUL ff extensions
Now webextensions are implemented in FF, it's incredibly easy to port extensions across (I ported one earlier this week, took about 20 minutes!)
Tree style tabs and all that jazz aren't going away yet.
It's a killer move from Mozilla and makes FF a first class citizen of the web again.
- Dropping XUL breaks backwards compatability and it seems Mozilla is willing to break it before they provide adequate replacement APIs
- The design of the new addon signature requirements turns AMO into a walled garden and I very much do not appreciate that
The problem is not XUL. Modifying HTML or XUL DOM via JS is roughly equivalent (setting aside XUL-only features like XBL, does this matter for many extensions?)
The problem is all the internal JS APIs that add-ons can call right now, there are too many to secure and ensure backwards compat. This is why extensions break between releases so much. It's also pretty hard to program against, so there are a lot of common bugs and it's very difficult to ensure any level of security, since Firefox extensions can do anything.
WebExtensions are intended to be a superset of the APIs Chrome exposes, new APIs are being added all the time. It must be possible to implement them securely and maintain them over time, unlike the current situation with internal-only APIs.
> The design of the new addon signature requirements turns AMO into a walled garden and I very much do not appreciate that
I disagree. Signing is required to make it more difficult for malicious extensions to persist in the wild. There's no requirement to host on AMO, just a requirement to sign if you want your extension to run in Firefox release builds.
If the extension is later found to be malicious, it can be revoked without having to depend on the ID (which is set by the add-on and trivial to circumvent).
> The primary concerns I have, which I left Firefox over
Which browser did you switch to? There's still time to participate and influence outcomes, old-style extensions are still supported today...
You can't even go from unlisted to listed on Firefox's addon site.
Will the new Firefox support real extensions or just wannabe-extensions like Chrome?
There are already several WebExtension APIs implemented that Firefox supports that Chrome does not, the difference now is that APIs are being built specifically for extension authors to use, rather than Firefox internals being directly accessible (which certainly allows you to modify anything, but is intractable to maintain backwards compat and secure).
Many authors of popular extensions are working on specifying and prototyping the APIs they need.
So what's happening is that the extension stuff is going to be standardized, and that standard will be closer to Chrome's model.
However, this doesn't mean that functionality will be lost -- this is the key bit of confusion around this that's causing all the resentment.
Instead, the protocol will be extended. The intention is so that almost all extensions, especially the popular ones like tree style tabs, will keep on working; however they will need to be written to work with the new APIs. Functionality from Firefox's API will only be removed when there is something on the webextensions side that gives the same abilities.
The current system lets plugin developers directly hook into Firefox source, which means that theoretically any change is a breaking change. Architectural overhauls like electrolysis were impeded by this too. Instead, the desire is to switch to a proper API that is separate from the inner functionality; which is basically a core principle of API design.
Chrome already does this -- the API is limited -- but the generic model is the right one. The plan is to do something similar in Firefox, with a much larger API (eventually) than what Chrome has.
At first, probably just the Chrome API will be implemented, but IIRC regular firefox addon APIs will not be removed until the corresponding APIs exist in the webextensions format.
This will mean that authors of old addons may need to put some work into it to make it work again (which they had to do anyway for electrolysis, really). Also, obscure addons using very random internal APIs may also break entirely. But for the most part the average addon user shouldn't notice anything.
Fantastic news, thanks!
> The intention is so that almost all extensions, especially the popular ones like tree style tabs, will keep on working; however they will need to be written to work with the new APIs.
This sounds doable.
> but IIRC regular firefox addon APIs will not be removed until the corresponding APIs exist in the webextensions format.
Again, this should sort it.
My worry was if we would be left with only chrome-like or worse browsers - for me Firefox currently plays in different league.
Edit: you possibly see why I and others were mistaken; you are the first one I know that has explained this. Feel free to tell relevant people why we misunderstood so we can clear up the FUD.
Right. There's been a lot of FUD on this and not enough has been explicitly said. I'm pretty sure this was clearly stated in some places, but FUD spreads easily :)
Maybe I can convince someone to write something about it.
You should come chat in #webextensions, if we can identify where messaging is falling down and fix it this would be great!
I think one thing missing right now is having good "release criteria" for WebExtensions (like we did for e10s) - I don't think implementing every single API that's available to old-style extensions right now is a tractable problem (since it's "every internal API", all the way up to executing arbitrary commands).
yes, of course, its not every internal API but the bottom line is that most extensions should still work, right? :)
Or are you guys going to implement every single incompatible addon yourself?
Google get's me nothing though, except the Chrome API and Operas copy thereof.
So Mozilla basically just said: "Let's just copy the Chrome APIs. Done"
Don't get me wrong, I've written some Chrome extensions, and I think the API is mostly pretty great. But wouldn't an actual standard be appropriate?
There's a community group: https://www.w3.org/community/browserext/ but no WG yet as far as I can tell.