Главная » Двор и сад » RDF — инструмент для неструктурированных данных. RDF Это просто

RDF — инструмент для неструктурированных данных. RDF Это просто

Editor’s Note: This presentation was given by Jesús Barrasa at GraphConnect San Francisco in October 2016.

Presentation Summary

Resource Description Framework (RDF) triple stores and labeled property graphs both provide ways to explore and graphically depict connected data. But the two are very different – and each have different strengths in different use cases.

In this presentation, Dr. Jesús Barrasa starts with a brief , including the origins of the Semantic Web.

A Brief History: The RDF and Labeled Property Graph

Let’s go over a brief history on where these two models come from. RDF stands for Resource Description Framework and it’s a W3C standard for data exchange in the Web. It’s an exchange model that represents data as a graph, which is the main point in common with the Neo4j property graph.

It understands the world in terms of connected entities, and it became very popular at the beginning of the century with the article the Semantic Web published in Scientific American by Tim Berners-Lee, Jim Hendler and Ora Lassila. They described their vision of the Internet, where people would publish data in a structured format with well-defined semantics in a way that agents - software - would be able to consume and do clever things with.

Next, persisting RDF - storing it - became a thing, and these stores were called triple stores . Next they were called quad stores and included information about context and named graphs, then RDF stores, and most recently they call themselves “semantic graph database.”

So what do they mean by the name “semantic graph database,” and how does it relate to Neo4j?

The labeled property graph, on the other hand, was developed more or less at the same time by a group of Swedish engineers. They were developing a ECM system in which they decided to model and store data as a graph.

The motivation was not so much about exchanging or publishing data; they were more interested in efficient storage that would allow for fast querying and fast traversals across connected data. They liked this way of representing data in a way that’s close to our logical model - the way we draw a domain on the whiteboard.

Ultimately, they thought this had value outside the ECM they were developing and a few years later their work became Neo4j.

The RDF and Labeled Property Graph Models

Now, taking into account the origin of both things - the RDF model is more about data exchange and the labeled property graph is purely about storage and querying - let’s take a look at the two models they implement. By now you all know that a graph is formed of two components: vertices and the edges that connect them. So how do these two appear in both models?

In a labeled property graph, vertices are called nodes, which have a uniquely identifiable ID and a set of key-value pairs, or properties, that characterize them. In the same way, edges, or connections between nodes – which we call relationships - have an ID. It’s important that we can identify them uniquely, and they also have a type and a set of key value of pairs - or properties that characterize the connections.

The important thing to remember here is that both the nodes and relationships have an internal structure, which differentiates this model from the RDF model. By internal structure I mean this set of key-value pairs that describe them.

On the other hand, in the RDF model, vertices can be two things. At the core of RDF is this notion of a triple, which is a statement composed of three elements that represent two vertices connected by an edge. It’s called subject-predicate-object . Subject will be a resource, or a node in the graph. The predicate will represent an edge – a relationship - and the object will be another node or a literal value. But here, from the point of view of the graph, that’s going to be another vertex:

The interesting thing to know is that resources (vertices/nodes) and relationships (edges) are identified by a URI, which is a unique identifier. This means that neither nodes nor edges have an internal structure; they are purely a unique label. That’s one of the main differences between RDF and labeled property graphs.

Let’s take a look at an example to make this a bit more clear:

Here’s a rich snippets that Google returns when you do a search for Sketches of Spain , which is one of my favorite albums by Miles Davis. This search returns a description of the album with things like the artist, the release date, the genre, producers and some awards. I’m going to represent this information in both models below.

Below is one of the possible serializations of RDF called Turtle syntax:

You can see that the triples are identified by a URI, which is the subject. The predicate is the name and the object will be Sketches of Spain , which together is a sequence of triples. So these are the kinds of things you will have to write if you want to insert data in a triple store.

Let’s look at how this information is displayed graphically:

The nodes on the left represent the album, which has a set of edges coming out of it. The rectangles represent literal values - the description: album about Miles Davis, the genre, the title - and it has connections to other things that are in ellipses that represent other resources (i.e., other nodes in the graph) that have their own properties and attributes.

What this means is that by representing data in RDF with triples, we’re kind of breaking it down to the maximum. We’re doing a complete atomic decomposition of our data, and we end up finding nodes in the graph that are resources and also literal values.

Now let’s look at it from the point of view of the labeled property graph. What I’ve created below is a sequence of statements that contain exactly the same information as the Turtle syntax above:

The semantics are the same. There’s no standard serialization format, or a way of expressing a labeled property graph, but rather a sequence of CREATE statements do the job here.

We create a node, which is more obviously represented with a parenthesis, and then the attributes - or the internal structure - in the curly bracket: the name, the description and the genre. Likewise, the connections between nodes are described with hard brackets.

Below is what the labeled property graph looks like:

The first impression is that it’s much more compact. Even though it has certain elements in common with the RDF graph, it’s completely different because nodes have this internal structure and values of attributes don’t represent vertices in the graph.

This allows for a much more reduced structure. But we still have the album at the center, which is connected to a number of entities, but the title, name and description aren’t represented by separate nodes. That’s a first distinction.

Sometimes there’s confusion when we compare the two models. If you have a graph with two billion triples, how do the two compare in terms of nodes, for example? If we take a graph with n nodes with five properties per node, five attributes, five relationships and five connections, we would get 11 triples per node in a labeled property graph.

