2000年制定新一代的标注语言XHTML，它是以XML技术为基础的HTML，其使得Web世界朝向模组化以及可扩展化进一步发展。而当前亟需定义一个符合线下应用的HTML规范，推动以Web of Things（WoT）方式设计线下服务应用，原因在于它不仅可以转化为实体化的Location Web，也解决了物联网互通互连的问题，并形成有利于线下搜寻引擎发展的环境。

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」，即能达成线上线下虚实融合 (Online-Merge-Offline；OMO) 的结果，对于OMO效益，若以线下搜寻引擎的应用为例，以关键字搜寻云端服务内容，便能对应服务内容与实际方位，得到线下服务的搜寻结果。线下服务应用所需求的meta name定义，根据线下搜寻引擎先行者-大千搜寻，所提供的规范定义参考如下。

图二

对于应用于公车、计程车等运输工具，行动服务的移动方位定义为开放资料，参考大千搜寻制定的规格，以URL方式读取位置资讯，行动服务API格式之定义如下:

http：//第三方网站/ od / data / api / {dataid}？

图三

图四

线下应用的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) ~ 模式(F)。

模式(A)以人做为应用标的，服务者在搜寻引擎注册会员帐号，并且提案所属的Web服务项目，便可利用线下搜寻引擎的App定位器，将位置资讯传送至搜寻引擎伺服器，服务者的Web服务项目，即能对应其即时服务方位。

模式( B)以车辆做为应用标的，服务公司在搜寻引擎注册专用会员帐号，并且提案车辆的Web服务项目，然后将帐号分配旗下的司机使用，车辆利用内建的车机定位器，将位置资讯汇传至搜寻引擎伺服器，车辆的Web服务项目，即能对应其即时服务方位，司机也可以应用手机系统，在Web服务项目与客户做双向互动。

图六

模式(C)亦以车辆做为应用标的，此为目前市场的主要应用架构，应用在现行的车队行动服务系统，定位系统可为车机或手机，车辆的Web服务项目无需额外提案，车队所属的Web服务资讯，仅需符合线下服务应用规范，并支援搜寻引擎行动服务API规格，搜寻引擎便可自动抓取Web服务资讯，且将位置资讯汇传至搜寻引擎伺服器。

模式(D)的应用场域在室内，可以利用RFID或者蓝牙做为室内定位技术，Web服务项目亦无需额外提案，模式(D)应用相似于模式(C)。

图七

模式(E)以及模式(F)车机定位系统，采用直接连结搜寻引擎伺服器的方式，当线下搜寻成为开放式应用平台，定位器生产厂商则可依据公开的介面规格，直接将位置资讯与定位器相关控制功能，与搜寻引擎伺服器做服务串接，通常这样的应用模式，平台将对生产硬体厂商收取每台硬体串接费，硬体厂商可以节省额外开发平台的费用。

图八

(本文作者黄柏尧为大千资讯科技创办人兼执行长)