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

政府開放資料的推動通常遇到一個問題是,業務主管機關不知道什麼資料應該開放,而資料的使用者則不知道有什麼資料可以被開放,而由再使用資料產生出價值或商業模式,歐盟所做這篇報告「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資料。

利用Facebook的加速科學研究:群眾外包式魚類辨識

這是一個利用Facebook促進科學研究加快的故事。簡單地說,研究人員因為採集大量的魚類照片,自已辨識的話,得花費不少時間,因此計畫主持人的學生提議將照片放上Facebook將他們的朋友們來幫他們辨識這些照片,當然他們的朋友多數也是魚類或生物得家,而照片放上Facebook的24小時後,就有90﹪的照片已經被辨識,這個成功的故事就這樣登上了Science期刊!

Facebook的頁面

http://www.facebook.com/media/set/?set=a.1713096701121.243121.1049262482&l=e485413c15

Video:

http://shelby.tv/video/youtube/8hhXZwLFfao/facebook-stories-speeding-up-science

文章原稿:
Science. 2011 Apr 29;332(6029):537.
Life in science. Ichthyologists hooked on Facebook.
Sidlauskas B, Bernard C, Bloom D, Bronaugh W, Clementson M, Vari RP.

Ichthyologists Hooked on Facebook

The Cuyuni River, which runs from Venezuela through Guyana and into the Atlantic via the Essequibo River, harbors hundreds of fish species. Although much of the river flows far from civilization, pollution from gold mining and other environmental hazards threaten its rich community of wildlife. Earlier this year, a small group of us from the United States and Guyana set out to perform the first comprehensive survey of the river’s fishes with support from the Biological Diversity of the Guiana Shield program at the Smithsonian’s National Museum of Natural History. We aimed to determine which species still thrived in the river, which might have disappeared, and whether any of the remote river’s denizens were entirely new to science.
We arrived in January, during the dry season, and embarked for two weeks of collecting and camping along 200 km of rainforest-lined river.

Local boatmen helped us navigate the often perilous river, and each day, we stood neck-deep in the muddy waters and pulled wide nets to catch samples of the life teeming beneath the surface. One student, Whit Bronaugh, photographed each species as the collection grew to hundreds, and then thousands, of fishes large and small.

Upon returning to Georgetown (Guyana’s capital), a major challenge confronted us. As a condition to securing an export permit, we had just one week to complete a detailed report with each of our 5000 specimens identified to genus and species. Given the limited library resources at our disposal and the time constraint, the task seemed impossible.

Then one of the students, Devin Bloom, suggested posting our many photographs on Facebook and inviting the ichthyologists among our circle of friends to help us identify them. Would that far-flung community take the time to help us? We decided to find out.
We posted the photographs (1), and within minutes comments began to pour in. “They look like fish to me” one commenter cheerfully acknowledged. On an anchovy, another noted, “Pizza topping.” But before long, more insightful messages began to appear. On a catfish: “would say Megalechis personata,” followed by another suggestion, “my guess would be Megalechis horacatum.” Amazed, we collected identifications from our friends, and then from friends of friends, contributing their expertise from around the world. Less than 24 hours later, 90% of our specimens were identified. Armed with our export permit, we packed
our specimens for shipment and returned home, grateful beyond words for the generosity of our colleagues, and for the social network that allowed us to harness their vast collective expertise and provide faster and more accurate identifications than we ever would have dreamed possible.

首次台灣開放街圖研討會(SotM Taiwan 2012)的記事

開放街圖 (OpenStreetMap) 計畫已經在台灣進行多年,隨著開放街圖在全球知名度大開,台灣的製圖參與者 (mappers) 與日增多,台灣開放街圖雖然沒有政府部門開放資料與製圖相關的商業團體支持,在 mappers 一步一腳印地繪製,台灣地區資料量也日漸豐富,但相對於鄰近日本,以及歐美各國,台灣開放街圖仍然不足,亟需更多 mappers 的加入。台灣 OSM 社群目前缺乏系統性互動討論,以及更深入地對於技術發展、應用推動、和交流的平台,因此極有必要舉辦台灣 OSM 研討會,讓以社群為主的地圖成為各界共同討論的目標,達到概念性與技術性的交流。

此次報名人數超乎預的踴躍,截止前已超過100人,因為場地的限制,過多的人我們無法容納,但讓我感到揪感心的是報到率出奇之高,當天來了80位左右的朋友,做為首次舉辦的研討會,尤其OSM Taiwan的社群又相對於其它社群規模小,能有這樣的數量已經感到十分滿足,謝謝大家的支持!

當日議程和投影片都放在SotM Taiwan 2012活動網頁,本次研討會榮幸地邀請中研院資訊所副研究員莊庭瑞博士,就「大眾協作與個人記憶」為主題,講述群眾外包的地圖特性與合作協同過程中如同透過地圖編輯保存共同的地方記憶,當天上午並有6個演講,涉及層面廣,從Open Data、防災、歷史地圖、教育到授權,下午則是台灣 OSM Mappers較為實務性的分享。所有的演講都有錄影,並置於YouTube,感謝OSSF同仁錄影並整理上傳。

當天本人統計分析一下台灣Mappers的製圖特性,做為開場,投影片在SlideShare:

我們這種小地區的SotM,ito world並不會幫我們做過去一年的製圖概況,因此自已親手做了一個利用CartoDB+Torque的版本:

http://geocyber.org/maps/osm/sotm2012/taiwan_osm_2012.html

SotM Taiwan 2012的活動照片:
[fsg_gallery id=”1″]