Again, I’m not comparing storage capacity, but keep in mind that when you have a 100 million triple graph (i.e., RDF graph), that’s an order of magnitude bigger than a labeled property graph. That same data will probably be equivalent to a ten-million-node labeled property graph.

Key Differences Between RDF and Property Graphs

Difference #1: RDF Does Not Uniquely Identify Instances of Relationships of the Same Type

Now that we know a bit more about the two models, let’s compare differences in terms of exclusivity.

The first one is quite important, and that is the fact that in RDF it’s not possible to uniquely identify instances of a relationship. In other words, we can say: it’s not possible to have connections of the same type between the same pair of nodes because that would represent exactly the same triple, with no extra information.

Let’s look at the following as an example, a labeled property graph and an RDF graph in which Dan cannot like Ann three times; he can only do it once:

We create a node called Dan that LIKES Anne . I repeat that Dan likes Anne two more times, and I end up with a graph that has three connections of type LIKES between Dan and Ann. Good.

Not only can we visualize this in a helpful way, but we can also query it to ask, “How many times does this pattern appear in the graph?” which returns a count of three.

Now let’s try to do the same in RDF using SPARQL:

What insert a statement that says Dan has name Dan, Ann has name Ann and Dan LIKES Ann, which we repeat three times. But see the graph that we get instead (above).

We have the values of the properties as vertices of the graph, and we have Dan with name Dan. We have Ann with name Ann, and we have a single connection between them, which is sad, because Dan liked her three times.

If I do the count again searching for this particular triple pattern, and I do the count, I get one. The reason for that is it’s not possible to identify unique instances of relationships of the same type with an RDF triple store.

Difference #2: Inability to Qualify Instances of Relationships

Second, because you can’t identify these unique instances in RDF, you cannot qualify them or give them attributes. Let’s take a look at another example that explores flights between New York City and San Francisco:

It costs $300 and is a total of 4,100 kilometers. Again, this statement can be expressed in Neo4j’s graph query language, Cypher, saying that there’s a connection between New York City and San Francisco, and that the connection has two attributes: the distance and the cost in dollars.

We produce a nice graph and can query the cost and distance of the connection to return two nodes.

If I try to do the same in RDF, I encounter a problem:

In this query, we say there’s a city called New York, a city called San Francisco, and a connection between them.

But how do I state the fact that this connection has a cost? I could try to say something like, “Connection has a distance.” But which connection? That would be a global property of the connection, so you can’t express that in RDF. As you can see above, here’s the graph that this type of SPARQL query produces.

RDF Workarounds

There are a few alternatives for these weaknesses in RDF.

One of them is a data modeling workaround, but we’re going to see that this is the same problem we experience with a . What happens when we have these many-to-many relationships - people knowing people, and people being known by others? This provides an entity-relationship model, but then you have to translate this into tables with several JOINs.

Because the modeling paradigm doesn’t offer you a way to modeling these types of relationships, you have to use what you have on hand and represent it the way you can. And as you know, the problem is that this starts building a gap between your model as you conceive it, and the model that you store and query. There are two alternate technical approaches to this problem: reification and singleton property.

Below is one RDF data modeling workaround, which is the simple option:

Because in RDF we don’t have attributes in relationships, we create an intermediate node. On the left is what I can do in the labeled property graph. Because we can’t create such a simple model in RDF, we create an entity that represents the connection between New York and San Francisco.

Once I have that node, I can get properties out of it. This alternative isn’t too bad; the query will be more complicated, but okay.

Now let’s take a look at reification, which - as you can see - isn’t very readable:

We still have Dan with with name Dan , and Ann with name Ann with a connection saying that he likes her.

With reification, we create a metagraph on top of our graph that represents the statement that we have here. We create a new node that represents a statement and points at the subject Dan, at the object Ann, and at the property stating the fact that he likes her. Now that I have an object - a node - I can add a counter, which tells us three.

This is quite ugly. On the one hand, you can still query who Ann likes:

But if you want to query “how many times,” you have to go look at both the graph and the metagraph. So if Dan likes Ann, then look at the statement that connects Dan and Ann and get the counter.

Now, imagine if you need to update that. You would have to say, “Dan has liked her one more time.” You wouldn’t come and say, “Add one more” because that doesn’t add more information. You will have to come and say, “Grab a pattern, take the value in the counter, increase it by one, and then set the new value.”

The Singleton property is another modeling alternative pretty much in the same vein:

You have your original model - Dan with his name who likes Ann, with her name. You can give this relationship a unique name, ID1234 , which allows us to describe it. We can say it’s an instance of likes and I can give it a counter of three.

Again, I’m building a metamodel that - while more compact than the reification model - still doesn’t allow you to ask, “Who does Dan like?” You have to ask, “Who does Dan 1234 ?” which is the type like .

Difference #3: RDF Can Have Multivalued Properties and the Labeled Property Graph Can Have Arrays

In RDF you can have multi-value properties - triples where the subject and predicate are the same but the object is different - which is fine. In the labeled property graph you have to use arrays, which is the equivalent.

In the snippet we had before, we had an album that had two values for the genre property: jazz and orchestral jazz. That’s easy to express in triples, and in Cypher you will need to use an array - not too bad.

Difference #4: RDF Uses Quads for Named Graph Definition

