來一場超級杯的地理資料視覺秀!

之前使用過Torque去呈現台灣地區OSM的2012年中編輯的歷程

沒想到CartoDB自已做的案例更酷了! 利用2015年SuperBowl期間的Twitter資料做一場資料秀,其實資料的處理不難,先在Twitter API上取出了含有#SB49的推文(tweets),區分出是新英格蘭愛國者(@Patroits)和西雅圖海鷹(@Seahawks),藉由推文(tweets)上帶有的xy座標,就可以將推文定於地圖上。當然,因為使用CartoDB所推出的Torque.js,這些資料必需匯入CartoDB,而這就是CartoDB的商業模式,它提供很好的地理視覺化工具,但資料量大或瀏覽量高時,就必須收費了!

這場超級杯的資料視覺秀,很有趣!

在18:30開場時,綠點海鷹充滿了西雅圖,而紅點的愛國者則聚集在新英格蘭,一開始就有地域上的差 異。

Screenshot 2015-02-11 17.45.24

在19:13時,新英格蘭首度觸地得分,頓時紅成一片。而19:36時,換海鷹得分則整個變成綠色。比分7:7平手!
touchdown_patriots#SB2015touchdown_seahwaks#SB2015

後來雙方再各得7分,在中場時,還是14:14的平手局面。而超級杯一直是美國本土收視率最高的節目,今年(2015)還破了最高收視率,而中場秀一直眾所矚目的焦點,廣告收益頗為驚人,然而,Katy Perry(@katyperry),我實在不認識,冏! 但從推文的量看得出來她果然是推特(Twitter)關注度高的女星。

@katyperry#SB2015

這場比賽非常戲劇化,海鷹和愛國者一路互有得分,但第四節前,海鷹一度是領先10分,但愛國者在第四節一路追趕,逆轉局面,雖然在終場前,海鷹落後3分,但球權在海鷹手中,且已經來到Goal line前不遠,只要一個touch down就完全翻盤,但關鍵出現在最後的26秒,受國者的菜鳥Malcolm Butler,居然抄掉海鷹四分衛 Rusell Wilson的傳球,而斷送海鷹的一線生機。因此,終場雖然是愛國者贏了比賽,海鷹的球迷幹譙聲浪應該不小,使得顏色有點慘綠了 XD! 整場的Highlight在Youtube,可以看得到,透過這樣地理視覺化,更讓人可以了解到球迷的動態。

Mac_BZ#SB2015

 

開放街圖(OpenStreetMap)與政府的合作

政府與OSM的合作應該可以為二種模式,一是政府資料匯入OSM,經由Mappers修改、更新後,再被政府取回,另一種是OSM資料被政府資料庫吸收後,再釋出於社群,後者所收集到的案例,資訊都不是相當明確。以下案例的收集來自於下列幾個:

1. Government to OSM (to Government)

1.1 歐盟 Corine Land Cover匯入OSM

背景:

  • Corine Land cover 資料是由歐盟環境局(European Environment Agency, EEA)匯集各國土地利用分析成果所建立,多數是根據衛星影像所製作,比例尺為1: 100,000,有3個土地使用等級中有44土地使用類型。

授權: 

  • 根據這樣的授權條款,OSM社群認為這份資料集是可以匯入OSM的,在OSM中對於Corine Land cover介紹的wiki page中出現這麼一段句話,As such it can be imported into OpenStreetMap.

授權議題討論過程:

  • 尚未找到歐盟的那個政府單位有想把Corine的資料再取回政府資料庫。

運作方式:

  • 以法國為例,是在OSM中建立一個帳戶(CLCF06),透過這個帳戶匯入,由OSM社群成員與政府主管單位的承辦人一起將資料匯入。並標示資料來源,於source欄中,標示Union européenne – SOeS, CORINE Land Cover, 2006.
圖1: Corine Land Cover 資料匯入OSM後,資料屬性的標記
  • Corine Land Cover資料匯入OSM的問題
  • Corine Land Cover資料較粗,Mappers因為利用Bing Maps的衛星影像來繪圖,OSM可以得到較為準確的土地使用邊界。
  • Corine Land Cover和OSM對於土地使用的分類不一致。
  • 匯入過程不能覆蓋原有正確的資料。
  • 資料如何驗証其正確性。

 1.2. 紐約市政府與OSM合作

