Category: Semantic Web

Google Tests Feature That Lets Media Companies, Marketers Publish Directly to Search Results – WSJ

Google Tests Feature That Lets Media Companies, Marketers Publish Directly to Search Results – WSJ

Google is experimenting with letting big publishers publish directly into search results, instead of going through SEO and indexing.

Google is experimenting with a new feature that allows marketers, media companies, politicians and other organizations to publish content directly to Google and have it appear instantly in search results.

..

Google has built a Web-based interface through which posts can be formatted and uploaded directly to its systems. The posts can be up to 14,400 characters in length and can include links and up to 10 images or videos. The pages also include options to share them via Twitter, Facebook or email.

Each post is hosted by Google itself on a dedicated page, and appears in a carousel in results pages for searches related to their authors for up to a week, a Google spokeswoman said. After seven days, the posts remain live but won’t be surfaced in search results. Rather, they can be accessed via a link.

…

The Google spokeswoman said the experimental feature is separate from Google’s Accelerated Mobile Pages program, which aims to speed up online content by streamlining the code that powers Web pages.

With the AMP program, Google also “caches” pages, or saves copies of them on its own systems, in order to deliver them more quickly to users. AMP doesn’t host content directly, however, whereas Google’s new search feature does.

Google’s tests of the new posting tool comes at a time when media companies, marketers and organizations of all types are increasingly distributing content by publishing directly to major online platforms, instead of driving users back to their own websites and properties.

Facebook has an Instant Articles feature, for example, which lets anyone host their content directly on the social network, provided they adhere to its content policies. Facebook also overhauled its own “Notes” feature in September 2015 which—similarly to Google’s new feature—offers a Web interface through which users can publish their content directly to the social network.

Apple also unveiled a Web-based publishing tool that allows users to arrange and publish content directly to its Apple News application.

The Google spokeswoman emphasized that the new tool remains in an experimental phase, and wouldn’t provide details on if or when it may be opened up to more authors. Google is currently testing it with a range of different type of partners, she said, but wouldn’t disclose exactly how many.

Hypertext Transfer Protocol (HTTP) Status Code Registry

Hypertext Transfer Protocol (HTTP) Status Code Registry

Registry included below

…

HTTP Status Codes

Registration Procedure(s)
IETF Review
Reference
[RFC7231]
Note
1xx: Informational - Request received, continuing process
2xx: Success - The action was successfully received, understood, and accepted
3xx: Redirection - Further action must be taken in order to complete the request
4xx: Client Error - The request contains bad syntax or cannot be fulfilled
5xx: Server Error - The server failed to fulfill an apparently valid request
Available Formats

CSV
Value Description Reference
100 Continue [RFC7231, Section 6.2.1]
101 Switching Protocols [RFC7231, Section 6.2.2]
102 Processing [RFC2518]
103-199 Unassigned
200 OK [RFC7231, Section 6.3.1]
201 Created [RFC7231, Section 6.3.2]
202 Accepted [RFC7231, Section 6.3.3]
203 Non-Authoritative Information [RFC7231, Section 6.3.4]
204 No Content [RFC7231, Section 6.3.5]
205 Reset Content [RFC7231, Section 6.3.6]
206 Partial Content [RFC7233, Section 4.1]
207 Multi-Status [RFC4918]
208 Already Reported [RFC5842]
209-225 Unassigned
226 IM Used [RFC3229]
227-299 Unassigned
300 Multiple Choices [RFC7231, Section 6.4.1]
301 Moved Permanently [RFC7231, Section 6.4.2]
302 Found [RFC7231, Section 6.4.3]
303 See Other [RFC7231, Section 6.4.4]
304 Not Modified [RFC7232, Section 4.1]
305 Use Proxy [RFC7231, Section 6.4.5]
306 (Unused) [RFC7231, Section 6.4.6]
307 Temporary Redirect [RFC7231, Section 6.4.7]
308 Permanent Redirect [RFC7538]
309-399 Unassigned
400 Bad Request [RFC7231, Section 6.5.1]
401 Unauthorized [RFC7235, Section 3.1]
402 Payment Required [RFC7231, Section 6.5.2]
403 Forbidden [RFC7231, Section 6.5.3]
404 Not Found [RFC7231, Section 6.5.4]
405 Method Not Allowed [RFC7231, Section 6.5.5]
406 Not Acceptable [RFC7231, Section 6.5.6]
407 Proxy Authentication Required [RFC7235, Section 3.2]
408 Request Timeout [RFC7231, Section 6.5.7]
409 Conflict [RFC7231, Section 6.5.8]
410 Gone [RFC7231, Section 6.5.9]
411 Length Required [RFC7231, Section 6.5.10]
412 Precondition Failed [RFC7232, Section 4.2]
413 Payload Too Large [RFC7231, Section 6.5.11]
414 URI Too Long [RFC7231, Section 6.5.12]
415 Unsupported Media Type [RFC7231, Section 6.5.13][RFC7694, Section 3]
416 Range Not Satisfiable [RFC7233, Section 4.4]
417 Expectation Failed [RFC7231, Section 6.5.14]
418-420 Unassigned
421 Misdirected Request [RFC7540, Section 9.1.2]
422 Unprocessable Entity [RFC4918]
423 Locked [RFC4918]
424 Failed Dependency [RFC4918]
425 Unassigned
426 Upgrade Required [RFC7231, Section 6.5.15]
427 Unassigned
428 Precondition Required [RFC6585]
429 Too Many Requests [RFC6585]
430 Unassigned
431 Request Header Fields Too Large [RFC6585]
432-450 Unassigned
451 Unavailable For Legal Reasons [RFC7725]
452-499 Unassigned
500 Internal Server Error [RFC7231, Section 6.6.1]
501 Not Implemented [RFC7231, Section 6.6.2]
502 Bad Gateway [RFC7231, Section 6.6.3]
503 Service Unavailable [RFC7231, Section 6.6.4]
504 Gateway Timeout [RFC7231, Section 6.6.5]
505 HTTP Version Not Supported [RFC7231, Section 6.6.6]
506 Variant Also Negotiates [RFC2295]
507 Insufficient Storage [RFC4918]
508 Loop Detected [RFC5842]
509 Unassigned
510 Not Extended [RFC2774]
511 Network Authentication Required [RFC6585]
512-599 Unassigned