Another difference is this notion of quad, which has no equivalent in labeled property graphs. You can add context or extra values to triples that identifies them and makes it easy to define subgraphs, or named properties.

We can state that Dan likes Ann in graph one and Ann likes Emma in another graph:

RDF & Labeled Property Graph Query Languages

The two different models also rely on different database query languages.

Because of the atomic decomposition of the data and RDF, you typically have longer patterns when you perform queries. Below is a query that has the names of artists with albums produced by Irving Thompson:

You have four patterns, each of which represents each of the edges in the more compact labeled property graph. But this isn’t what I would call an essential differentiator.

There were a few recent updates to both the SPARQL and Cypher query languages:

Something like uppercasing the values of a property in Cypher is very SQL-like and simple.

You can much a person and attribute name to uppercase , whereas in SPARQL you will have to MATCH it, BIND it to a variable, do the uppercase , and then do the insertion and the deletion because we can have multiple values. So by updating you need to delete the previous value, unless you want to keep both of them.

RDF & Labeled Property Graph Data Stores

RDF stores are very strongly index-based, while Neo4j is navigational. It implements index-free adjacency, which means that it stores the connections between connected entities, between connected nodes, in disks.

This means that when you query Neo4j, you’re actually chasing pointers instead of scanning indexes. We know that index-based storage is okay for queries that aren’t very deep, but it’s very difficult to do something like path analysis. Compare that to Neo4j, which allows you to have native graph storage that is best for deep or variable-length traversals and path queries.

It’s fair to say that triple stores were never meant to be used in operational and transactional use cases. They should be used in mostly additive, typically slow-changing - if not immutable - datasets. For example, the capital of Spain is Madrid, which isn’t likely to change. Conversely, Neo4j excels in highly dynamic scenarios and transactional use cases where data integrity is key.

A Comparison: Semantics

The first two lines are on the front end of RDF in total notation, saying that John Smith lives in London and that London is a city in England. The second one is a fragment of JSON that could easily represent the same information. The third one is JSON-LD and includes both the data and the ontology, and the final one is a fragment of Cypher.

Semantics can mean two things in the RDF world. The first is the idea of vocabulary-based semantics. Because you can identify relationships with URIs, you can define agreed-upon vocabularies like Schema.org and Google Knowledge Graph (GKG) . This covers most of the usage of RDF today.

The other meaning is inference-based semantics, which is rule-based - including OWL. We use this when we want to express what the data means so that I can infer facts, do some reasoning or check the consistency of the dataset.

Let’s look at a couple examples. The first example provides a simple pair of facts: John lives in London. London is in England. You can express this with two RDF triples:

:JohnSmith:livesIn:London:London:locationIn:England
Now you run a query: who lives in England? You can express that in SPARQL:

SELECT ?who WHERE { ?who:livesIn:England }
But it returns zero results because you have to say:

X:livesIn ?city ^ ?city:cityIn ?ctry => ?x:LivesIn ?ctry
If someone lives in a city and the city is in a country, then you live in the country. But no one’s going to figure that out if you don’t make it explicit in a rule, and this is an example of how you have to make the semantic explicit. The real question is: are your semantics explicit?

If we ask the question again, now that we have defined our rule, it will return John Smith.

Below is another example that shows importing data from two data sources into a triple store. There are two facts coming from datasource1: Jane Smith’s email is [email protected], and her Twitter handle is @jsmith. This can look like the following two triples:

:JaneS1:hasEmail "[email protected]" :JaneS1:hasTwitterHandle "@jsmith"
Now we get another pair of triples from another data source that says: Jane Smith’s email is [email protected] and her LinkedIn profile is “http://linkdn.com/js.” Again, the two triples below look like this:

:js2:hasEmail "[email protected]" :js2:hasLnkdnProfile "http://linkdn.com/js"
Next you put it into the RDF graph thinking that semantics are going to do the magic. You ask the question: What’s the LinkedIn profile of the person tweeting as @jsmith? The SPARQL query looks like this:

SELECT ?profile WHERE { :hasTwitterHandle "@jsmith" ; :hasLnkdnProfile ?profile . }
But again you get no results, because - like in the previous case - you have to say that the email address is a unique identifier and therefore you can infer that if two resources have the same email, you can derive that they’re the same and can be expressed with a rule like this one:

X:hasEmail ?email ^ ?y:hasEmail ?email => ?x owl:sameAs ?y
You can also express this more elegantly in OWL, which would look like this:

:hasEmail rdf:type owl:InverseFunctionalProperty ?prop a owl:InverseFunctionalProperty ?p^ ?x ?p ?al => owl:sameAs ?y
An inverse functional property is a primary-key-style property. It’s not exactly the same because a primary key is a kind of constraint that would prevent you from adding data to your database if there’s another one with the same value.

Here, you can add data without any problem. But if we find two that have the same value, we’re going to think that these two are the same.

Even if we express this in a more declarative way, these are the semantics of an inverse functional property. Basically if two values have the same value, I can derive that they are the same. We re-run the query and this time it will return Jane Smith’s LinkedIn profile.

It’s all about making the data explicit. There’s really no magic here; RDF is just a way of making data more intelligent and making your semantics explicit. Below is a quote from Tim Burners-Lee that speaks to this:

A Demo: How Do We Get to a Semantic Graph Database?

I’m going to show features and capabilities in Neo4j that are typically from RDF as stored procedures and extensions. Hopefully, they’ll make their way into the APOC library soon.