授權: 

  • 建物外框線和地址點位是依 2012 Open Data Law 釋出,幾乎是Public Domain,符合OSM  Contributor terms

運作方式:

  • 由Mapbox且是OSM社群的成員,將開放平台中的建物外框線和地址點位資料匯入OSM,Mapbox並負責開發程式去檢測建物與住址資料被修改,定時用email方式通知政府相關單位,如圖2。詳請看Mapbox的blog
圖2: Mapbox開放應用程式定期回報政府部門建物資料在OSM中的更動

1.3. 加拿大自然資源部和OSM的合作

背景: 

  • CanVec 是數位地圖參照產品,由加拿大自然資源部(Natural Resources Canada, NRCan)製作 is a digital cartographic reference product produced by Natural Resources Canada (NRCan),CanVec 起源於加拿大最好的資料來源,以國際慣用的標準向量格式提供了高品質的地形資訊。CanVec是多來源的產品,有之前的國家地形基本圖(National Topographic Data Base, NTDB)和現在的 GeoBase (www.geobase.ca)。CanVec含有超過90種地理地形實體,並組織成11種主題。NRCan希望透過與OSM整合之合作模式,讓OSM Mappers更新政府部門的圖資。

授權:

運作方式:

  • NRCan把CanVec的圖資轉成.osm格式,讓OSM Mappers可以利用OSM的地圖編輯器,如JOSM、Potlatch等,去輸入和修改資料,NRCan會定期比對OSM的資料,以偵測被修改的地方,使政府圖資保持最近的狀態,圖3為合作模式的示意圖。圖4是渥大方華地區NRCan和OSM地圖的一個比較。 
圖3: NRCan和OSM的合作模式
圖4: CanVec和OSM的變遷偵測。灰色為OSM的道路圖,綠色為OSM中沒有的資料,紅色為CanVec沒有的資料

 1.4. 紐西蘭土地資料(LINZ)匯入OSM

背景:

授權: 

  • 尚未找到紐西蘭政府要將匯入OSM的LINZ再取回的相關消息。

 1.5.日本國土地理院「国土数値情報」的匯入OSM

背景:

授權:

  • 尚未查到有國土地理院將匯入OSM的国土数値情報再取回,並匯入政府資料庫的相關訊息,因此也沒有在這方面有智財權和授權上的討論,或是可能有,但是以日文。
  • 運作模式: 由OSM Mappers 自行轉入OSM,但得加”source=KSJ2“的tag,以標示資料來源。

2. OSM to Government (to OSM)

2.1. 海地震災後的製圖

2.2.HOT在蒙古烏巴托促進智慧城市的製圖

參考資料

歐盟如何區分高價值的開放資料?

政府開放資料的推動通常遇到一個問題是,業務主管機關不知道什麼資料應該開放,而資料的使用者則不知道有什麼資料可以被開放,而由再使用資料產生出價值或商業模式,歐盟所做這篇報告「Report on high-value datasets from EU Institutions」,即提供了一個思考的方向。

歐盟開放資料平台(EU Open Data Portal, EU ODP) 扮演的是歐盟及所屬機構的資料開放與資料上架,但資料的主管機關[1]往往不知道應該拿出什麼樣的資料在EU ODP上開放。理論上而言,愈多資料被開放,就愈有價值,但就有限的資源下,資料主管機關在進行開放資料的業務時,若能區分出什麼高價值的資料,而優先開放,是事半功倍,且資料主管機關最想知道的事。

一方面,就資料主管機關的觀點而言,資料集的高價值性是它們有沒有符合下列條件:

  1. 資料是否能促進政府透明化;
  2. 資料的開放是否受到法律責任的約束;
  3. 資料是否直接或間接關係到公共任務;
  4. 資料是否能實現成本降低;
  5. 資料使用的目標群眾之型態與規模。

另一方面,就資料再使用者的觀點而言,高價值的資料集是具有高度被使用價值和被再使用潛力,因此有機會促成下一步(新的)商業模式。

根據二個方面觀點所成的定義,該計畫區分出261筆高價值的資料集,來自於57個不同機關單位,其中144個還沒在EU ODP上架,恰可以根據分析成果,因資料具有高價值,而要求開放,另外的117筆,已經在EU ODP 上架的資料中,有26筆資料集是2星級或更差的資料,應該著手將資料升級為開放格式或進階到連結(linkable)等級。