Wait! The Web Isn’t Dead After All. Google Made Sure of It | WIRED

Wait! The Web Isn’t Dead After All. Google Made Sure of It | WIRED

IN 2010, THE web died. Or so said the publication you’re reading right now.

In a WIRED cover story that summer, then-editor-in-chief Chris Anderson proclaimed the demise of the World Wide Web—that vast, interconnected, wonderfully egalitarian universe of internet pages and services we can visit through browser software running on computers of all kinds. We had, he said, departed the web for apps—those specialized, largely unconnected, wonderfully powerful tools we download onto particular types of phones and tablets. “As much as we love the open, unfettered Web,” he wrote, “we’re abandoning it for simpler, sleeker services that just work.”

At about the same time, Rahul Roy-Chowdhury took charge of the Google team that oversees Chrome, the company’s web browser. “I remember the ‘Web is Dead’ article very clearly,” he remembers. “I thought: ‘Oh My God. I’ve made a huge mistake.’” Needless to say, he didn’t really believe that. But there’s some truth in there somewhere. Though the web was hardly dead, it was certainly struggling in the face of apps. Six years later, however, Roy-Chowdhury believes the web is on the verge of a major resurgence, even as the world moves more and more of its Internet activities away from the desktop and onto phones.

As evidence, he points to the growing popularity of the mobile version of Chrome. This morning, as Google releases the latest incarnation of its browser, the company has revealed that a billion people now use Chrome on mobile devices each month—about the same number that use it on desktops and laptops.

But Roy-Chowdhury goes further still. After another six years of work, he says, Google and others have significantly improved the web’s underlying technologies to the point where services built for browsers can now match the performance of apps in some cases—and exceed it in others. “The web needed to adapt to mobile. And it was a rocky process. But it has happened,” he proclaims from a room inside the Google building that houses the Chrome and Android teams. “We’ve figured out.”

Pelican Books

Pelican Books

Read on any (or all) of your devices

Whether you are reading on a smartphone, tablet or widescreen monitor, the text adapts to offer the ideal reading experience for any screen size.

Always pick up where you left off

Start reading a book on your phone on the way to work, continue at your desk over lunch, and pick it up again in the evening with your iPad.

Your reading position is automatically bookmarked and synced across all your devices.

Highlight and share passages

Highlight a passage of text to save for later, or share your favourite extracts with friends on social media.(Highlighting is only available on laptop / desktop devices at the moment – we’re working on bringing it to mobile soon.)

All Pelican books are available to read online. Read the first chapter for free, and unlock the full book for £4.99.

How Gmail lets spammers grab your attention with emoji ← Terence Eden’s Blog

How Gmail lets spammers grab your attention with emoji ← Terence Eden’s Blog

So, what’s going on here? How have they got an animated image into the subject line?

Here’s the raw text of the message’s subject line:

1
Subject:=?UTF–8?B?876tqQ==?==?utf–8?q?__=79=6f=75=27=76=65=20=62=65=65=6e=20=63=68=6f=73=65=6e=20=66=6f=72=20=33=30=20=66=72=65=65=20=73=70=69=6e=73_?==?UTF–8?B?876tqQ==?=

Let’s take a look at the code sequence at the start and end of the subject: =?UTF-8?B?876tqQ=

As all good geeks know, characters outside the ASCII range are encoded as Base64 in emails.

The resultant character is U+FEB69 – a “Private Use” character which has no defined representation in Unicode.

For most of us, the character “󾭩” doesn’t display as any meaningful symbol – but on the web version of Gmail, it shows up as: B69, a flashing star.

WTF?

Ok, here’s what’s going on…

Way back in the midsts of time (well, about 2009) there was no standard for Emoji. Each company made use of Unicode’s private use characters in a different way. If you had a phone from Google and sent a message using the “Glowing Star Emoji” to a phone made by another manufacturer – the symbol would either not display properly, or show up as a completely different character!

