對於鏈結資料(Linked Data)實作的調查

美國國際圖書館電腦中心(OCLC, Online Computer Library Center)在2014-15年間對全球的圖書館和博物館進行問卷調查,想了解全球的圖書館和博物館界在鏈結資料(Linked Data)的執行狀況,這個調查收集了20個國家90個機構的回應,問卷的原始資料在此,根據這個問卷資料,Karen Smith-Yoshimura 在2016年於D-Lib上發表了一篇文章,以下的內容是轉譯這篇文章。

以機構的類別而言,調查對象是以圖書館為主,博物館比例較低。

機構進行鏈結資料工作有多久?

在這90個機構中,有些已經進行鏈結資料的工作超過二年,但也有為數不少的機構其實還沒有開始鏈結資料的工作。

 

 

 

如何使用鏈結資料?以鏈結資料的使用而言,多數的單位鏈結資料的使用者,而相對地,發佈者比例則較低。

 

那發佈鏈結資料的單位,因為調查對象是以圖書館為主,他們所發佈出來的資料類型,是以書目資料、描述的詮釋資料、權威檔、知識本體/語彙為主。

 

 

雖然許多機構的鏈結資料的計畫都是在剛起步的階段,能夠說出鏈結資料工作的成功之機構是相對低的,整理了46個機構的回饋,導出幾個成功的鏈結資料工作之指標:

  • 資料重複使用 (Data re-use).
  • 增加被搜尋 (Increased discoverability)
  • 新知識的建立 (New knowledge creation)
  • 思想的領先者 (Thought leadership)
  • 對於語意網的準備 (Preparation for the semantic Web)
  • 操作的順利進行 (Operational success)
  • 促進機構的發展 (Organizational development)
  • 促進機構的轉型 (Organizational transformation)

其文章也列出其他原因,包含:

  • 在未來的計劃需要發佈鏈結資料來利用及重複使用。
  • 最大化資料的互操作性和重複使用性。
  • 測試 BIBFRAME 和 schema.org。
  • 計畫需求。
  • 提供穩定、整合、正規化資料在跨機構的研究活動。

被提到發佈鏈結資料的障礙依序為:

  1. 學習曲線對員工太高
  2. 和舊有的資料不一致
  3. 選擇合適的知識本體來呈現資料
  4. 建立連結
  5. 在如何建立系統有輕量文件或建議
  6. 工具的缺乏
  7. 不成熟的軟體
  8. 弄清楚資料是誰的

 

 

 

最後,文章整理了受訪者給要進行鏈結資料計畫的單位一些建議:

  • 聚焦於你所要完成的目標,而不是技術的東西
    • 模型化你所要解決之案例的資料
    • 往長期的資料一致和統合 (data reconciliation and consolidation) 之方向去努力
  • 增加獨特的價值: 建立在你有但別人沒有
    • 挑出你可以解決的問題
    • 帶入你所處的機構/社群來思考
  • 對於鏈結資料結構、可取得的知識本體和你的資料能有好的理解
    • 消化你所發佈的資料
    • 一開始就考慮法律授權問題
    • 盡量廣泛地參考相關資料且諮詢專家
  • 現在開始! 就去做吧!