過去,對於政府應該開放那些資料,許多的重點都在放,資料使用者端的價值或利益,但這個報告帶來的啟發是,政府是不應該站在和人民一樣的角度在看資料開放的問題,資料開放為政府所帶來最直接的「高價值」應該是政府效能提升,如透明化、成本降本和改善公共事務的推動等,應該不是和民間、企業一樣買資料,想著加值的利益,因為這是民間或企業想的事情,我想,這是當前台灣開放資料的徵結。

[1] 原文是用data publisher,但就台灣而言,用資料業務主管機關似乎比較貼近些

開放資料推廣的雜想

什麼是開放資料的推廣? 要怎麼推廣開放資料?應該還有更多可以做的事吧!

1. 除了hackathon,應該還有不一樣的thon,如 ideathon, mapathon, editathon….。

2. 除了APP競賽,更應該強調開放資料混搭的創新。

3. 除了APP競賽的成果,需要更多的開放資料成功案例。

4. 除了政府開放資料,個人、非營利組織(民間社團)、到企業都可以開放資料,從上到下、或從下到上,整合資訊的過程即是推廣。

5. 除了開放資料,如何使用開放源碼處理開放資料更有吸引力。

6. 除了政府補助的開放資料課程,應該還有大學校園的課程、線上課程、工作坊…..等。

7. 除了民間的課程,政府也應該讓公務人員上更多的課程。

8. 除了專業的內容,應該思考如何將有些開放資料遊戲化(gamification)。

開放街圖(OSM)將成為谷歌地圖的(Google Map)的最大爭競者嗎?

常有人問起,開放街圖(OpenStreetMap)能不能商業化? 或開放街圖能有什麼商機? 隨著上個月Telenav宣布他們的產品Scout捨棄了與TomTom的合作關係,而轉為使用開放街圖,這個問題似乎有一個強而有力的答案。事實上,不少網路媒體、甚至是紐約時報都認為TeleNav的做法將為適地性服務(Location-Based Service, LBS)和導航產業的市場帶來許多衝擊和轉變,但就一個圖客(Mappers)而言,開放街圖能被一家具規模的導航公司所使用,其實背後有更有意義。

TeleNav uses OSM

利用開放街圖為導航地圖這件事並不新鮮,開放街圖的維基上有一堆這些的服務,但能被一個在那斯達克(NASDAQ)上市的導航商所用,就別具意義,顯示出群眾外包(Crowdsourcing)的地圖己經被重視,且逐漸進入商業使用的階段。然而,群眾外包的地圖最大的疑慮是資料品質,像開放街圖在這種開放的系統,誰都可以來畫地圖,很難保證被畫上的地圖是正確的,但開放街圖並沒有太多的限制,每個帳戶是平等的,只要有一個帳號,誰都可以去畫地圖、改地圖,在沒有自動檢核機制之下,靠的是圖客們的檢視,愈多人使用,正確就會愈高,就和開放源碼一樣,符合所謂的Linus’s Law (given enough eyeballs, all bugs are shallow)。TeleNav捨棄了與TomTom合作,敢用群眾外包的圖資,顯示處理開放街圖到導航可使用的水準之成本己經不高,與其花錢去買地圖公司的圖資,倒不如把錢拿來處理開放街圖,讓自己的公司充份地掌握自己的LBS服務商品中的地圖,不用只與一家地圖公司合作,地圖圖資被一家公司所掌握。所以TeleNav在今年(2014年)1月底先以2千4百萬美元買下在德國柏林的新創公司Skobbler,其實就是想買進轉換開放街圖資料的技術,就更不用說,Steve Coast在去年(2013年)9月從Microsoft跳槽到TeleNav,早早在為使用開放街圖做準備。

