線下服務應用與HTML規範發展

線下服務應用與HTML規範發展

HTML的發展簡介
英國科學家Timothy John Berners-Lee是全球資訊網的發明者,1990年他制定HTML(Hypertext Markup Language),並寫出瀏覽器和伺服器軟體,1993年發佈首個HTML規範的提案,並在1995年完成”HTML 2.0″。自1996年起,HTML規範乃由全球資訊網協會(World Wide Web Consortium,W3C)維護,全球資訊網協會又稱W3C理事會,1994年10月在麻省理工學院電腦科學實驗室成立,為解決Web應用中不同平台、技術和開發者帶來的不相容問題,W3C擬定了諸多全球資訊網的公共標準 (例如:HTML、XML、CSS等),因而大幅提昇全球資訊網之互通性,帶動WWW世界之迅速發展。

HTML市場需求演進
W3C著重於各種標準的研發、制定及推廣,以達到普及使用的目的,此外,網際網路前進的腳步,需要搜尋引擎巨輪帶領,為達成發展全球資訊網的推廣效益,因此HTML meta 多個標籤定義給搜尋引擎閱讀,以增加其資訊的歸納與處理效能。然而傳統的HTML開發的初衷是面向PC的,而隨機移動終端的不斷出現,HTML已經滿足不了市場的需求,所以2000 年制定新一代的標註語言XHTML,它是以 XML 技術為基礎的HTML,其使得 Web 世界朝向模組化以及可擴展化進一步發展。但隨著近年智慧手機的大量普及,網際網路進入行動服務時代,服務型態著重於用戶與實體資訊的連結關係,開始導向以人的位置為中心的服務價值,因此線下服務搜尋的需求與日俱增,但HTML 規範尚未與時俱進,致使當前Location Base相關的線下服務應用,大部分僅能以App做為設計應用。

線下服務應用的現況
App設計應用在智慧手機發展初期,因硬體效能不足與瀏覽環境限制等因素,確有其階段性的發展需要,誠如PC發展歷程,也是由App應用慢慢轉向開放性的Web應用,然而主流App採用資料串接架構,實際上是一種封閉系統,難以如同開放性的Web系統,去發展跨應用跨服務的整合入口,加上用戶安裝App數量十分有限,致使大部分App在用戶端沒有市場,根據近年對於App應用統計,排名前五的App囊括80%以上流量,而且高達90%以上的殭屍App,已形成嚴重的軟體資源浪費問題,不僅不利於資訊共享的線下服務,也不利於發展跨應用跨服務的整合入口,所以當前亟需定義一個符合線下應用的HTML規範,推動以Web of Things(WoT)方式設計線下服務應用, WoT 之所以重要,在於它不僅可以轉化為實體化的Location Web,也解決了物聯網互通互連的問題,並形成有利於線下搜尋引擎發展的環境。

線下服務應用的規範
HTML meta 標籤提供網頁內容資訊給瀏覽器或是搜尋引擎閱讀,例如網頁內容的描述、網頁重要關鍵字、網頁編碼等都是常用 meta來標示的網頁資訊,另外還有網頁作者、網頁發佈時間、所使用的編輯器等資訊,也可以透過 meta tag 來標示,meta的功能用來註明這些網頁資訊,讓閱讀的瀏覽器或是搜尋引擎可以掌握相關背景,進而達成預定的瀏覽效益與資訊揭露目的。傳統的 HTML meta 標籤的功能,共有兩個重要的部分,分別為 name 與 http-equiv,隨著 HTML 的版本更新,到現在最新的 HTML5 已經開始支援 charset 的語法,以下就針對先前搜尋引擎需要索引的name部分製作成表,提供給各位參考。

線下服務Web應用的目標,是以URL對應實體世界的每一物件,對應實體物件的實際作法,就是以URL對應物件方位,雲端的Web便可轉換成為所謂的「Location Web」,即能達成線上線下虛實融合 (OMO, Online-Merge-Offline) 的結果,對於OMO效益,若以線下搜尋引擎的應用為例,以關鍵字搜尋雲端服務內容,便能對應服務內容與實際方位,得到線下服務的搜尋結果。線下服務應用所需求的meta name定義,根據線下搜尋引擎先行者-大千搜尋,所提供的規範定義參考如下。