So what are the takeaways from this demo? The first one was mentioned in the presentation by the Financial Times, an organization that made the transition from RDF to a labeled property graph.

They thought they needed a linked semantic data platform to connect their data, but what they actually needed was a graph. So always ask yourself what kind of features you need. Is it about the inferencing? Is it about semantics? Or is it just a graph?

If you store your data in RDF and query it in SPARQL, you’re not semantic - you have a graph. In most of the use cases, you find yourself not using as much of OWL and all the semantic capabilities as you would, because you know it’s extremely complex and it results in performance issues. If you’re working with a reasonably-sized dataset, don’t expect it to finish the query.

We also know that publishing RDF out of Neo4j is trivial, which is the same with importing RDF. The code is under 100 lines and is available on Github . It’s a really simple task.

And I’ve also shown that inference doesn’t require OWL. In the end, semantics (inference) is just data-driven, server-side logic, typically implemented as rules. You’re putting some intelligence close to your data that’s in turn driven by an ontology. And if you manage to balance expressivity and performance without falling into unneeded complexity, then it may be a useful tool.

I’m not going to criticize OWL because its own creators discuss why it’s not being adopted. It’s definitely not taking off, and I think one of the reasons is because it can be overkill for many use cases.

Базовой структурной единицей RDF является коллекция троек (или триплетов), каждый из которых состоит из субъекта, предиката и объекта (S,P,O). Набор триплетов называется RDF-графом. В качестве вершин графа выступают субъекты и объекты, в качестве дуг – предикаты (или свойства). Направление дуги, соответствующей предикату в данной тройке (S,P,O), всегда выбирается так, чтобы дуга вела от субъекта к объекту.

Рис. 17. RDF-тройка.

Каждая тройка представляет некоторое высказывание, увязывающее S, P и O.

Первые два элемента RDF-тройки (Subject, Predicate) идентифицируются при помощи URI.

Объектом может быть как ресурс, имеющий URI, так и RDF-литерал (значение).

RDF-литералы (или символьные константы)

RDF-литералы бывают 2-х видов: типизированные и не типизированные.

Каждый литерал в RDF-графе содержит 1 или 2 именованные компоненты:

Все литералы имеют лексическую (словарную) форму в виде строки символов Unicode.

Простые литералы имеют лексическую форму и необязательную ссылку на язык (ru, en…).

Типизированные литералы имеют лексическую форму и URI типа данных в форме RDF URI.

Замечание . Язык литерала не нужно путать с идентификатором локали. Языка относится только к текстам, написанным на естественном языке. Все трудности, возникающие при представлении данных на конкретном компьютере (при определении локали), должны решаться конечным пользователем.

Сравнение литералов

Два литерала равны тогда и только тогда, когда выполняются все перечисленные ниже условия:

1. Строки обеих лексических форм совпадают посимвольно;

2. Либо оба литерала имеют теги языка, либо оба не имеют;

3. Теги языка, если они имеются, совпадают;

4. Либо оба литерала имеют URI типа данных, либо оба не имеют;

5. При наличии URI типа данных, эти URI совпадают посимвольно.

Определение значения типизированного литерала

Приведем пример:

Пусть множество {T, F} - множество значений истинности в математической логике. В различных приложениях элементы этого множества могут представляться по-разному. В языках программирования {1, 0} (1 соответствует T, 0 соответствует F), либо {true, false}, либо {истина, ложь}.

Фактически задается некоторое отображение множества значений истинности на множество чисел или строк символов. Теперь значениями логического типа (bool или boolean) в становятся строковые значения или спецсимволы. Чтобы получить значения истинности необходимо воспользоваться обратным отображением.

Таким же образом происходит получение значения типизированного RDF литерала. За лексической формой стоит некоторое значение, которое определяется применением отображения. Это отображение определяется по URI типа данных и зависит от самого типа.

Основы языка представления RDFS.

Каждый из элементов триплета определяется независимо ссылкой на тип элемента и URI.

Предикат (в контексте RDF его обычно называют свойством) может пониматься либо как атрибут, либо как бинарное отношение между двумя ресурсами. Но RDF сам по себе не предоставляет никаких механизмов ни для описания атрибутов ресурсов, ни для определения отношений между ними. Для этого предназначен язык RDFS – (язык описания словарей для RDF). RDF Schema определяет классы, свойства и другие ресурсы.

Рис.18. RDF-тройка субъект-предикат-объект

RDFS является семантическим расширением RDF. Он предоставляет механизмы для описания групп связанных ресурсов и отношений между этими ресурсами. Все определения RDFS выражены на RDF (поэтому RDF и называется «самоописывающимся» языком). Новые термины, вводимые RDFS, такие как «домен», «диапазон» свойства, являются ресурсами RDF.

Resource Description Framework (RDF, «среда описания ресурса» ) - это разработанная консорциумом Всемирной паутины модель для представления данных, в особенности - метаданных . RDF представляет утверждения о ресурсах в виде, пригодном для машинной обработки. RDF является частью концепции семантической паутины .

Ресурсом в RDF может быть любая сущность - как информационная (например, веб-сайт или изображение), так и неинформационная (например, человек, город или некое абстрактное понятие). Утверждение, высказываемое о ресурсе, имеет вид «субъект - предикат - объект» и называется триплетом . Утверждение «небо голубого цвета» в RDF-терминологии можно представить следующим образом: субъект - «небо», предикат - «имеет цвет», объект - «голубой». Для обозначения субъектов, отношений и объектов в RDF используются URI .