地圖內容己經不是單純地是單一地圖公司提供就可以滿足現今適地性服務(LBS),Google在去年(2013年)6月也是約13億美元天價買下以色列的LBS新創公司其目的就是提供地圖與用戶互動服務,讓用戶可以透過地圖的使用能回饋到Google Map,而能讓地圖內容更符合用戶需求,當然戰略上也是為了Waze不讓Facebook或Apple給拿走,去擴增適地性服務(LBS)。 適地性服務(LBS)與社群媒體(social media)二者己經是密不可分,一方面,地圖內容如何透過社群媒體結合更多用戶來改善地圖內容、提高更新速度,另一方面,如何透過地圖使用行為,來改善適地性服務(LBS)方式,以提供更貼近人心的地理服務,無論如何,用戶才是決戰的重點,Waze號稱他們在全球有5千萬個用戶,而開放街圖呢?2014年開放街圖的全球註冊的用戶已經達160萬人,這個數量與Waze顯然有很大的差距,但二者用戶的本質是相當不同的,開放街圖註冊用戶是地圖的貢獻者,不是單純的使用者,反觀有多少人在Waze上貢獻資料呢?TeleNav當然看上這點,上那找這麼多的地圖貢獻者來繪製、編修地圖,開放街圖的社群成自然而然成為最好的後盾。

TeleNav使用開放街圖的案例,事實上就是一個開放資料成功的應用案例。就TeleNav而言,TeleNav花的錢並不是買圖資,而是技術,TeleNav所省下的成本可以用來增強導航功能,而使得他們的產品在市場上更有競爭力,另一方面,開放街圖並沒有因為TeleNav或其它廠商的使用,而更動它本來既有的運作方式,從繪製編修地圖到社群的活動都不會因為這樣而改變[註1]。一樣的道理,在談開放政府資料加值或者是產業,就是在於開放政府資料如何省去廠商資料成本,而能專注地在於技術服務的開發,這對於新創公司其實是大利多的,因為過去政府許多資料不是很貴,就是開放授權講不清,往往是有管道、有關係、大資本的公司才可以拿到資料,透過政府開放資料,免除了這樣的問題,新創公司能專注於資料使用上的創意,而不是在資料取得就己經先吃癟,怎麼能夠期待有創意,更沒辦期待像Skobbler這樣的公司出現。

因此開放街圖所開創的經濟模式,有別於以往Google Map的模式,各位可以看看,在最近5年來的競合之下,走Google Map模式的地圖商、導航商,其實只剩下Google Map了,不但國際大廠連連整併,就連Local的地圖服務商也很難掙下去,台灣有UrMap呀! 現在有多少人還用?我相信TeleNav的案例一定會帶給許多人啟發,但走開放街圖的模式是否能夠成功,這無法保證,但絕對會是另一個機會,隨著開放街圖的成熟,一定會有愈來愈多人拿來商業使用,逐漸成為有別於Google Map模式的競爭者。

[註1]有中國人前陣子頻頻大規模的修改地圖,把台灣的地名都改成簡體了,猜想和TeleNav在中國也有分公司,要在中國地圖產品,必需符合中國法律有關

10個政府資料不願意開放的的理由

因為要去參加一場與開放資料相關的會議,於是乎,列了10個政府資料不願意開放的的理由。
1.資料涉及國防、社會安全議題敏感
2.資料涉及個人隱私
3.擔心資料品質不好,怕開放後被質疑
4.擔心資料被外國公司使用,有資訊外洩之嫌
5.擔心被外界誤用,如石虎的調查資料怕被反「13線拓寬工程」的人看到
6.主張智慧財產權,例如資料生產單位有著作人格權
7.資料為財產,怎麼可以隨便給你用
8.因為規費法,要付費後才可以拿到資料
9.沒有適宜的法令讓我們的資料開放
10.你就用嘛! 不要問這麼多

為什麼HTML不能實現語意網?

