Широкомасштабная интеграция данных: Cвязанные данные

Применение принципов связывания крупных, независимых наборов данных в Интернете

Технологии связанных данных эффективно объединяют множество наборов данных в один. Теперь, когда вам известна модель данных Resource Description Framework (RDF), а также протокол SPARQL и язык запросов RDF (SPARQL), мы рассмотрим, как объединить эти стандарты с веб-архитектурой для создания и использования легко потребляемых взаимосвязанных данных.

Брайан Слеттен, инженер-программист, IBM

Фото автораБрайан Слеттен (Brian Sletten) – инженер-программист с гуманитарным образованием, специализирующийся на передовых технологиях. Его опыт охватывает многие отрасли, включая розничную торговлю, банковское дело, онлайн-игры, оборонную промышленность, финансовую сферу, гостиничный бизнес и здравоохранение. Он получил степень бакалавра информатики в Колледже Уильяма и Мэри и живет в Оберне (штат Калифорния, США). В сферу его интересов входят архитектура Интернета, ресурсно-ориентированные вычисления, социальные сети, Semantic Web, обработка научных данных, 3D-графика, визуализация, масштабируемые системы, консалтинг в области безопасности и другие технологии конца ХХ и начала ХХI века.



07.08.2016

В первых двух статьях этой серии (Создание паутины данных с помощью RDF и Обращение к данным RDF с помощью SPARQL) мы рассказали о Resource Description Framework (RDF) и SPARQL Protocol and RDF Query Language (SPARQL) – двух стандартах World Wide Web Consortium (W3C), нацеленных на создание портативных, доступных сетевых структур данных. Модель графа RDF облегчает накопление информации на определенную тему из различных источников. Теперь вы знаете, как получать данные RDF через HTTP при локальных запросах или передавать запросы стандартизованному серверу во избежание передачи ненужных данных. В этой статье из серии Широкомасштабная интеграция данных мы рассмотрим, как RDF и SPARQL сочетаются с веб-архитектурой для создания и использования связанных данных.

Принципы связанных данных

Призывая к согласованности способов публикации данных в Интернете, Тим Бернерс-Ли определил четыре принципа связанных данных:

  1. Использование в качестве имен универсальных идентификаторов ресурсов (URI).
  2. Использование URI в формате HTTP, чтобы эти имена можно было искать.
  3. Предоставление тем, кто ищет URI, полезной информации с использованием стандартов (RDF*, SPARQL).
  4. Включение ссылок на другие URI, чтобы можно было находить больше вещей.

Об этой серии статей

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

На данном этапе этой серии публикаций мотивация этих принципов не требует объяснений, но для ясности я все же кратко ее изложу.

Во-первых, цель системы именования – делать ссылки в общедоступном контексте. Эти ссылки должны быть согласованными, недвусмысленными и бесконфликтными. Стандарт URI дает такую схему именования: схему создания систем имен. Зная, как анализировать, представлять и хранить URI в своей системе, можно принимать идентификаторы из любых других систем, если они созданы с соблюдением стандарта. Такие системы могут включать уже написанный и развернутый код, который принимает ссылки на будущие, новые стандартизованные имена URI.

Имена URN

Использование URI не означает, что для Semantic Web номера ISBN бесполезны. Uniform Resource Name (URN) — это тип URI, который позволяет отображать внешнюю схему имен на пространство URI с помощью префикса пространства имен. У книги может быть следующий URN: urn:isbn:978-1608454303.

Существуют и другие глобальные системы имен. Общепринятая схема – это Международный стандартный номер книги (ISBN). Номера ISBN долгие годы играли решающую роль для стандартизации ссылок на книги. Успех этой схемы объясняется главным образом тем, что поддержка системы имен позволила сократить расходы и количество ошибок для рынков издания и распространения книг. К сожалению, ISBN относится только к книгам. У журналов, музыкальных партитур и аудиовизуальной продукции (кинофильмы, телевизионные программы, трансляции спортивных событий) свои схемы идентификаторов. Тематику книг можно указать с помощью схемы иерархической классификации, такой как система десятичной классификации Дьюи, но это еще одна несовместимая система идентификаторов. Ученых можно идентифицировать с помощью идентификаторов ORCID, но у прикладных специалистов такой системы нет. Таким образом, чтобы указать, что конкретная (академическая) книга написана конкретным ученым на известную тему, нужно использовать не просто три разных идентификатора, а три разные схемы! Стандартная схема ссылок на все эти вещи явно имеет смысл.