Множество RDF-утверждений образует ориентированный граф , в котором вершинами являются субъекты и объекты, а рёбра отображают отношения.

История

История появления RDF имеет своё начало в 1990 году , когда Тим Бернерс-Ли предложил отмечать типы ссылок между документами для облегчения автоматической обработки. Типы ссылок однако не были включены в первую спецификацию HTML , но идея была подхвачена в системе описания метаданных MCF . Обобщённое представление метаданных нашло отражение в рекомендации W3C по RDF в 1999 году . С тех пор стандарты RDF развиваются, появляются новые средства для работы с RDF .

Набор стандартов

2015 год:
- Linked Data Platform 1.0 (англ.) - Введение в Linked Data , описание предлагаемых подходов к использованию RDF в сети Интернет.
- Формат представления RDFa
  - RDFa Core 1.1 - Third Edition (англ.) - Описание основ синтаксиса «RDFa» для RDF 1.1
  - RDFa Lite 1.1 - Second Edition (англ.) - Описание облегчённого синтаксиса «RDFa Lite» для RDF 1.1
  - HTML+RDFa 1.1 - Second Edition (англ.) - Особенности синтаксиса «RDFa» в HTML для RDF 1.1
  - XHTML+RDFa 1.1 - Third Edition (англ.) - Особенности синтаксиса «RDFa» в XHTML для RDF 1.1
2014 год:
- Модель данных RDF 1.1:
  - RDF 1.1 Concepts and Abstract Syntax (англ.) - Понятия и абстрактный синтаксис RDF 1.1
  - RDF Schema 1.1 (англ.) - Словарь RDF 1.1
  - RDF 1.1 Semantics (англ.) - Семантика RDF 1.1
- Форматы представления:
  - RDF 1.1 XML Syntax (англ.) - Описание синтаксиса «RDF/XML » для RDF 1.1
  - RDF 1.1 Turtle (англ.) - Описание синтаксиса «Turtle» для RDF 1.1
  - RDF 1.1 N-Triples (англ.) - Описание синтаксиса «N-Triples» для RDF 1.1
  - RDF 1.1 N-Quads (англ.) - Описание синтаксиса «N-Quads» для RDF 1.1
  - RDF 1.1 TriG (англ.) - Описание синтаксиса «TriG» для RDF 1.1
  - JSON-LD 1.0 (англ.) - Описание синтаксиса «JSON-LD», представление RDF-данных в формате JSON
  - JSON-LD 1.0 Processing Algorithms and API (англ.) - Описание алгоритмов обработки и их API для RDF-данных, представленных в форме «JSON-LD»
- Прикладные словари и онтологии
  - Data Catalog Vocabulary (DCAT) (англ.) - онтология понятий в области описания опубликованного в сети каталога информации и содержащихся в нём наборов данных
  - The RDF Data Cube Vocabulary (англ.) - онтология понятий в области описания многомерных наборов данных
  - The Organization Ontology (англ.) - онтология понятий в области описания структуры организаций
2013 год:
- Rule Interchange Format
  - RIF RDF and OWL Compatibility (Second Edition) (англ.) - использование с RDF рекомендуемого W3C подхода к описанию и выполнению правил
- Связанные стандарты
  - Internationalization Tag Set (ITS) Version 2.0 (англ.)
2012 год:
- rdf:PlainLiteral: A Datatype for RDF Plain Literals (Second Edition) (англ.)
- Отражение реляционных данных в RDF:
  - A Direct Mapping of Relational Data to RDF (англ.) - прямое
  - R2RML: RDB to RDF Mapping Language (англ.) - гибкое
  - Use Cases and Requirements for Mapping Relational Databases to RDF (англ.) - исходные примеры применения и требования, 2010 год
- (англ.) - онтология для описания медиа-ресурсов
2008 год:
2004 год:
- (англ.) - Понятия и абстрактный синтаксис RDF 1.0
- RDF Semantics (англ.) - Семантика RDF 1.0
- RDF Test Cases (англ.) - Набор тестовых данных RDF
- RDF Primer (англ.) - Введение в RDF

Также есть множество черновиков и заметок, среди которых есть Linked Data Glossary (англ.) - глоссарий всех понятий, связанных с RDF.

Форматы представления

Для записи и передачи RDF используется несколько форматов, в том числе:

Семантика

RDF предоставляет средства для построения информационных моделей, но не касается семантики описываемого. Взятый в отдельности граф RDF можно понимать только как граф. Толкование значения основывается на способности пользователей RDF интерпретировать отдельные URI, строковые литералы и структуру графа, и по ним интерпретировать остальные URI и семантику данных.

Для выражения семантики требуются словари (англ. vocabularies ), таксономии (англ. taxonomies ) и онтологии (англ. ontologies ) и наличие в рассматриваемом графе связей с ними.

Словарь представляет собой собрание терминов, имеющих во всех контекстах использования этого словаря одинаковый смысл.

Таксономия - это словарь иерархически организованных терминов.

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

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

RDF Schema

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