在網路搜尋資料時,最大的阻礙是資訊使用者與資訊提供者之間所使用的語意不同,如果使用者無法以 “正確”的語彙來搜尋,所得結果不是錯誤,就是眾多的搜尋結果中只有少量使用者想要的結果,以致於使用者無法擷取提供者的資訊,而提供者無法將資訊送達於使用者,這是因為搜尋工無法了解網頁中資訊的意義,為解決這樣子的問題 Tim Berners-Lee,全球資訊網(World Wide Web)之父,於2001年提出語意網的概念。在語意網中,在網頁中的文字與媒材會被連結到知識本體中相對應的概念或及其關係,而此知識本體中的概念是充份被定義,且概念中彼此的關係亦被清楚的說明,因此使用者在搜尋資料時,語意網的服務可以提供更為符合需求。
然而,目前網頁的技術—超文字標記語(Hypertext Markup Language, HTML)是無法達到語意網的實現,因為HTML的標記(tag)只針對網頁內容在瀏覽器中顯示的方式所設計,如台灣是說明台灣一詞在網頁中顯示為粗體,但可使用的標記限定於技術規格中所列,而另一種資料交換常使用的格式—可擴展標記語言(Extensible Markup Language, XML) ,雖然XML對於標記名稱沒有限定,著重於標記的結構,但這只使用資料具有語法上結構,而沒有達到語意層級。為實現意語網,W3C (WWW Consortium) 在XML的基礎上訂定了另一種具有語意的資料編碼方式,為資源描述架構 (Resource Description Framework, RDF),如class, subclassOf, property, subpropertyOf, domain, range, sequences, collections, 和其它一些相關語彙,資料經過RDF的編碼後,可所解析RDF的工具可了解資料的語意,如二個概念中具有一個subclassOf 的關係,可以知道這二個概念有上下從屬的關係,因此常被用來編寫簡單的知識本體,通常都是具有概念階層上語意關係。
更進一步,網路本體語言 (Web Ontology Language, OWL)則提供更多邏輯關係的定義來使資訊的語意更明白,包含函數化關係( functional properties)、反關係(inverse relations)、遞移性(transitivity)、同義字(synonyms)、基數限制(cardinality restrictions)和附加概念(additional concepts)。依照使用邏輯關係複雜程度,OWL三種版本可以使用,分別為 OWL Lite、OWL DL、和OWL Full。 OWL Lite 支持使用者定義分類層級的架構和簡單的限制; OWL DL中的DL即是描述邏輯(Description Logic),表示所使用的邏輯規則是以描述邏輯為基礎;而OWL Full 顧名意義即使用所有OWL的語彙,且有更多有彈性的定義,但目前多數工具或軟體不支援OWL Full所編碼的資料。語意網 (Semantic Web)將帶來Web 結構化有意義的內容,且開創了一個環境其中軟體代理人可以網頁到網頁間的漫遊,很容易地實現使用者所需的複雜任務(Berners-Lee et al., 2001). 語意網不是另一種Web而是現在的延伸,可使人與電腦再好的合作,在語意網的第一階段中結構化現存的Web己經在進行,未來這些發展應引導出重要新功能,而成為一種“機器”,使了解資料且更好地處理資料 (Berners-Lee et al., 2001)。

連結感測器資料(Linked Sesnor Data): 從氣象測站到連結資料

緣起

會進行這個Linked Sesnor Data的試作有一些緣由,把時間拉回2013年8月1日在環保署召集的「環境資源資料開放專家諮詢會議」,開會目的除了討論環保署資料開放平台,更是在於討論紫外線測站資料來當開放資料五顆星的範例。太酷了! 環保署願意進行開放資料5顆星的示範是一件很棒的事! 不但有助於環保署所屬開放資料品質的提昇,也可以刺激其它政府部會對於開放資料品質的關注。但會中業務單位所簡報的那個「紫外線測站的五顆星開放資料」是問題多多,對於OWL/RDF有了解的人,其實不難發現簡報中的那份RDF是有問題的,況且把資料編譯為RDF格式充其量就是4顆星等級,怎麼可以說是5顆星呢?再者,所謂的5顆星開放資料是要連結什麼呢!?

這個問題後來成為與會專家要給予的答案。資料集與資料集要連結,這之間就必需要有某一些關連,也就是所謂的context,以致於資料集中的某一個entity可以與另一個entity以某種形式相連,在普遍的做法就是用owl:sameAs來表達在不同資料集中的二個entity是一樣的,以我有限的所知,資料集之間的context可以由三個特性來思考: 地理空間(Geospatial)、時間的(Temporal)、和主題屬性的(Attributiive),以環保署開資料平台中的紫外線測站資料為例,有可能連結的部份看來只有地理空間的特性了! 就資料特性而言,若環保署要做Linked Open Data (LOD),建議應該朝向Linked Sesnor Data,就是把所有測站以OGC的Sensor Web Enablement (SWE)W3C SSN Ontology 二者來表達環保署中的測站,而測站所產生的資料則是以Linked Observation Data 來詮釋。

 

IMG_20140103_121214從Sesnor nodes組成sensor network,然後以OGC SWE來架構Sensor Web,所以容易再以W3C SSN Ontology表達

 