Обратите внимание, идея Бернерса-Ли не в том, что все должны использовать одни и те же коды URI. Базовое взаимодействие достигается просто с помощью стандарта URI. Хорошо, когда люди достигают соглашения о том, как называть вещи, но это не обязательно. Это верно как для идентификаторов узлов, так и для идентификаторов связей в RDF-графах.

Во-вторых, несмотря на то, что любая URI-совместимая система может использовать ссылку на идентификатор URI во внешнем наборе данных, пользователи этой системы могут не распознать идентификатор. Для незнакомых идентификаторов требуют средства поиска того, на что они указывают. Чтобы узнать что-нибудь о названной сущности, потребляющая система должна знать о такой службе или иметь средства обнаружить ее. В результате число зависимостей и связей, которые приложение-потребитель должно поддерживать для использования определенных схем имен, увеличивается.

Второй принцип несет в себе огромную ценность для обмена данными. Если система может потреблять URI и если это разрешимые URI (URL), то их можно рассматривать как любой другой веб-ресурс и обращаться к ним с запросами GET – чтобы узнать больше о том, к чему они относятся. Не нужно придумывать никакой специальной службы и нет никаких новых зависимостей, помимо HTTP и его единого интерфейса. Имя является идентификатором и дескриптором, по которому можно узнать больше.

Третий принцип уточняет, что если обеспечить стандартную сериализацию стандартных моделей данных — в дополнение к любым другим специальным форматам, которые вы хотите получить при анализе своих ресурсов, — то для разбора результирующей структуры анализирующей системе не нужно знать ничего другого. Система может не знать, каковы идентификаторы, но – согласно второму принципу – всякий раз, когда хочет узнать больше, сможет различить их. В дополнение к стандартным форматам сериализации поддержка стандартных механизмов запросов, таких как SPARQL Protocol, позволяет клиентам задавать вопросы о ваших данных.

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

Так как первый принцип не требует использования стандартных идентификаторов — а только стандартный схемы идентификаторов, — это гарантирует, что в разных наборах данных одним и тем же вещам будут присвоены разные имена. Эту проблему можно решить многими способами, но я не буду вдаваться в детали. Общий подход состоит в том, чтобы использовать семантические отношения более высокого порядка, например, owl:sameAs из языка Web Ontology Language (OWL), чтобы отождествлять идентификаторы на постоянной основе. Тогда для запросов к любым эквивалентным ресурсам можно использовать любую систему аргументации, которая понимает семантику OWL, и получать их свойства. Основные моментом здесь является то, что такие механизмы обеспечивают способы соединения своих терминов с другими. Это обогащает данные и помогает поддерживать возможности поиска между наборами данных.

В целом эти принципы применимы как к общедоступным так и к частным данным. Не надо думать, что все эти технологии применимы только к бесплатным, публичным данным, которыми можно делиться со всеми. В конце концов, все это веб-ресурсы, и их можно разместить за межсетевым экраном, механизмом оплаты и моделями авторизации и проверки подлинности. Цель состоит в том, чтобы решить многие проблемы соединения информации между различными источниками данных с помощью технологий, которые работают на больших масштабах. Достижение этой цели помогает снизить стоимость интеграции почти до нуля по сравнению с более дорогими, хрупкими и трудоемкими технологиями, не основанными на сетевых стандартах.

Чтобы увидеть эти идеи в действии, достаточно рассмотреть проект сообщества Linking Open Data.


Проект Linking Open Data

В 2007 году небольшая группа людей — проект сообщества Linking Open Data (LOD) — взялась за соединение ряда общедоступных наборов данных. На рисунке 1 представлены первые 12 наборов данных, связанных между собой — включая информацию DBpedia, GeoNames и US Census.

Рисунок 1. Облако проекта Linking Open Data в 2007 году
Облако проекта Linking Open Data в 2007 году

