W3.org에서 다음과 같이 언급하고 있으므로, 해당 @id 필드는 작동하는 URL이어야 한다고 생각합니다.
그래프 내의 노드를 외부에서 참조할 수 있으려면 노드가 식별자를 가져야 합니다. IRI는 Linked Data의 근본적인 개념이며, 노드가 진정한 의미로 연결되려면 식별자를 참조해 해당 노드의 표현을 가져올 수 있어야 합니다. 이를 통해 애플리케이션이 노드에 대한 추가 정보를 검색할 수 있게 됩니다.
흥미롭네요. HTML 소스를 확인해야 한다는 생각은 못 하고 JSON-LD라고 단정 지었었네요.
Google은 스키마 데이터를 사용하지만, 해당 특정 데이터를 사용하는지는 잘 모르겠습니다. schema.org 문서가 매우 명확하게 작성되어 있지 않아서요.
Discourse가 각 주제에 여러 개의 DiscussionForumPosting을 넣는 것으로 보이는데, 문서의 예시를 보면 DiscussionForumPosting은 댓글이 아닌 주제 본문만을 지칭하도록 의도된 것 같습니다. 그런데 문서에는 comment 필드에 Comment(단수)가 나열되어 있으면서도 설명은 복수형으로 작성되어 있네요.
방금 Invison이 어떻게 처리하는지 살펴봤는데, JSON-LD를 사용하여 comment 필드에 Comment 객체를 넣고 있습니다. 브라우저에 전송하는 텍스트가 상당히 많은 것 같습니다.
이 포럼을 우연히 지켜보고 있었는데, 참 잘됐다. 그 HTML을 파싱하는 Google 코드의 소유자니까.
링크된 스레드는 그 댓글로 이어진 논쟁에 대한 좋은 답변이다. 나머지 부분은 여기서 다루겠다.
HTML의 id 속성을 노드 ID로 해석하는 것은 기본적으로 비표준이다. Google의 마이크로데이터 파싱 초기에 아마도 모호한 이유로 그렇게 했을 것이다. 그렇게 하려면 명시적으로 itemid를 사용해야 한다. 언젠가 그 해킹 방식을 제거하길 바라지만, 손실 없이 그런 것을 제거하는 것은 어렵다.
두 번째로, IRI는 반드시 참조 가능(dereferencable)할 필요는 없다. 그것은 W3C의 권장 사항일 뿐이며, 많은 IRI가 그렇지 않으며 Google도 그것을 절대 요구하지 않는다.
이것은 구조화된 데이터의 노드가 의도치 않게 병합되는 문제를 일으킬 때만 문제가 된다. 예를 들어 HTML의 다른 곳에서 동일한 값의 itemid를 사용한 경우와 같은 경우다. 그렇지 않으면 무시해도 되는 이상한 현상에 불과하다.
아, 그리고 JSON-LD로 전환하지 말아달라. 솔직히 포럼과 같이 텍스트가 많은 마크업에는 그것이 더 선호된다. 텍스트 내용을 중복해서 작성해야 하는 것은 어리석은 일이다. 작성하기가 더 쉬워서 우리가 그것을 추진해 온 것이다.