IMG_20140103_121156Linked Sesnor Data, Linked Observation Data, and Geonames

 
很遺憾的是,他們並沒有採納這些意見,在環保署開放資料平台上線後,12月初無意間看到,那個有問題的說明己經在環保署開放資料5顆星的頁面上,而有問題的RDF資料也提供下載。這種做法給了二個不好的示範,首先,在專家會議中,本人就不認為那是對的說明和對的RDF資料,但這些內容和資料還是上線了,好吧! 意見也給了,那專家會議的用意什麼? 另一個是比較嚴重的問題是,把錯誤的LOD說明和資料放在一個政府公署開放平台的網頁上,很容易就會誤導其它人,對於LOD的理解,開放也得開放「對」的資訊,是吧! 身為市井小民所幸可以透過平台「意見回饋」反應機制,向環保署說明,那份說明的LOD頁面和RDF資料有問題,哈! 意見回饋比專家會議有效耶! 環保署在一週後拿掉在資料開放平台上的那些LOD資料,所以大家己經看不到了,接著承辦這項業務的人員也來拜訪,並帶著修改的RDF來討論。的確,修改後的RDF,使用了標準語彙,如Dublin Core,但看起來就是一份單純由表格轉為RDF的文件,這不見得有錯,但語意的表達是相當弱的,對於紫外線測站詮釋,也就是紫外線測站所表達出的概念是什麼?並沒有辦法得知。

或許,你心中油然而生一個問題,「疑!那些LOD的資料,在網頁看起來都像是表格一樣,那資料轉成這樣有什麼問題?」嗯! 那些LOD的資料背後其實都有一個ontology來表達資料的語意,只是放上網頁為了瀏覽方便而表現成表格的形態,利用標準語彙也是在確保資料語意不被誤解,但ontology中,概念的結構和邏輯的規範可以使資料語意更為完備,並可以進一步達到邏輯推理,當然目前我們只需要達到將資料本身概念充份地表達,在這個紫外線測站的案例中,如同前面所說,還是採用W3C SSN Ontology來表達紫外線測站才是比較恰當的方式。

從建構知識本體(ontology)開始

這筆所謂的紫外線測站基本資料所記述的資料相當有限,主要項目如下:

  • 紫外線測站的中英名稱
  • 紫外線測站所在的縣市鄉鎮
  • 紫外線測站的空間座標和住址
  • 紫外線測站的發佈機關

這筆有限的資料能表達出的內涵確實不多,若只根據這些項目編出的ontology應該也很空洞,對於一個用來表達紫外線測站的ontology而言,不僅僅是要表述地理空間的描述,更重要是要表達什麼是紫外線測站和紫外線測站觀測什麼。根據W3C SSN Ontology 對於感測器(Sesnor)的描述和定義,可以重新想想,要如何重新表達這筆紫外線測站資料:

  • 紫外線感測器本身是用來測量紫外線(Ultraviolet)的
  • 紫外線觀測是以紫外線指數(UV Index)
  • 紫外線感測器是裝在中央氣象局的氣象站或環保署的空氣監測站
  • 無論是氣象站或空氣監測站都有空間座標、地址、和所在行政區域

W3C SSN Ontology 這份報告附有很多案例是可以依循的,其中對於Linked Sesnor Data 就有一個案例,對於紫外線測站資料,不就是一個很好拿來模仿的案例! 對於感測器(Sesnor)的描述和定義,這個案例中主要使用W3C SSN ontology和DUL(DOLCE Ultra Light) ontology,此外也描述感測器(Sesnor)觀測能力和裝在氣象局的事實,更重要的是這樣表達的感測器(Sesnor)是可以被連結(link)。根據這個架構,可以設計一個ontology來解釋這筆紫外線測站資料,而這個ontology 不單單只有紫外線測站的ontology,而應該是感測器知識本體(sesnor ontology),且可以應用在任何不同的感測器上,我習慣先用畫圖把需要的class和individuals先勾勒出來,以便後續ontology的編輯。

uv_ontology根據W3C SSN 和 DUL設計的紫外線感測器ontology

 
與寫程式類似,ontology的編輯可以用文字編輯器,但也有一些工具輔助,一般常用的工具為Protégé,根據上面那個畫好的圖,這個UV sesnor ontology 很快就能完成。
 

Linked Data: 讓自己可以被連結,也可以連結別人