對於應用於公車、計程車等運輸工具,行動服務的移動方位定義為開放資料,參考大千搜尋制定的規格,以URL方式讀取位置資訊,行動服務API格式之定義如下:

http://第三方網址/od/data/api/{dataId}? $format={format} &$top={top} &$skip={skip} &$orderby={orderby} &$filter={field} eq {value}

線下應用的Sitemap規範
「Sitemap」規範為網站地圖,使用者可以在其中提供網站網頁、影片和其他檔案的相關資訊,並說明各個網頁和檔案之間的關係,這使搜索引擎可以更有效地對網站進行資訊收集,並查找可能與網站其餘內容隔離的URL。Sitemaps協議是一個URL內容,它包含robots.txt協議,用以對URL排除搜尋的補充說明,Sitemap 也會告訴搜尋引擎網站上的哪些網頁和檔案較為重要,並針對這類檔案提供有價值的資訊,舉例來說,Sitemap 會針對網頁提供最近更新時間、變更頻率以及替代語言版本等相關資訊進行檢索,此外,對於需要補充更新的線下應用Web而言,基本上完全相容於Sitemap 舊有的通用規範,根據大千搜尋提出的解釋與說明,惟需進一步補充提交內容規範,其要點說明如下:

• 基於對應實體萬物之任一物件,包含草木、裝置、車輛、商品、商店等, 任一物件必需以URL形式,對應其唯一的URL網址以及方位,關於方位對於Sitemap提交之差異,則區分為定點位置與可移動位置兩種情況。

• URL對應的物件為定點位置之情況,Sitemap提交方式參考如下左圖,若以商店與商品關聯為例,商店與商品網址互聯為內網鏈接,而且定義屬於同一空間位置,則提交內容可以各別提交商店與商品的URL,或者可以提交一個商店的URL,針對關鍵字搜尋目的,所提交的商店URL,可以包含內網鏈接商品的商店URL,或是商品資訊都在同一頁面的商店URL。

• URL對應的物件為可移動位置之情況,Sitemap提交方式參考如下右圖,在此的說明也以物件定義為商品為例,此商品的 URL必需採用各別提交方式,且提交必須一併附上行動服務API之 URL。

行動服務應用模式
線下行動服務應用,根據大千搜尋提供的參考模式,主要可以區分為六種方式,模式(A)以人做為應用標的,服務者在搜尋引擎註冊會員帳號,並且提案所屬的Web服務項目,便可利用線下搜尋引擎的App定位器,將位置資訊傳送至搜尋引擎伺服器,服務者的Web服務項目,即能對應其即時服務方位。模式( B)以車輛做為應用標的,服務公司在搜尋引擎註冊專用會員帳號,並且提案車輛的Web服務項目,然後將帳號分配旗下的司機使用,車輛利用內建的車機定位器,將位置資訊匯傳至搜尋引擎伺服器,車輛的Web服務項目,即能對應其即時服務方位,司機也可以應用手機系統,在Web服務項目與客戶做雙向互動。

模式( C)亦以車輛做為應用標的,此為目前市場的主要應用架構,應用在現行的車隊行動服務系統,定位系統可為車機或手機,車輛的Web服務項目無需額外提案,車隊所屬的Web服務資訊,僅需符合線下服務應用規範,並支援搜尋引擎行動服務API規格,搜尋引擎便可自動抓取Web服務資訊,且將位置資訊匯傳至搜尋引擎伺服器。模式( D)的應用場域在室內,可以利用RFID或者藍芽做為室內定位技術,Web服務項目亦無需額外提案,模式( D)應用相似於模式( C)。

模式( E)以及模式(F)車機定位系統,採用直接連結搜尋引擎伺服器的方式,當線下搜尋成為開放式應用平台,定位器生產廠商則可依據公開的介面規格,直接將位置資訊與定位器相關控制功能,與搜尋引擎伺服器做服務串接,通常這樣的應用模式,平台將對生產硬體廠商收取每台硬體串接費,硬體廠商可以節省額外開發平台的費用。

IoT Search 大千搜尋: https://iot-search.com

文章授權(創用CC授權)
by-nc-sa
comment

CONTACT US

We're not around right now. But you can send us an email and we'll get back to you, asap.

Sending

©2020 Business Next Publishing Corp. 聯絡、建議隱私權

Log in with your credentials

or    

Forgot your details?

Create Account