連結感測器資料(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資料。

鏈結資料 (Linked data)、開放資料(Open Data)和鍵結開放資料(Linked Open Data): 從學術到產業行與不行?

昨天應「高人」之邀,參與了台北市電腦公會舉辦的第三場 Open Data產業新契機系列論壇,會中的提問,好像講了太多我們過去的做LOD的經驗,但我提出問題的可能不是很精確,所以台上沒有任何回應,會後也沒有進一步的討論,只有台北市議會的人,是周柏雅議員的助理嗎? 說如果台北市的資料有這樣的問題我們可以幫你,感恩啦! 因為說的不好,所以在自己的部落格上解釋一下。我的發言應該是這樣的

本人在LOD上有實作,有一些經驗可以分享。研考會陳怡君科長說得好,政府資料中有74%是與地理資料有關,地理資料的開放與LOD的發展有很大的關係,今天就以地名而言,是一個很好的鍵結資料,如大家知道「野柳」過去被西班牙人稱為Diablo,這就是同一地點在不同時間上的對於地方稱呼的鍵結,也是台灣與西班牙的鍵結,地名資料目前是沒有公開授權的資料庫,中研院生物多樣性中心和農委會林試所,已經就利用他們所建立的4 5個資料庫中的資料透過開放授權,將資料釋出後,再以LOD技術與全球資料庫GBIF鍵結,並上傳到datahub.io被審核後成為LOD cloud的一雲,而我以內政部地名資料為主,做了另一個LOD的資料集已經與全球最大的地名資料庫Geonames.org 連結,並沒辦法完全上傳至datahub.io,原因是台灣地名資料庫沒有公開授權,若我上傳即有法律上責任,目前只能以學術研究方式提供參考。

(發言的內容有做過一些修飾,但大意沒變。哈哈哈,當天下午已經是疲憊不堪,在沒有充足的提精飲料下,實在無法完整的想起來我說了什麼。TCA的人在我發言完後,拿了一張紙來叫我把我的發言寫下來,幹嘛!這是小學生考試嗎?TCA的大哥大姊別欺負我,請看上面不精確的回憶)

我的問題要表達一件重要的事情,資料沒有公開授權怎麼有辦法做LOD,若要說也只是Linked Data不是Linked Open Data,我長年關心的是地理資料開放授權議題,都到現在這個節骨眼上了,總不能還叫廠商花錢買? 但在場的人似乎不是很在乎這件事。

接下來,對於LOD在產業上的發展,有些觀察,因個人研究興趣,對於語意網和鍵結資料有一些經驗,但三年多來對於鍵結資料的研究,多是都在學習歐美國家發展的狀態,本身並沒有研發出了不起的理論或軟體,相信一定有人比我還專業,能夠說得上的,獻醜了,就是去年在一個日本舉辦的國際會議上,就如何利用LOD資源來做強化非結構性資料,讓使用者在Facebook上貢獻資料中的能夠與現存的LOD資料相連,發表了一篇文章,論文集會由LNCS出版,有興趣可以看看投影片內容

然而這一趟去了日本,學習不少,讓我驚豔的地方是日本對於Open Data的推動方式。學術團體、地方政府和民間業者共同推動Linked Open Data (LOD) Challenge,使得產官學能夠以Open Data的需求與供應面上,就資料集(Data set)、想法(idea)、應用程式(Application)、視覺化(Visualization) 等四個面向來做競賽,個人對於這個活動做了一個簡單的介紹,而觀察了幾個月下來發現,這樣子的競賽活動快速帶動政府、產業和學術的相互交流,強調的是Open Data資料真正落實資料應用的發展、從個人收集女性流行服飾資料並做成APP,到利用政府公開資料來發展生態或深度旅遊應用程式,對於Open Data的應用上,就廣度和深度都有一定的水準。

學術上的研究本來就應該落實到產業,但學術研究的人並不一定能夠了解產業的需求,藉由一次次名為“Challenge”活動,實際上是一種「溝通與對話」,可以逐步地媒合資料供給、技術研發和產業發展,TCA舉辦一系列論壇的目的和日本LOD Challenge相同嗎?老實說,在昨天的論壇中,我沒有看到LOD真正能夠落實到產業是什麼?先不論技術層面的問題,資料連不連的起來的問題,就「原住民族文化觀光資料開放」中的幾個Use cases,看起來就只是在消費原住民的文化,是以治理(或統治)者的角色在思考產業,但這或許是原罪,現存資料庫中的資料本來就是以治理者角度在建立資料,而不是保存文化的角度,舉一個簡單的例子,傳統領域可能與觀光不是那麼密切,但傳統原住民的地名,用他們自己語言來謂呼的地方的名字,是一個重要的文化資產,各位到蘭嶼,下飛機後,看到的地圖是漢語不是達悟族語,那他們為什麼不能用達悟族語來表達他們的地名?同樣的,玉山、雪山和許多高山可能都有布農族或泰雅族地名,為什麼沒有一個漢語和原住民語,雙語併行的地圖? 若原民會手上有原住民傳統地名,拿來和內政部地名Link一下,往後觀光業者就這個資料開發,就可以有雙語,可以行銷在地,又可以教育民眾在地知識,保存原民文化,(長官~,我希望看到的這樣的案例)。廣告一下,事實上,有一群長期關心原民文化的朋友(而且還有外國人參與,汗顏!外國人比我們還關心原住民),長期在花東一帶做原住民語輸入法,也逐步地將原住民語地名建入OpenStreetMap。

LOD的發展是技術面很吃重的工作,若要以推廣LOD進入產業,工具的研發或在化地是很重要的一環。目前在歐洲多是以歐盟層級的大型計畫,如FP7中的LOD2來做研發,並釋放許多的Open Source工具,使後續可以就他們的經驗和基礎再研發。但有許多工具,不一定適合於台灣的資料,最簡單,我們使用的是中文,和別人語系不同,在處理語意,和資料鏈結也會不同,(腦海中竟然出現肝藥廣告詞:成份不同、效果也不同),工研院扮演的角色是針對原民會的這個計畫研發工具,並釋放給業界使用? 昨天的簡報和問答,實在沒有辦法了解到這點。

LOD是達到開放資料五顆星等級的方法,是世界潮流與趨勢,很高興,政府單位開始想做著手做這部份,舉雙手贊同。但昨天聽起來,心中疑惑更多,這樣的討論充其量的只是一個Linked Data的論壇,而不是Linked Open Data的論壇,這麼多被提到資料,有多少是開放授權呢? 再者,談LOD進入產業是否太早,工具研發和人才培育是關鍵,我很懷疑目前台灣有多少技術人才可以進行LOD的工作,產業若要接手有多少工具可以使用?多少人才可以運用? 如果這二個基礎都沒有,LOD產業可能只是另一個空談。

 

 

語意技術聯合國際研討會 (Joint International Semantic Technology Conference, JIST 2012)

JIST2012是第二屆,上一屆在中國杭州,如果沒有搞錯這個研討會的前身應該是ASWC (Asian Semantic Web Conference)。

JIST2012

雖然這是亞洲區語意網會議,但參加的人不僅來自於亞洲國家,除了日本、韓國、中國、泰國、越南、印度、伊朗、台灣,許多人是來自於歐洲,如德國、英國、愛爾蘭、瑞典、芬蘭、義大利、盧森堡,少數來自於美洲,如美國和加拿大,來參與的人不乏是語意網領域有名的單位組織,如愛爾蘭的DERI (Digital Enterprise Research Institute)、美國的Kno.e.sis Center in Wright State University、德國的 University of Leipzig、日本的NII (National Institute of Informatics)、韓國的KISTI、中國上海交通大學、清華大學,參加人數約100人左右。

會議內容雖有少數偏於理論, 但多數論文偏於語義網和資料連結的實務性研究,4個邀請演講也偏向於應用面,以業界的實務應用,詳細內容可參考議程 。與會的人多為語意網或連結資料方面專家,尤其能在亞洲地區的會議遇到這麼多來自歐美地區且是語意網的專家,三天的會議下來,彼此互動切蹉,獲益良多,有些沒想過研究主題,衝擊腦袋,產生不一樣且具體的想法 。

我們的論文有幸被接受並口頭發表。此行 另一個收獲是能夠了解日本在Open Data和LOD的推動和做法,在JIST 2012 大會的前一天LOD Challenge社群舉辦的International Asian LOD Challenge Day,雖然來不及參與這一天的活動,但後來有機會與LOD Challenge社群接觸,並了解一些日本在推動Open Data和Linked Open Data 的做法和推動方式,這一些觀察整理成 LOD Challenges

相較而言,JIST的等級當然比不上ISWC和ESWC,但被接受的文章仍然有一定的水準,但接受率略高,約在36-37%左右。詳細的接受率為:

  • Regular papers 22/58
  • In-Use track papers 7/17
  • Special track papers 6/15
  • Linked Data in Pratice 4/11
  • Database Integration 2/4