Семантическая разметка HTML5 для тегов и категорий постов блога

Многие блоги используют концепцию «тегов» и «категорий» для добавления метаданных к сообщению. Какова наилучшая практика семантической разметки для этой информации, чтобы машина, читающая сообщение в блоге, могла легко идентифицировать теги?

В настоящее время я добавляю "tag" к атрибуту rel ссылки, например.

<a rel="tag" class="tag" href="/tags.html#site-configuration">#site-configuration</a>

Я полагаю, что можно использовать html-формат Dublin Core для ключевого слова:

<meta name = "DC.Subject"
          content = "site-configuration">

и добавить это в шапку страницы, или метатеги могут быть в теле? Что предпочтительнее, тот или другой вариант или какой-то совершенно другой вариант?

Есть ли лучшая стратегия с точки зрения предоставления точных и стандартизированных определений контента?

Является ли HTML5 разумным выбором, если я хочу быть таким придирчивым к метаданным, или мне следует использовать тип документа XML?

Каковы плюсы и минусы различных подходов?


person cboettig    schedule 12.10.2012    source источник
comment
<meta name="keyword" content="site-configuration"> может быть предпочтительнее, поскольку я не думаю, что DC.Subject является допустимым html5. Не уверен, какие атрибуты будут правильными для категорий (т.е. в стандарте html5 нет атрибута rel="category" (?))   -  person cboettig    schedule 13.10.2012
comment
XHTML5 будет полезен при использовании grddl или xslt, как это часто бывает с семантически богатым содержимым.   -  person Chawathe Vipul S    schedule 18.01.2013


Ответы (1)


Первый шаг заключается в том, чтобы получить/использовать простой HTML семантически правильно. В случае (X)HTML5 вы должны построить соответствующую схему, используя элементы содержимого секций section, article, aside и nav, и использовать header и footer для отделения содержимого метаданных от основного содержимого; также подумайте о семантике встроенного уровня, такой как time (дата публикации), dfn (определения), abbr (аббревиатуры/акронимы) и т. д. И используйте значения meta-name и rel, которые определены в спецификации.

Вторым шагом будет использование значений атрибутов метаданных, которые не определены в спецификации, но зарегистрированы в определенных местах (чтобы их можно было использовать), например name ключевые слова для meta элементов и rel значения для a/area/ link элементов.

Третий шаг — улучшить разметку семантическими машиночитаемыми аннотациями. Существует три распространенных способа сделать это:

  • Микроформаты (с использованием предопределенных значений class и rel)
  • RDFa (с использованием атрибутов и URI)
  • Микроданные (с использованием атрибутов и URI)

RDFa и микроданные похожи (и расширяемы, и довольно сложны), тогда как микроформаты проще (но не такие выразительные/расширяемые). Я написал краткий ответ программистам о различиях и более подробный ответ о различия между микроданными и RDFa.

В случае с RDFa или микроданными вашей основной задачей будет поиск словарей/онтологий, способных описать/классифицировать ваш контент. Такие словари могут быть созданы кем угодно (вы даже можете создать их самостоятельно), но часто рекомендуется использовать известные/популярные словари, например, чтобы поисковые системы могли использовать ваши аннотации (популярный пример: Schema.org).

В случае с микроформатами вам нужно найти микроформат (на вики на microformats.org) который соответствует вашим потребностям. Если для вашего случая его нет, вы можете предложить новый микроформат (но это займет некоторое время, пока он не будет «принят», если вообще будет).


Является ли HTML5 разумным выбором, если я хочу быть таким придирчивым к метаданным, или мне следует использовать тип документа XML?

Вы также можете использовать XHTML5, если вам нужна поддержка XML. Если вы используете "только" (X)HTML, определенный в спецификации, и не используете дополнительные схемы/словари XML, с семантической точки зрения не будет иметь значения, используете ли вы HTML(5) или XHTML(5).

person unor    schedule 13.10.2012
comment
Отличный ответ, спасибо. Похоже, что использование стандартного атрибута класса в теге html (например, ссылки) является примером микроформата. Верно ли это и при использовании атрибута rel? Вики, на которую вы ссылаетесь, определяет rel="tag" и rel="category" в качестве микроформатов. Считаются ли теги HTML5, такие как ‹header› и ‹footer›, микроформатами? Кажется, что они имеют гораздо более строго типизированное значение, чем что-то вроде `‹p class=vcard›, даже несмотря на отсутствие явного пространства имен. - person cboettig; 15.10.2012
comment
В частности, есть ли какое-либо преимущество между определением ключевого слова с использованием стандарта HTML5 <meta name="keyword" content="my-keyword"> по сравнению с Dublin Core <meta name="DC.Subject" content="my-keyword"> по сравнению с тем, как это можно сказать в RDFa? - person cboettig; 15.10.2012
comment
@cboettig: Да, некоторые микроформаты также используют значения rel (я добавил это в свой ответ). Обратите внимание, что он называется микроформатом только в том случае, если он указан в вики на microformats.org. Таким образом, все значения class/rel, определенные в других местах, не являются микроформатами. Также обратите внимание, что значение rel tag определено в HTML5 и также в микроформатах — и определения немного отличаются. Элементы HTML (например, footer) никогда не могут быть микроформатами. microformats определяет способ классификации содержимого элементов HTML с помощью этих предопределенных значений для атрибутов class/rel. Это всего лишь соглашение. - person unor; 15.10.2012
comment
@cboettig: определения keywords (в спецификации HTML5) и dcterms.subject (в вики WHATWG или Dublin Core) могут отличаться. Вы должны внимательно прочитать, как они определяются. Конечно, возможно, что они одинаковые. Также обратите внимание, что агенты, такие как поисковые системы, боты, программное обеспечение и т. д., могут знать только один из возможных эквивалентных способов (например, синтаксический анализатор Dublin Core может искать только dcterms.subject, но не keywords и т. д.). - person unor; 15.10.2012