RDFa 실험

by Brian Kelly | 2010년 5월 3일 | HTML , W3C | 댓글 2개 배경 최근 게시물에서 마이크로포맷과 RDFa에 대한 몇 가지 생각을 정리했습니다: HTML 페이지에 더 풍부한 구조 추가하기 . 저는 이제 RDFa의 잠재력을 평가할 적절한 시점일 수 있다고 제안했지만, 마이크로포맷이 초기의 기대에 부응하지 못한 것으로 보인다는 점을 지적하며 신중론을 덧붙였습니다. 이러한 유보는 Owen Stephens도 공감했는데, 그는 TELSTAR 프로젝트의 일환으로 학생(및 교직원) 간 ‘참조’ 공유를 가능하게 하기 위해 (Bibo 온톨로지와 함께) RDFa를 사용하는 것을 고려했고, 이 결정의 배경이 된 이유들을 설명했습니다. Owen의 결정은 주로 배포 문제에 집중되어 있었습니다. 반면 Chris Gutteridge는 이념적 유보를 가지고 있었는데, 그는 “시각적 마크업과 데이터 마크업이 섞이는 것을 싫어한다. 논의되는 항목 옆 요소에 RDF 블록(가능하면 N3 형식)을 두거나 페이지에 그냥 두는 것이 더 낫다”고 했습니다. 저처럼 Stephen Downes도 조사할 의향이 있어 보였고 “이벤트를 설명하는 데 사용되는 RDFa 구문을 구체적으로 가리키는 링크”를 요청했습니다. Michael Hausenblas는 두 가지 유용한 자료에 대한 링크를 제공했습니다: W3C의 Linked Data Tutorial – RDFa로 연결된 데이터 게시 및 소비 에 관한 것과 “인간과 기계 모두를 위한 연결된 데이터 구축” ( PDF 형식 )에 관한 논문입니다. Pete Johnson도 유용한 의견을 주고 HTML 5 리소스에서 RDFa를 사용하는 방법에 관한 최근 발표된 작업에 대한 링크를 제공했습니다. 나의 실험 Stephen Downes처럼 저도 이벤트에 대한 더 풍부한 구조를 제공하는 것부터 시작하는 것이 유용하다고 생각했습니다. 따라서 제 실험은 다가오는 이벤트 페이지 에 RDFa 마크업을 추가하는 것으로 시작되었습니다. 브라우저 확장으로 처리하기 위해 이러한 풍부한 구조를 제공하는 것의 이점은 현재 설득력이 없어 보였기 때문에 제 초점은 검색 엔진이 이러한 마크업을 제공하는 것이었습니다. 따라서 동기는 주로 널리 사용되는 서비스에서 처리될 이벤트에 대한 더 풍부한 마크업을 제공하여 최종 사용자가 더 나은 검색 결과를 받을 수 있도록 하는 것입니다. 제 첫 번째 방문지는 리치 스니펫 을 소개한 Google 게시물이었습니다. Google은 2009년 5월, 1년이 채 되지 않은 시점에 리치 스니펫 지원을 시작했습니다. 이는 “웹 페이지에 포함된 구조화된 데이터를 강조하기 위해 Google의 알고리즘을 적용한 새로운 스니펫 표현”으로 설명됩니다. 리치 스니펫 사용에 대한 문서는 Google의 웹마스터 도구 웹사이트 에 제공됩니다. 이는 이벤트에 대한 RDFa(마이크로데이터 및 마이크로포맷과 함께) 마크업에 대한 정보를 제공합니다. 추가 페이지에서는 사람, 기업 및 조직 에 대한 마크업에 대해 유사한 정보를 제공합니다. Google이 리치 스니펫을 위해 자체 어휘를 개발했다는 비판을 받았다는 것을 알고 있지만, 가장 적절한 어휘에 대한 논쟁을 계속하기보다는 RDFa 사용에 대한 간단한 실험을 수행하는 데 더 관심이 있었습니다. 다가오는 이벤트 페이지는 저 자신(이름, 조직 및 조직 위치, University of Bath의 지리적 위치 포함)에 대한 RDFa 마크업을 포함하도록 업데이트되었습니다. 2010년 강연의 경우 이전에 사용했던 마이크로포맷을 강연 날짜와 위치(다시 지리적 위치 정보 포함)에 대한 정보를 제공하는 RDFa 마크업으로 대체했습니다. 페이지를 정상적으로 볼 때 눈에 띄는 변화는 없었습니다. 그러나 RDFa(및 마이크로포맷) 정보를 표시하는 FireFox 플러그인을 사용하면 소프트웨어가 HTML 페이지에서 더 풍부하게 구조화된 요소를 식별할 수 있음을 알 수 있습니다. 스크린샷은 Operator 사이드바와 RDFa Highlight 북마클릿에 의해 마크업이 렌더링된 방식과 화면 하단의 상태 표시줄에 RDFa 검증기 및 SIOC RDF 브라우저 에 대한 링크를 보여줍니다. 이 이미지를 Operator 플러그인에 의해 마이크로포맷이 렌더링되는 방식과 비교하면 마이크로포맷 표시는 이벤트 제목을 보여주는 반면 RDFa 표시는 RDFa 마크업을 포함하는 HTML 요소를 나열한다는 것을 알 수 있습니다. RDFa가 제공하는 더 큰 유연성은 마이크로포맷이 제공하는 더 제한된 사용에서 제공되는 컨텍스트의 손실이라는 대가를 치르는 것으로 보입니다. 유효한가? HTML RDFa Highlight 북마클릿이 RDFa 마크업이 사용 가능하고 마크업이 적용된 요소를 나타냈지만 HTML 페이지의 다른 측면도 수정해야 했습니다. DTD가 HTML 1.0 Strict에서 다음과 같이 변경되었습니다: 또한 RDFa 요소의 네임스페이스를 정의해야 했습니다: HTML에 정의된 요소를 포함하여 HTML 페이지에 접근할 수 있었기 때문에 이것이 가능했습니다. 일부 CMS 애플리케이션은 이러한 변경을 허용하지 않을 수 있으며, 또한 조직에 이러한 변경을 금지하는 정책이 있을 수 있다는 것을 알고 있습니다. 그러나 이후 페이지를 검증하면서 HTML 유효성 오류를 발견했습니다. 제가 name=“foo” 속성을 사용한 것이 id=“foo” 로 대체된 것 같습니다. 그러나 DTD와 요소에 대한 변경 및 RDFa 마크업 포함이 제가 해야 했던 유일한 변경은 아니었습니다. id=“foo 속성은 “foo”가 알파벳 문자로 시작해야 한다는 것을 발견했습니다. 따라서 id=“2010”을 id=“year-2010” 으로 변경해야 했습니다. 이것은 저에게 다소 더 걱정스러운 일이었는데, 하위 호환되는 새 마크업이나 약간 수정된 마크업을 포함하는 것이 아니라 내부 앵커의 URL을 변경해야 했기 때문입니다. 앵커가 알파벳 문자로 시작했다면 문제가 되지 않았을 것이고(그리고 저는 문제를 인지하지 못했을 것입니다). 그러나 문서 중심의 XHTML 1.0 Strict 준수 세계에서 더 데이터 중심의 XHTML 1.1+RDFa 세계로 마이그레이션하면 링크가 깨질 수 있는 것으로 보입니다. 저는 다가오는 및 최근 이벤트 페이지에서 이 변경을 하고 페이지 내 링크를 변경할 준비가 되어 있었습니다. 그러나 다른 사람들이 이러한 내부 앵커에 링크하는 경우(가능성이 낮다고 생각하지만) 링크가 약간 저하될 것입니다(404 오류 메시지가 표시되지 않고 특정 연도의 시작 항목 대신 페이지 상단이 표시됨). Google의 RDFa 마크업 보기 Google의 리치 스니펫 테스트 도구를 사용하면 “웹 페이지 URL을 입력하여 검색 결과에 어떻게 나타날 수 있는지 확인”할 수 있습니다. 첨부된 이미지는 제 이벤트 페이지 에 대한 이 도구의 출력을 보여줍니다. 이는 Google이 알고 있는 페이지 구조를 보여줍니다. Google이 강연 위치의 위도와 경도를 알고 있으므로 위치 기반 서비스에 사용할 수 있으며 이벤트 요약과 설명을 제공할 수 있습니다. 올바른가? 초기 실험 후 제 전 동료 Pete Johnston(현재 Eduserv 소속)이 친절하게 피드백을 주었습니다. 그는 W3C의 RDFa Distiller and Parser 서비스를 알려주었고 최근에 DC-HTML을 사용한 문서 메타데이터 와 RDFa 사용 및 W3C에서 제공하는 RDFa 1.1 초안 에 대한 게시물을 직접 발표했습니다. Distiller and Parser 서비스를 사용하여 제 이벤트 페이지(현재

P.S. A few readers have asked which shared & managed wordpress hosting we actually reach for — it's SiteGround; take a look here if you want the current details.