一一解釋UV Sesnor Ontology中類型(class)和個體(individual)會是冗長的說明,為了有效率的說明UV Sesnor Ontology中的知識表達,以下是擷取部份段落來做解釋:
 

Solar501A (亂瞎掰的)感測器本身是用來測量紫外線(Ultraviolet)的,安裝於台北氣象站的系統平台上,且有量測紫外線指數(UV Index)的能力,而紫外線指數有15個等級,每一個等級就是100焦身/每平方公尺,例如8就是測到紫外線800-899焦身/每平方公尺。紫外線指數又可以分級為低量級、中量級、高量級、過量級、和危險級,下面案例只顯示紫外線指數8-10是過量級。

 

###  http://lod.tw/ontologies/weather-station/uv#Sensor_Solar501A

:Sensor_Solar501A rdf:type ssn:SensingDevice ,
                           owl:NamedIndividual ;

                  ssn:onPlatform :Platform_for_Taipei_Weather_Station ;

                  ssn:hasMeasurementCapability :UV_Index_MeasurementCapability .

###  http://lod.tw/ontologies/weather-station/uv#UV_Index_MeasurementCapability

:UV_Index_MeasurementCapability rdf:type ssn:MeasurementCapability ,
                                         owl:NamedIndividual ;

                                ssn:inCondition :UV_Sacle ;

                                ssn:forProperty :Ultraviolet .

###  http://lod.tw/ontologies/weather-station/uv#Ultraviolet

:Ultraviolet rdf:type ssn:Property ,
                      owl:NamedIndividual .

###  http://lod.tw/ontologies/weather-station/uv#UV_Sacle

:UV_Sacle rdf:type ssn:MeasurementRange ,
                   owl:NamedIndividual ;

          ssn:hasValue :UV_Index_0_interval ,
                       :UV_Index_10_interval ,
                       :UV_Index_11_interval ,
                       :UV_Index_12_interval ,
                       :UV_Index_13_interval ,
                       :UV_Index_14_interval ,
                       :UV_Index_15_interval ,
                       :UV_Index_1_interval ,
                       :UV_Index_2_interval ,
                       :UV_Index_3_interval ,
                       :UV_Index_4_interval ,
                       :UV_Index_5_interval ,
                       :UV_Index_6_interval ,
                       :UV_Index_7_interval ,
                       :UV_Index_8_interval ,
                       :UV_Index_9_interval .

###  http://lod.tw/ontologies/weather-station/uv#UV_Index_8_interval

:UV_Index_8_interval rdf:type DUL:Region ,
                              owl:NamedIndividual ;

                     :hasMeasurementPropertyMaxValue :UV_Index_8_max_value ;

                     :hasMeasurementPropertyMinValue :UV_Index_8_min_value .

###  http://lod.tw/ontologies/weather-station/uv#UV_Index_8_max_value

:UV_Index_8_max_value rdf:type DUL:Amount ,
                               owl:NamedIndividual ;

                      DUL:hasDataValue "8.99"^^xsd:float ;

                      DUL:isClassifiedBy :Hecto_joule_per_square_meter .

###  http://lod.tw/ontologies/weather-station/uv#UV_Index_8_min_value

:UV_Index_0_min_value rdf:type DUL:Amount ,
                               owl:NamedIndividual ;

                      DUL:hasDataValue "8.0"^^xsd:float ;

                      DUL:isClassifiedBy :Hecto_joule_per_square_meter .

###  http://lod.tw/ontologies/weather-station/uv#Very_High_Risk

:Very_High_Risk rdf:type ssn:FeatureOfInterest ,
                         owl:NamedIndividual ;

                rdfs:label "過量級"^^xsd:string ;

                ssn:hasValue :UV_Index_10_interval ,
                             :UV_Index_9_interval ,
                             :UV_Index_8_interval .

 

台北氣象站的系統平台是台北氣象站的一部份,台北氣象站是中央氣象局的一部份,而台北氣象站和中央氣象局都是一種組織(Organization)。

 

###  http://lod.tw/ontologies/weather-station/uv#Platform_for_Taipei__Weather_Station

:Platform_for_Taipei__Weather_Station rdf:type ssn:Platform ,
                                               owl:NamedIndividual ;

                                      ssn:attachedSystem :Sensor_Solar501A ;

                                      DUL:hasLocation :Site_Taipei_Weather_Station ;

                                      DUL:isPartOf :Taipei_Weather_Station .

