Разъяснение Schema.org для представления JSON-LD и URI

Я пытаюсь закодировать в JSON-LD семантическую информацию, связанную с веб-сайтом, с помощью Schema.org. Веб-сайт очень простой: он содержит домашнюю страницу, страницу галереи со списком изображений и страницу с подробными сведениями об изображениях.

Читая различные примеры с веб-сайта Schema.org, а также просматривая раздел «Начало работы», не так просто понять, какая информация должна быть представлена ​​на каждой странице.

Чтобы прояснить вопрос, я могу предоставить фрагмент кода, который я пытаюсь создать, выведя необходимую информацию после прочтения документации Schema.org.

Ниже список конкретных вопросов:

  • Нужно ли повторять информацию, представленную на домашней странице, на всех других страницах? В этом случае, как должна быть закодирована дополнительная информация (как указать, что страница является ImageGallery или ImageObject)?
  • Как сопоставить (на странице сведений об изображении) изображение с URI, чтобы семантически связать объект на изображении с объектом реального мира (например, используя dbpedia.org/resource/URI)?

Пример

ГЛАВНАЯ СТРАНИЦА

{ "@context":"http://schema.org",

   "@type":"WebSite",
   "name":"Site name abc",
   "alternateName":"ABC",
   "description":"description",
   "keywords":"keywords",
   "inLanguage":"en",
   "url":"http://www.thewebsiteurl.com",
   "potentialAction":{
     "@type":"SearchAction",
     "target":"http://www.thewebsiteurl.com/find/{search_term_string}",
     "query-input":"required name=search_term_string"
   }
}

ГАЛЕРЕЯ СТРАНИЦА

{  "@context":"http://schema.org",
   "@type":"ImageGallery",
   "description":"description",
   "keywords":"keywords",
   "associatedMedia":[
   {
       "@type":"ImageObject",
       "contentUrl": "http://...../image1URL.jpg",
   },
   {
           "@type":"ImageObject",
       "contentUrl": "http://...../image2URL.jpg",    
   },
   .....
   ]
}

ДЕТАЛЬНАЯ СТРАНИЦА ИЗОБРАЖЕНИЯ

{
  "@context": "http://schema.org",
  "@type": "ImageObject",
  "author":{
    "@type": "Person",
    "name":"abc"
  },
  "contentLocation":{ 
      "@type": "Place",
      "geo": {
        "@type": "GeoCoordinates",
        "latitude": "[latitude]",
        "longitude": "[longitude]"
      },
      "name": "Place name"
  },
  "copyrightHolder":{
      "@type": "Organization",
      "email": "[email protected]",
      "url" : "http://www.thewebsiteurl.com"
  },
  "contentUrl": "http://...../image1URL.jpg",
  "datePublished": "[date]",
  "description": "description",
  "keywords":"keywords",
  "name": "Image name",
  "exifData":[
  {
    "@type": "PropertyValue",
    "name": "Exposure Time",
    "value": "1/10 sec."
  },
  .....
  ]   
}

person user9370976    schedule 21.03.2016    source источник


Ответы (1)


Нужно ли повторять информацию, представленную на домашней странице, на всех других страницах?

Используя синтаксисы Microdata и RDFa, вы обычно размечаете то, что доступно на странице. Хотя синтаксис JSON-LD отличается от них (поскольку он не разметка, т. Е. Отделен от существующей разметки), нет причин обрабатывать его иначе.

Если у вас есть контент об определенном изображении на домашней странице, странице галереи и странице сведений, вы можете (и, на мой взгляд, должны) предоставить структурированные данные об этом на каждой из этих страниц.

Одна из причин этого в том, что потребители не обязательно анализируют ваш сайт целиком:

  • Потребитель может найти одну страницу, поискать структурированные данные и снова уйти, не ища другую страницу вашего веб-сайта.
  • Потребитель может найти одну страницу, поискать структурированные данные, заинтересоваться дополнительными данными и перейти по ссылкам, указанным в ваших структурированных данных (например, URI, заданным как значения свойств).

Поэтому в идеале предоставляйте структурированные данные (или ссылочные структурированные данные, которые представлены в другом месте на вашем сайте) везде, где это необходимо.

В этом случае, как должна быть закодирована дополнительная информация (как указать, что страница является ImageGallery или ImageObject)?

Может иметь смысл различать тип документа (в случае веб-страницы, WebPage или один из подтипы) и тип (ы) для вещей, описанных в этом документе.

Итак, ImageGallery (который является подтипом WebPage) представляет страницу, а _ 6_ представляет изображение, которое может быть частью этой страницы.

Если возможно (но часто это не так), вы должны предоставить свойства, которые связывают все предоставленные узлы. Например, с hasPart / isPartOf, mainEntity / _ 10_ или, конечно, такие свойства, как author и т. д.

Как сопоставить (на странице сведений об изображении) изображение с URI, чтобы семантически связать объект на изображении с объектом реального мира (например, используя dbpedia.org/resource/URI)?

Для этой цели можно использовать свойство sameAs Schema.org. Но вы, конечно, также можете использовать свойства из других словарей, например owl:sameAs.

person unor    schedule 21.03.2016
comment
Спасибо за ваш ответ. Итак, в основном я могу использовать следующие типы: WebPage для домашней страницы, ImageGallery для страницы, содержащей список изображений, и ImageObject для страницы, содержащей детали для конкретного изображения? - Что касается семантической ссылки на внешний ресурс, например DBpedia: sameAs может быть вариантом. А как насчет свойства mainEntityOfPage? - person user9370976; 22.03.2016
comment
@ user3535189: Если вы хотите указать тип для страницы и тип для сущностей контента: вы можете использовать ItemPage для изображения страницу сведений и ImageObject для изображения и используйте _3 _ / _ 4_, чтобы связать эти два объекта. То же самое с галереей: ImageGallery для страницы и несколько ImageObject (или, например, ItemList с несколькими ImageObject) для фактического содержания. - person unor; 22.03.2016