декларирует существование ресурсов, среди которых отдельно выделяет литералы разных типов данных, в том числе строк с указанием языка, строк с XML-или HTML-разметкой;
декларирует существование классов ресурсов и их подклассов;
декларирует существование свойств, которые относятся к ресурсам определённого класса, могут объектами иметь ресурсы конкретных классов, и могут быть более узко осмысленным вариантом более общего свойства;
декларирует существование таких часто используемых свойств как «наименование», «описание», «ресурс-синоним», и некоторых других;
описывает классы и свойства, позволяющие организовать в модели RDF три вида списков;
описывает классы и свойства, нужные для реификации (от англ. reification , воплощение) - обеспечения возможности записи триплетов, объектом и субъектом которых являются триплеты.

Описание дополнительной семантической нагрузки этого словаря расположено во всех трёх основных стандартах RDF - в описании концепций RDF (англ.) , в описании самого словаря (англ.) , и в описании семантики RDF (англ.) .

В частности, в описании семантики RDF говорится, что словари могут лишь подразумевать, но не содержать в явном виде триплеты, которые можно получить из остальных триплетов словаря путём исполнения ряда определённых для словаря формальных правил, следующих из семантики используемых словарём понятий. И приведён перечень правил, подразумеваемых словарём RDF Schema.

OWL

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

RDF-хранилища

Для хранения RDF-данных используются два основных вида хранилищ: специализированные (native, «родные», «нативные») и не специализированные (non-native). Специализированные хранилища позволяют достичь большей степени оптимизации, но более трудоёмки в проектировании, так как строятся специально для работы с RDF. Остальные хранилища более просты в проектировании (например, за счёт использования механизмов реляционных СУБД или решений NoSQL), но менее оптимизированы под работу с RDF. Специализированные хранилища делятся по способности оперировать с данными, лишь целиком находящимися в оперативной памяти (in-memory) или же способные использовать и внешнюю память (например, жёсткий диск) .

Системы для работы с RDF разрабатываются как в рамках исследований, так и для производственного использования. К основным специализированным хранилищам, пригодным для производственного использования, относятся :

Применение

Оформление баз знаний или представления их данных в рамках различных проектов в множестве институтов, университетов и иных организаций. В основном, в научно-исследовательских целях.

Поисковые системы предлагают веб-мастерам использовать RDF и аналогичные языки разметки страниц для повышения информативности ссылки на их сайт в результатах поиска.

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

Кроме вышеперечисленного, в формате RDF представляют данные для анализа и/или интеграции в информационных системах предприятий , что даёт возможность исследовать их при помощи SPARQL (проект D2RQ, например), а при опоре на отраслевой стандарт, например, ISO 15926 позволяет унифицированно обмениваться данными различных предприятий на уровне отрасли.

Использование RDF увеличилось с появлением представления RDF в виде JSON-LD и распространением Linked Data. Например, Google принимает во внимание семантическое описание страницы в одном из RDF-форматов (и с использованием словаря Schema.org) и использует его для более подробного описания результатов поиска

Оптимизация для улучшения работы поисковых машин и других изощренных инструментов

Обзор

Исторически веб-технологии концентрировались на "впечатлениях и ощущениях", порождаемых веб-страницами и веб-сайтами. Самыми важными были следующие соображения: визуально привлекательный дизайн, ссылки и JavaScript-приложения, работающие надлежащим образом и поддерживающие новейшие мультимедийные функции. Все более важным стало нахождение в верхней части результирующих списков, выдаваемых поисковыми машинами. К сожалению, поисковые машины не видят дизайна веб-сайта и не ощущают динамики его поведения; они видят лишь разметку, которая сводится для них к типу шрифта (полужирный, курсив и т. д.) или к выделению того или иного блока контента.

Часто используемые сокращения

HTML: HyperText Markup Language
RDF: Resource Description Framework
SEO: Search Engine Optimization

Сетевые авторы начали осознавать, что они нуждались в чем-то большем, чем презентационные украшения. Они нуждались в средствах, позволяющих указать поисковой машине или любой другой подобной программе на реальную структуру данных. Например, на то, какая именно информация соответствует цене, дате проведения мероприятия, элементу контактной информации человека и т. д. Существовала потребность в т. н. "сети данных", удовлетворение которой на протяжении долгого времени являлось основной заботой разработчиков модели RDF (Resource Description Framework).

Концепция RDF весьма проста, однако, к сожалению, многие ее аспекты слишком сложны при описании, обсуждении и обработке. Применительно к веб-технологиям типичная рекомендация звучит следующим образом: "Убедитесь в том, что обычный сетевой автор сможет изучить предлагаемую технологию за один день". Для решения этой задачи потребовалось много лет, однако теперь, наконец, появилась разновидность RDF, которая успешно проходит этот тест, а именно RDFa 1.1 Lite.

RDFa Lite — это упрощенная версия RDFa (RDF annotations). RDFa представляет собой механизм для кодирования полной модели данных RDF в рамках HTML и подобных словарей. Сложность модели RDFa несколько превышает пороговое требование "возможность изучения за один день", поэтому группа WHAT WG (которая создала HTML5) создала HTML-спецификацию под названием Microdata. Спецификация Microdata стала ядром Schema.org (см. раздел ), — инициативы по кодификации способов разметки данных в сети. Со временем спецификация Microdata получила статус W3C Working Draft (действующий проект)(см. раздел ), однако защитники RDF и RDFa считали, они смогли бы продвигать RDFa, если бы у них имелось подмножество RDFa, столь же простое как и Microdata. И вот, наконец, мы получили преимущества отработанной модели данных, но с простым синтаксисом.