Ниже я расскажу о DBpedia подробнее. Пока же начнем с того, что в DBpedia есть информация из Википедии по теме Оберн, штат Калифорния. Другую информацию об Оберне можно найти в 2000 U.S. Census и в проекте GeoNames. Эти три набора данных используют разные идентификаторы для одного и того же (Оберн), но немного покопавшись под капотом, можно обнаружить, что для установления связи между терминами DBpedia использует OWL sameAs. Теперь для запроса данных через механизм рассуждений OWL и извлечения всех результатов можно использовать любой из трех терминов. (Опять же то, как и почему это работает, выходит за рамки настоящей статьи.)

В листинге 1 URI Оберн из проекта GeoNames приравнивается к ресурсу об Оберне в контексте DBpedia на английском языке. Затем я подключаю к ресурсу DBpedia идентификатор Оберна из Freebase. Наконец, я подключаю к английскому контексту идентификатор Оберна из контекста DBpedia на японском языке. Теперь все четыре имени приравнены друг к другу. Триады, указанные в качестве предмета любым из них, теперь верны для них всех.

Листинг 1. Соединение идентификаторов с помощью OWL
# Соединение ресурса DBpedia по Оберну, штат Калифорния, с тремя 
# другими ресурсами с помощью owl:sameAs 
 
@prefix owl:   <http://www.w3.org/2002/07/owl#> . 
 
<http://sws.geonames.org/5325223/> 
  owl:sameAs  <http://dbpedia.org/resource/Auburn,_California> . 
<http://rdf.freebase.com/ns/m.0r2rz>  
  owl:sameAs  <http://dbpedia.org/resource/Auburn,_California> . 
<http://ja.dbpedia.org/resource/オーバーン_(カリフォルニア州)> 
  owl:sameAs  <http://dbpedia.org/resource/Auburn,_California> .

Следует помнить, что это наборы данных из разных организаций, не обязательно произведенные членами проекта LOD. Но они выражены с использованием стандартов, что делает возможным получение данных, доступных широкому кругу клиентов. Некоторые данные хранятся в RDF-файлах, другие – в хранилищах триад, а третьи – в реляционных базах данных и при необходимости отображаются как RDF. Использование технологий связанных данных обычно не обременительно для источников информации. Эти технологии – всего лишь проводники для получения информации и простого ее соединения с родственным контентом. Связь между наборами данных можно присоединить к остальному контенту или хранить отдельно в наборе ссылок.

Из предыдущей статьи вы знаете, что посредством SPARQL можно получать информацию из нескольких источников данных одновременно, просто обращаясь к ним с ключевым словом FROM. Теперь можно оставить источники данных нетронутыми, а хранить в файле связи между идентификаторами, как в листинге 1, и в запросе SPARQL обращаться к этому набору ссылок, как в листинге 2. В этом запросе связь между терминами в каждом из источников данных будет включена в граф и доступна для интеграции на основе механизма рассуждений.

Листинг 2. Запрос SPARQL с наборами данных и наборами ссылок
SELECT variable-list 
FROM dataset1 
FROM dataset2 
FROM linkset 
WHERE { 
   graph pattern 
}

Таким образом были связаны первые 12 наборов данных проекта LOD. Затем к ним добавились другие. Потом еще. Проект добавил новые классы наборов данных, включая цитирование научных исследований; науки о жизни; данные госучреждений; информацию об актерах, режиссерах, кинофильмах, ресторанах и многое другое. К 2014 году были связаны 570 наборов данных, представляющих миллиарды триад RDF. Итоговая схема облака LOD по состоянию на 2014 год приведена на рисунке 2. Еще интереснее изучать интерактивную версию в браузере с поддержкой SVG. Нажимая на большую часть отдельных наборов данных, вы попадаете на соответствующие страницы Datahub.

Схемы облака LOD

Схемы LOD публикуются по лицензии CC-BY-SA и доступны из разных исторических этапов облака. Схема облака Linking Open Data 2014 года Макса Шмахтенберга, Кристиана Брайзера, Анжея Йенцсха и Ричарда Сиганьяка.