###  http://lod.tw/ontologies/weather-station/uv#Taipei_Weather_Station

:Taipei_Weather_Station rdf:type :Weather_Station ,
                                 owl:NamedIndividual ;

                        rdfs:label "Taipei"^^xsd:string ,
                                   "台北"^^xsd:string ;

                        DUL:isPartOf :Central_Weather_Bureau_Taiwan ;

                        DUL:hasLocation :Site_Taipei_Weather_Station .

###  http://lod.tw/ontologies/weather-station/uv#Weather_Station

:Weather_Station rdf:type owl:Class ;

                 rdfs:subClassOf DUL:Organization .

###  http://lod.tw/ontologies/weather-station/uv#Central_Weather_Bureau_Taiwan

:Central_Weather_Bureau_Taiwan rdf:type :Government_Organization ,
                                        owl:NamedIndividual ;

                               rdfs:label "中央氣象局"^^xsd:string .

 

台北氣象站是在台北氣象站場址(site),這個場址是一個地方(Place),有一個WGS 84 XY座標的參考點(reference point),且這個場址有一個地址(Address),這場址也在一級行級行級區的台北市之中和二級行政區的大安區之中,且大安區也在台北市之中,而台北市在台灣之中。

 

###  http://lod.tw/ontologies/weather-station/uv#Site_Taipei_Weather_Station

:Site_Taipei_Weather_Station rdf:type DUL:Place ,
                                      owl:NamedIndividual ;

                             geo:hasGeometry :Reference_Point_Taiepi_Weather_Station ;

                             vcard:hasAddress :Address_Taipei_Weather_Station ;

                             :is_in :Daan_District ;

                             :is_in :Taipei_City .

###  http://lod.tw/ontologies/weather-station/uv#Reference_Point_Taiepi_Weather_Station

:Reference_Point_Taiepi_Weather_Station rdf:type geo:Point ,
                                                 owl:NamedIndividual ;

                                        wgs84_pos:long "121.55834"^^xsd:float ;

                                        wgs84_pos:lat "22.036934"^^xsd:float ;

                                        geo:asWKT "Point(121.5583420000, 22.0369330000)"^^sf:wktLiteral .

###  http://lod.tw/ontologies/weather-station/uv#Address_Taipei_Weather_Station

:Address_Taipei_Weather_Station rdf:type owl:NamedIndividual ,
                                         vcard:Address ;

                                vcard:street-address "公園路64號"^^xsd:string ;

                                vcard:locality "台北市"^^xsd:string ;

                                vcard:country-name "台灣"^^xsd:string ;

                                vcard:region "大安區"^^xsd:string .

###  http://lod.tw/ontologies/weather-station/uv#Daan_District

:Daan_District rdf:type lodtw:2nd_Administration ,
                        owl:NamedIndividual ;

               :is_in :Taipei_City ;

               owl:sameAs freebase:Daan District ,
                          geonames:Daan District .

###  http://lod.tw/ontologies/weather-station/uv#Taipei_City

:Taipei_City rdf:type lodtw:1st_Administration ,
                      owl:NamedIndividual ;

             :is_in :Taiwan ;

             owl:sameAs freebase:Taipei ,
                        geonames:Taipei ,
                        wikidata:Taipei ,
                        depedia:Taipei.

 
眼尖的你不難的不發現,上述的每一個「類型(Class)」和「個體(individuals)」都是以URL方式呈現,如http://lod.tw/ontologies/weather-station/uv#Taipei_City; 且上一段中的台北市和大安區都己經以owl:sameAs分別連結到DBPediaGeonamesWikidata、或Freebase,如UV sesnor ontology中的Taipei_City是以owl:sameAs連結http://rdf.freebase.com/ns/m.0ftkx, http://sws.geonames.org/7280290/, http://www.wikidata.org/entity/Q1867, 和http://dbpedia.org/resource/Taipei。與一開始所做的分析一樣,在這筆資料中地名是最有可能拿來連結其它資料的實體(entities)。

最後,想強調的是,編寫這個UV Sesnor ontology用意在於讓更多人了解什麼是LOD,並期待能引發更多LOD的討論,而能有更多更正確的LOD資料。