В прошлом году основатели Schema.org провели семинар для сообщества специалистов по структурированным веб-данным. Я посетил этот семинар, на котором Бен Адида (Ben Adida), редактор спецификации RDFa, продемонстрировал нам работу, которую группа RDF Web Applications Working Group выполнила при создании RDFa Lite. Весьма положительные отзывы о предварительной версии этой спецификации вдохновили организацию W3C на интенсификацию дальнейших усилий в этой области. RDFa 1.1 Lite — это весьма лаконичный действующий проект (working draft) от организации W3C (вполне возможно, что к тому моменту, когда вы будете читать этот текст, этот проект уже превратится в официальную рекомендацию W3C).

Прочитав эту статью, вы узнаете о RDFa 1.1 Lite и сможете быстро приступить к созданию HTML-страниц, включенных в сеть данных. Предполагается, что читатель уже имеет представление о HTML.

Атрибуты для уточнения контента

Совместимость

Формат RDFa совместим со спецификациями HTML 4, HTML 5 и XHTML.

RDFa предусматривает разметку структурированных данных в рамках веб-сайта. Вы не сосредотачиваетесь лишь на том, как контент должен выглядеть с точки зрения пользователя. Вы можете пометить дату как дату, имя человека как имя человека, событие как событие, организацию как организацию и т. д. RDFa Lite редуцирует высокий уровень амбиций до простейших вещей, которые вполне способны работать: к HTML или к XHTML добавляется всего пять атрибутов. Машина способна с легкостью интерпретировать эти атрибуты, чтобы извлечь из веб-страницы полезные данные. Если говорить коротко, то это все.

В показан пример "чистого" HTML-кода для онлайновой статьи.

Листинг 1. Чистый HTML-код для онлайновой статьи

Web development > Technical library

An introduction to RDF by Uche Ogbuji, Partner, Zepheira.

Published: 01 Dec 2000

Summary: This article introduces Resource Description Framework (RDF),

Модель RDF, разработанная консорциумом W3C для веб-метаданных, использует язык XML в качестве синтаксиса для взаимного обмена. Важнейшая цель RDF состоит в упрощении работы автономных агентов, что очистило бы Интернет посредством совершенствования поисковых машин и сервисных каталогов. Для получения дополнительной информации об RDF прочитайте документ (developerWorks, декабрь 2000 г.).

В оставшейся части этой статьи аннотации HTML-кода в будут рассмотрены с целью демонстрации всех пяти атрибутов спецификации RDFa Lite: vocab , typeof , property , resource , prefix .

Листинг 2. HTML-код для демонстрации RDFa Lite

Tags for this article: introduction, rdf, tutorial.

This article"s text is suitable for a wide audience, with a Fog index of 10.2.

Атрибут vocab

В показано изменение элемента body с целью упаковки описания всей статьи.

Листинг 3. Использование атрибута vocab

...

Атрибут vocab готовит почву в RDFa Lite. Он указывает на словарь, который по умолчанию будет использоваться в аннотациях. В нашем примере используется словарь, соответствующий стандарту Schema.org, поэтому мы выбираем элемент типа wrapper (упаковщик), чтобы пометить его надлежащим образом. У вас нет необходимости использовать элемент body , однако вам следует использовать элемент, который упаковывает все аннотации.

Атрибут typeof

В shows the outline of a div to enclose the one article being described.

Листинг 4. Использование атрибута typeof

....

Атрибут typeof помечает свой элемент как описание или как представление экземпляра заданного класса. Посредством обозначения vocab , заданного стандартом Schema.org , этот элемент помещается в соответствующий контекст, в результате чего становится ясно, с каким определением "article" (статья) мы имеем дело. Article — это один из классов, специфицированных стандартом Schema.org. Каждое определение класса документировано, в том числе соглашения по его использованию и ассоциированные с ним свойства.

Атрибут property

В показан фрагмент, размечающий заголовок статьи.

Листинг 5. Использование атрибута property

An introduction to RDF

Атрибут property предоставляет свойство объекта, который только что был декларирован как объект Article стандарта Schema.org . Свойство name был задано для того, чтобы дать заголовок этому объекту Article .

В показаны первые три атрибута RDFa Lite.

Листинг 6. Три атрибута RDFa Lite

...

An introduction to RDF

...More information regarding this article, or even the content itself...

...

В демонстрируются способ, посредством которого RDFa сообщает показанную ниже информацию таким образом, чтобы ее смогла обработать машина.

Данный HTML-документ представляет собой статью, соответствующую спецификации Schema.org, с заголовком "An introduction to RDF" (Введение в RDF)

Более изощренные утверждения

Спецификация HTML уже предоставляет доступное для машинной обработки место для размещения заголовка статьи — в элементе head . Однако словарь Schema.org позволяет нам сообщить о статье гораздо больше информации, чем один лишь заголовок, в том числе конструкты, выходящие за рамки HTML (и действительно, на момент написания статьи этот словарь содержал 46 свойств). Даже в случае таких свойств, как заголовок, возможности HTML не всегда оказывались достаточными. Представьте себе, что у вас есть страница, включающая индекс статей, или начальная страницы с результатами поиска. Вам пришлось бы на одной HTML-странице описать несколько реальных статей. HTML не располагает никакими возможностями на этот случай, однако Schema.org позволяет нам иметь несколько элементов div — по одному для каждой статьи, на которую производится ссылка.