Рисунок 2. Облако проекта LOD в 2014 году
Облако проекта Linking Open Data в 2014 году

Кликните, чтобы увидеть увеличенное изображение

Рисунок 2. Облако проекта LOD в 2014 году

Облако проекта Linking Open Data в 2014 году

Многие из этих наборов данных описаны с помощью RDF-словаря для описания взаимосвязанных данных: Vocabulary of Interlinked Datasets (VoID). Кто создал эти наборы? Когда они изменялись в последний раз? Как они велики? Где найти ссылки для их соединения с другими данными? Описание VoID отвечает на все эти вопросы.

Давайте углубимся в один из этих источников данных: DBpedia. DBpedia – одна из первых попыток предоставления структурированных метаданных из Википедии. VoID-описание DBpedia будет содержать метаданные, такие как в листинге 3.

Листинг 3. Пример VoID-описания из DBpedia
@prefix void: <http://rdfs.org/ns/void#> . 
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . 
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . 
@prefix owl: <http://www.w3.org/2002/07/owl#> . 
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> . 
@prefix dcterms: <http://purl.org/dc/terms/> . 
@prefix foaf: <http://xmlns.com/foaf/0.1/> . 
@prefix wv: <http://vocab.org/waiver/terms/norms> .         
@prefix sd: <http://www.w3.org/ns/sparql-service-description#> . 
@prefix : <#> . 
 
:DBpedia a void:Dataset; 
    dcterms:title "DBPedia"; 
    dcterms:description "RDF data extracted from Wikipedia"; 
    dcterms:contributor :FU_Berlin; 
    dcterms:contributor :University_Leipzig; 
    dcterms:contributor :OpenLink_Software; 
    dcterms:contributor :DBpedia_community; 
    dcterms:source <http://dbpedia.org/resource/Wikipedia>; 
 
    dcterms:modified "2008-11-17"^^xsd:date; 
    . 

:DBpedia_Geonames a void:Linkset 
    ... 
    . 

:FU_Berlin a foaf:Organization; 
    rdfs:label "Freie Universität Berlin"; 
    foaf:homepage <http://www.fu-berlin.de/>; 
. 
. 
.

Из этого описания следует, что DBpedia – это данные, извлеченные из Википедии. Хотя большая часть содержания Википедии не структурирована, сайт включает в себя значительную часть редакционно-управляемой структуры. В частности, инфобоксы в статьях стандартизованы, и их информацию легко извлекать хорошо структурированными способами. Как следствие, более 12,6 млн предметов однозначно описаны с применением 2,5 млрд RDF-триад из 119 локализованных языковых контекстов, в том числе:

  • 830 000 персон
  • 640 000 мест
  • 370,000 художественных произведений
  • 210 000 организаций
  • 226 000 видов животных и растений
  • 5600 заболеваний

Каждый из этих предметов представляет собой ресурс со своим собственным разрешимым идентификатором. При оценке масштабов и разнообразия указанных тем помните, что этот многодоменный набор данных поддерживается и курируется добровольцами. Он включает в себя 25 млн ссылок на изображения, 28 млн ссылок на документы и 45 млн ссылок на другие наборы данных RDF. Почти три четверти ресурсов классифицированы по нескольким онтологиям.

У каждого из этих ресурсов есть логический идентификатор, HTML-страница и прямая ссылка RDF/XML-сериализацию:

http://dbpedia.org/resource/Auburn,_California     # логический идентификатор 
http://dbpedia.org/page/Auburn,_California         # HTML-страница 
http://dbpedia.org/data/Auburn,_California.rdf     # Прямая RDF-ссылка

Если проследовать по ссылке на логический ресурс, то вы будете перенаправлены на HTML-представление. Это происходит потому, что при нажатии на эту ссылку браузер запрашивает ответ с указанием в качестве предпочтительного источника HTML. И сервер DBpedia перенаправляет вас на визуализированную форму. Там можно найти связи Оберна с родственными ресурсами, такими как городская газета, округ в котором он находится, и его знаменитости.