Obviously, in an interconnected world, such a situation is untenable – so Google and several other companies set up the Emoji4Unicode project.

Google uses Private Use mappings to represent Emoji (“picture character”) symbols in Unicode text. These characters are commonly used by Japanese cell phone carriers. This project makes these mappings available.

Google and other members of the Unicode consortium are also developing a proposal for the addition of standardized Emoji symbol characters to Unicode.

The Unicode consortium banged some heads together (in a friendly way) and everyone agreed on a new standardised set of characters.

The new Unicode standard has “Glowing Star” set as U+1F31F and looks like this: 🌟.
(If your computer doesn’t support Unicode 6.0 you can take a look at the official reference chart.)

But the old version lives on! The animated GIF lives at https://mail.google.com/mail/e/B69where it is used for the web version of Gmail. (You can alter that end number to get all manner of odd characters.)

Modern Android phones still recognise this relic – although, in Google’s typically slapdash fashion, Android’s Gmail app won’t display the animation in the subject line, only in the body:

Gmail Flashing

The same happens with the iOS version of Gmail. Animated in the body, not in the subject line,

Try it yourself by sending an email with the subject and body “Star 🌟 vs Animated 󾭩”.

It doesn’t seem to work in Google Hangouts – or any other Google apps, just mail.

Interestingly, when sending this characters from the web or Android version of Gmail, it adds an “X-Goomoji-Subject” header and automatically converts the characters to GIFs. The Unicode is completely stripped away from the message.

So there we have it. An ancient form of Emoji, probably all but forgotten, has been resurrected by spammers in the hope that you’ll notice their wares.

What a load of 󾓴!

Web Trend Map (May 2009)

Web Trend Map – Test

(circa.  May 2009)

The Web Trend Map is a yearly publication by Information Architects Inc. (iA).

It maps the 333 leading Web domains and the 111 most influential Internet people onto the Tokyo Metro map.

Domains are carefully selected by the iA research team in Zürich and chosen through dialogue with map enthusiasts.

Each domain is evaluated based on traffic, revenue, age and the company that owns it.

The iA design team in Tokyo assigns these selected domains to individual stations on the Tokyo Metro map in ways that complement the characters of each.

For example, Twitter is located in Shibuya this year: Shibuya is the station with the biggest buzz.

Google is placed in the busiest, most highly trafficked train station in the world: Shinjuku.

The New York Times, the »Old Gray Lady«, is located in Sugamo—a shopping paradise for Tokyo’s grandmothers.

We grouped closely-associated websites and tried to make sure each individual domain is on a metro line that suits it, with close attention paid to the intersections.

As a result, the map produces a web of associations: some provocative, some curious, others satirically accurate.

Why Tokyo Metro? Because it works beautifully.

You can evaluate a domain based on its station’s height,width andposition.

Height: A station’s height represents its domain’s success. »Success« refers not only to traffic, but also revenue and trend.

Width: A station’s width represents the stability of the company behind its domain. However, not every large corporation has a large building.

Unless its domain has proven itself as a significant online component, its station remains thin.

Position: A station’s location on a metro line indicates the group it belongs to.

A station‘s position on the map—whether inside the main line, on the main line, or outside the main line—indicates whether it is a part of the tech establishment, a traffic hub, or an online suburb.

The Curse of Storage

The Curse of Storage

Our ever-growing collections of information and objects can lead to thoroughly modern crises that echo the past. Commentary by Momus.

I’ve been thinking about the parallel between object storage and information storage — apartments and computers — ever since visiting an interesting exhibition at London’s Barbican last month.

Future City looks at experiment and utopia in architecture over the last 50 years. I was particularly impressed by a quote from Japanese metabolist architect Kiyonori Kikutake. “A Japanese room is determined by information,” Kikutake was quoted as saying, “whereas a Western room relies on objects.”

I thought immediately of Kyoichi Tsuzuki’s photographs of Tokyo apartments. These tiny places (I lived in one myself for a year) tend to consist of an empty living space — typically a tatami-covered floor — surrounded by densely packed information-storage systems.

The information “saved” to these spaces might be clothes, records, knickknacks, magazines, toys — the obsessively collected, meticulously arranged, somewhat pointless “hard copy” of countless shopping trips. The tatami-and-futon floor space, meanwhile, is where processing happens.

There, the room’s occupant does his living, eating, loving, sleeping, thinking. This is the room’s RAM, its processor, where the present moment is all. Here the timeline of human attention scans through a book, a manga, a magazine or website, one page at a time.

Never one to pass up an opportunity to think of my lifestyle as Japanese rather than Western, I decided there and then to create a “Japanese” apartment in Berlin, a place devoted to information and the storage of information. My new apartment, after all, was on the small side. I’d have to resort to Japanese tricks and a Japanese sensibility to make it work. I had in mind not just Tsuzuki’s photographs of stashed Tokyo pads, but also a lovely book I have (it’s in a box somewhere) of photographs of Japanese writers’ rooms.
Continue reading “The Curse of Storage”