Атрибут resource

Если вы способны описать на одной странице несколько объектов, то становится важной возможность предоставить каждому из этих объектов соответствующий идентификатор. RDFa предоставляет для этой цели атрибут resource . В показан фрагмент, аннотирующий автора статьи.

Листинг 7. Атрибут resource

Uche Ogbuji, Partner, Zepheira. 01 Dec 2000.

Данный фрагмент добавляет информацию о том, что "Автор данной статьи — это человек по имени Uche Ogbuji, который является компаньоном в компании Zepheira". Обратите внимание на то, как p элемент был помечен в качестве описания нового объекта типа Person согласно Schema.org. Кроме того, элемент p имеет элемент property , который соединяет этот объект с объектом, заключающим в себе статью.

Атрибут resource предоставляет объекту, описанному в элементе p, идентификатор, который идентифицирует соответствующий фрагмент по отношению к URL-указателю самой страницы. Например, если эта страница находится по адресу http://www.сайт/developerworks/library/w-rdf, то теперь существует объект, который имеет идентификатор http://www..ogbuji.

Zepheira — это организация. В качестве дальнейшего развития этого примера мы можем выразить Zepheira как еще один вложенный объект, используя для этого класс Organization , описанный в спецификации Schema.org. RDFa позволяет нам аннотировать все, что мы считаем важным. В данном случае нас интересуют более подробные сведения об авторе, а не об организации, в которой он работает.

Атрибут prefix

Заключительный атрибут, описанный в спецификации RDFa Lite — prefix — используется для объединения нескольких словарей в одном описании.В показано, каким образом можно аннотировать индекс "читабельности" статьи.

Листинг 8. Атрибут prefix

10.2

Спецификация Schema.org не содержит свойства для индекса читабельности текста Gunning-Fog — в отличие от Freebase. Freebase — несколько более структурированная разновидность Wikipedia — управляет схемами и описаниями для широкого разнообразия объектов и типов объектов. Я задал префикс для ссылки на свойства согласно спецификациям Freebase, а не словарю Schema.org по умолчанию, а затем использовал этот префикс для текста, представляющего собой значение индекса читабельности для данной статьи.

Обобщающий пример

В сведены воедино все продемонстрированные к настоящему моменту элементы, а также добавлены такие элементы, как breadcrumb.

Листинг 9. Использование всех пяти атрибутов RDFa Lite

...

Web development > Technical library

An introduction to RDF

By Uche Ogbuji, Partner, Zepheira.

Published: 01 Dec 2000

Summary: This article introduces Resource Description Framework (RDF), developed by the W3C for Web-based metadata, using XML as an interchange syntax. RDF"s essential aim is to make work easier for autonomous agents, which would refine the Web by improving search engines and service directories. Author Uche Ogbuji gives an overview of RDF aspects from schemas to usage scenarios. The article assumes that you are already familiar with XML.

Tags for this article: introduction, rdf, tutorial .

This article"s texts is suitable for a wide audience, with a Fog index of 10.2.

...

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

Заключение

Помимо Schema.org существуют и другие словари, в том числе Dublin Core (имеющий базовую поддержку в RDFa) и Facebook Social Open Graph. Тем не менее, стандарт Schema.org в последнее время получил мощную поддержку, особенно с учетом своих выдающихся апологетов. Это новейшее достижение в длинном перечне событий в такой сфере, как оптимизация поисковых механизмов (search-engine optimization, SEO).

Вполне возможно, что идея SEO имеет преимущественно маркетинговый характер, однако она полностью базируется на таких концепциях совершенствования веб-технологий, как достижимость, чистая разметка и аннотирование страниц — везде, где это возможно, и с привлечением большего количества информации о фактическом значении контента. Такие достижения, как RDFa Lite, призваны разместить мощные возможности SEO в пределах досягаемости практически любого сетевого автора. Я надеюсь, что эта статья поможет вам изучить RDFa за один день и призывают вас немедленно приступить к аннотированию своих страниц.

Resource Description Framework (RDF) является стандартом W3C для описания сетевых ресурсов, таких как заголовок страницы, автору, дате изменения, содержание и информацию об авторских правах.

Вы должны иметь базовые знания

Прежде чем продолжить, вы должны иметь базовые знания о следующем понимании:

XHTML
Пространства имен XML

Если вы хотите изучать эти предметы во- первых, пожалуйста, посетите наш домашнюю страницу .

Что такое RDF?

RDF относится к Resource Description Framework (Resource Description Framework)
RDF является описание ресурса рамки для Web
RDF предоставляет модель и грамматику для таких независимых групп, которые могут обмениваться данными и использовать его
RDF предназначен для чтения и понимания компьютером
Цель RDF предназначен не появляться людям
RDF использует XML для записи
RDF является неотъемлемой частью W3C Semantic Web Activity
RDF является рекомендацией W3C

RDF - Примеры применения

Описание недвижимости торговые пункты, такие как цена и доступность
Описание графика Веб-событие
Для описания информации страницы, такие как содержание, автора и дату создания или изменения
Фотографии и описание рейтинга содержимого сети
Описание для поисковых систем
Описание Электронная библиотека