Все эти URI представляют собой ссылки на ресурсы, и каждый ресурс описан с помощью RDF из Википедии. То, что вы видите, нажав на ссылку, это не веб-страница данного ресурса, а HTML-отрисовка данных RDF. Например, у Auburn Journal есть своя собственная веб-страница, которую можно найти, отправившись с ресурса газеты по ссылке http://dbpedia.org/ontology/wikiPageExternalLink.

Я упоминал, что большая часть ресурсов DBpedia классифицирована по нескольким онтологиям. Конкретно это означает, что ресурсы представляют собой экземпляры классов, которые также являются RDF-ресурсами. Если внимательно посмотреть на страницу ресурсов Оберна, то можно увидеть, что это rdf:type из нескольких классов, в том числе:

Обратите внимание, что это разные классы из разных схем. Легко догадаться, как можно в любое время добавлять новые категории, устанавливая новые отношения экземпляра rdf:type со всем, что имеет смысл. Однако это отношение членства в наборе. То есть можно спрашивать обо всем, что входит в этот набор (или является экземпляром этого класса). Если отправиться по ссылке на категорию http://dbpedia.org/class/yago/CitiesInPlacerCounty,California, то можно увидеть другие города округа Placer County, включая Лумис, Роклин и Роузвиль. Здесь вы видите набор связанных городов, основанный на отношении вложенности как частей одного и того же округа.

Класс http://dbpedia.org/class/yago/CountySeatsInCalifornia включает в себя гораздо больший набор. Здесь классифицированы главные города округов штата Калифорния, и к ним можно переходить через отношения к другим, о которых вам известно. Навигация по ссылкам эффективно осуществляется с помощью неявных запросов SPARQL, обрабатываемых за кулисами. Вот эквивалентный запрос:

SELECT ?s WHERE { 
 ?s a <http://dbpedia.org/class/yago/CountySeatsInCalifornia> 
}

Так как DBpedia поддерживает протокол SPARQL, о котором я писал в предыдущей статье, этот запрос можно превратить в прямую ссылку. Вот расширенная форма:

http://dbpedia.org/snorql/?query=SELECT+%3Fs+WHERE+%7B%0D%0A+%3Fs+a+%3Chttp%3A \ 
%2F%2Fdbpedia.org%2Fclass%2Fyago%2FCountySeatsInCalifornia%3E%0D%0A%7D

Теперь объединим некоторые вещи, которые я показал вам, в новый запрос:

SELECT ?s ?page WHERE { 
 ?s a <http://dbpedia.org/class/yago/CountySeatsInCalifornia> ; 
 <http://dbpedia.org/ontology/wikiPageExternalLink> ?page . 
}

Добавим к предыдущему запросу еще одно отношение. Теперь мы просим: «Показать все главные города округов штата Калифорния и связанные с ними внешние веб-страницы». Это мощный запрос, позволяющий автоматически объединять данные, извлекаемые из Википедии. Его результаты можно увидеть здесь.

Теперь внесем в запрос одно простое изменение. Вместо ресурсов, которые являются членами класса http://dbpedia.org/class/yago/CountySeatsInCalifornia, используем http://dbpedia.org/class/yago/CapitalsInEurope:

SELECT ?s ?page WHERE { 
 ?s a <http://dbpedia.org/class/yago/CapitalsInEurope> ; 
   <http://dbpedia.org/ontology/wikiPageExternalLink> ?page . 
}

Результаты здесь. Ничего не изменилось, кроме того, что теперь результаты отражают внешние веб-страницы, связанные со столицами стран на Европейском континенте!

Если изменить искомое отношение к ресурсам, классифицированным подобным образом, то можно задать совершенно другой вопрос. Этот запрос, вместо внешних ссылок, дает информацию о широте и долготе:

SELECT ?s ?lat ?long WHERE { 
 ?s a <http://dbpedia.org/class/yago/CapitalsInEurope> ; 
   <http://www.w3.org/2003/01/geo/wgs84_pos#lat> ?lat ; 
   <http://www.w3.org/2003/01/geo/wgs84_pos#long> ?long . 
} 
ORDER BY ?s

Результаты здесь.

Нетрудно представить себе получение информации в ответ на такой запрос и ее отображение на карте Google Maps. Результат этого показан на рисунке 3, а взаимодействовать с этим результатом можно здесь. Подумайте о том, как много кода пришлось бы изменить, чтобы найти и визуализировать места рождения всех глав государств европейских стран. (Подсказка: очень много.)

Рисунок 3. Европейские столицы из DBpedia
Европейские столицы из DBpedia

Кликните, чтобы увидеть увеличенное изображение

Рисунок 3. Европейские столицы из DBpedia

Европейские столицы из DBpedia

Теперь, когда мы знаем механику, не трудно представить, как задавать другие вопросы на произвольные темы. Мой любимый запрос к DBpedia (который мне предложил Боб Дюшарм) – найти все приколы на школьной доске из всех эпизодов «Симпсонов». Отправившись по этой ссылке, имейте в виду, что каждый эпизод также является ресурсом, который содержит ссылки на режиссера эпизода, особых гостей, героев и т.п. Каждый эпизод классифицируется как член набора телевизионных программ определенного года выпуска. Следуя по ссылкам, относящимся к этим классам, можно найти другие телевизионные эпизоды, которые выходили в эфир примерно в то же время.

Так что предела разнообразию вопросов, которые можно задавать DBpedia, не существует. И имейте в виду, что DBpedia – лишь один из почти 600 наборов данных, которые входят в облако LOD. Связанные данные дают впечатляющие результаты при относительно малом количестве усилий.


Заключение

Подумайте о том, как много времени уходит у вашей организации на то, чтобы интегрировать каждый новый источник данных. Связанные данные – это принципиально иной подход, который работает при уровнях производительности, масштаба и гибкости, которые трудно себе представить, если все, что вы когда-либо имели в своем распоряжении, – это решения уровня предприятия, зависящие от языка программирования. Ничто в этом подходе не ограничивает его применимости и к общедоступным данных. Те же идеи легко использовать за пределами межсетевого экрана.

Фрагменты связанных данных

Для решения задачи надежных запросов к связанным данным одна группа предложила новый подход, называемый фрагментами связанных данных (Linked Data Fragments). Это пока не стандартный подход, но он несет в себе много полезных идей, с которыми я советую вам ознакомиться.

Связанные данные – это не магия. Стандартные идентификаторы, разрешаемые путем стандартной сериализации стандартных моделей данных, – это простой (хотя, возможно, и не интуитивно понятный) набор концепций. Однако с технической точки зрения поддержка протокола SPARQL в открытом Интернете – невероятно трудное дело. Трудно предсказать, какие виды нагрузок на ваши серверы будут исходить от случайных людей. В работу DBpedia вкладываются значительные усилия. Подробнее об этом процессе можно прочесть на веб-сайте.

В следующей статье я представлю программную платформу, основанную на этих идеях, и, наконец, начну знакомить вас с технологиями Open Services Lifecycle Collaboration (OSLC).

Ресурсы

Научиться

  • Оригинал статьи: Data integration at scale: Linked Data.
  • Связанные данные: читайте о почти 600 наборах данных проекта LOD, их истоках, способах их создания и связях между ними.
  • Фрагменты связанных данных: Читайте о менее обременительном способе, позволяющем удаленным клиентам запрашивать данные.
  • DBpedia: исследуйте набор данных, извлеченных из Википедии.
  • Wikidata: у Википедия есть свой собственный источник данных, вдохновленный успехами DBpedia, который теперь предлагает свою собственную конечную точку SPARQL.
  • Linked Data (Tom Heath and Christian Bizer, Morgan & Claypool, 2011 г.): первая всесторонняя книга о принципах связанных данных и проекте связанных данных.
  • Linked Data (David Wood et al., Manning Publications, 2014 г.): еще одна книга о создании систем, основанных на принципах связанных данных.

Обсудить

  • Semantic Web Interest Group: примите участие в форуме разработчиков и пользователей технологий Semantic Web.

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


  • Bluemix

    Узнайте больше информации о платформе IBM Bluemix, создавайте приложения, используя готовые решения!

  • Библиотека документов

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Web-архитектура, XML
ArticleID=1033165
ArticleTitle=Широкомасштабная интеграция данных: Cвязанные данные
publish-date=08072016