Modeling with RDF RDF and Tabular Data Consider the Product database relation ID Model No. Division Product Line SKU 1 ZX-3 Manufacturing support Paper machine FB3524 2 ZX-3P Manufacturing support Paper machine KD5243 3 B-1430 Control Engineering Feedback line KS4520 4 B-1430X Control Engineering Feedback line CL5934 Each row describes a single entity The type of each entity is the table name (Product) Give each row a distinct URIref The table gives us a locally unique identifier: the primary key (ID)
75
Embed
Modeling with RDF RDF and Tabular Data Consider the Product database relation IDModel No.DivisionProduct LineSKU 1ZX-3Manufacturing supportPaper machineFB3524.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Modeling with RDF RDF and Tabular Data Consider the Product database relation
ID Model No. Division Product Line SKU
1 ZX-3 Manufacturing support Paper machine FB3524
2 ZX-3P Manufacturing support Paper machine KD5243
3 B-1430 Control Engineering Feedback line KS4520
4 B-1430X Control Engineering Feedback line CL5934
Each row describes a single entity
The type of each entity is the table name (Product)
Give each row a distinct URIref
The table gives us a locally unique identifier: the primary key (ID)
To get a globally unique identifier, use the URI for the database itself
Say, http://www.acme.mfg.com
Use the prefix mfg:
For an identifier for a row, concatenate the table name (“Product”) with the unique key
Express it in the mfg: namespace
mfg:Product1, mfg:Product2, …
The column labels correspond to properties
For globally unique identifiers, use same namespace as for individuals
For local names, concatenate table name and column label
The situation is more subtle when info is merged from multiple sources each with its own inference engine
Most RDF implementations allow new triples to be asserted into the triple store
So an application can assert inferred triples
If those triples are serialized and shared on the Web,
another application could merge them with other sources and draw further inferences
Here the distinction between asserted and inferred might be too course to be useful
Suppose 1 info source provides a list of members of the class PassengerVehicle and another provides a list of members of class Van To find a list of all MotorVehicles , we use the inference rule for
subClassOf
We have a merged graph
The inferencing determines that both myVehicle and yourVehicle are members of the class MotorVehicle
Two fundamental components in this data integration example
1. A model that expresses the relationship between the 2 data sources Here the model consists of a single class having both the
classes to be integrated as subclasses This is represented by the single concept of subClassOf
2. The notion of inference Inferencing applies the model to the 2 data sources to
produce a single, integrated answer
When data seem disconnected, it’s often because some apparently simple consistency is conspicuously absent
RDFS and Meaning Modeling in RDF is about graphs—it creates a graph structure to
represent data
Modeling in RDFS is about sets
RDFS provides a way to talk about the vocabulary used in an RDF graph
It lets an info modeler express, relative to particular data modeling and integration needs, how individuals are related how properties used to define individuals are related to sets of
individuals etc.
RDFS is like other schema languages in providing info about how we describe data
But it differs from other schema languages in important ways
Consider document modeling systems
A schema language here (XML Schema) lets us express the set of allowed formats for a document
Can then determine (automatically) whether a given document confirms to the schema
A database schema provides type and key info for relations
A relation itself has nothing indicating the meaning of info in a given column or which column is used to index the relation
For OO programming systems, the class structure again helps organize the data
It not only describes the data but also determines, according to the inheritance policy of the language, what methods are available for a given instance and how they are implemented
This contrasts with databases and XML:
It doesn’t interpret the data but instead gives a systematic way to describe info and transformations for that info
In all cases, the schema is info about the data
The schema in RDF should help provide meaning to the data
The mechanism by which it does this is inference
Inference lets us know more about a set of data than what’s explicitly expressed in the data
It thus explicates the meaning of the original data
The additional info is based in a systematic way on patterns in the original data
RDFS provides detailed axioms that express exactly what inferences can be drawn from given data patterns
Most modeling systems have a clear distinction between the data and its schema
But many modern systems model the schema in the same forma as the data—e.g.,
The introspection API of Java represents the object models as objects
An XML Schema document is a well-formed XML document
For RDF, the schema language was defined in RDF from the start
All schema info in RDFS is defined with RDF triples
It’s thus easy to give a formal description of the semantics of RDFS:
Give inferences rules that work over patterns of triples
In RDF, everything is expressed in triples
The meaning of asserted triples is expressed in inferred triples
The structures that drive these inferences are also triples
So this process can continue as far as it needs to:
The schema info that provides context for info on the Semantic Web can itself be distributed on the Semantic Web
Can explicate the meaning of each RDFS resource by indicating what triples can be inferred in certain circumstances (defined by some pattern of triples)
Illustrate this with one of the most fundamental RDFS terms: rdfs:subClassOf
In RDFS, class membership is given meaning only when there are several classes and a known relation between them
That something’s a member of a class means it’s a member of any superclass Cf. the Type Propagation Rule
The various rules taken together give a way to express a variety of relations between classes and properties Such a collection of classes and properties gives a rudimentary
definition of a vocabulary for RDF data I.e., it defines a set of elements and the relationships of those sets to
The type info for Kaneda propagates in the expected way, giving
:Kaneda rdf:type :MajorLeaguePlayer .
This very simple interpretation of the subclass relationship makes it a workhorse of RDFS modeling
It’s like IF/THEN of programming languages:
IF something is a member of the subclass THEN it’s a member of the superclass
But nothing in RDFS corresponds to the ELSE clause
You can’t infer things from the lack of asserted membership
The RDFS Inference Patterns RDFS consists of a small number of inference patterns
Each provides type info on individuals in a variety of circumstances
Relationship Propagation through rdfs:subPropertyOf
The mechanism RDFS provides for talking about the properties that link individuals is based on an inference pattern defined using resource (keyword) rdfs:subPropertyOf
Terminology includes verbs as well as nouns
Many of the same requirements for mapping nouns from one source to another apply to relationships
Relationship brother is more specific than sibling
If someone is my brother, then he is also my sibling
The rule: For properties P and R, we have
If P rdfs:subPropertyOf R, then, if A P B, then infer A R B
Example A large firm engages a number of people in various capacities
and has a variety of ways to administer these relationships
Some are directly employed by the firm while others are contractors
Among the contractors, some are directly contracted to the company on a freelance basis, others on a long-term retainer, and still others contract through an intermediate firm
All these people can be said to work for the firm
To see how to model this in RDFS, first consider the inferences we should be able to draw and under what circumstances
Name the relationships between a person and the firm :contractsTo, :freeLancesTo, :indirectlyContractsTo, :isEmployedBy, :WorksFor
If we assert any of these properties about a person, we’d like to infer that he :worksFor the firm
And there are intermediate conclusions we can draw—e.g., Both a freelancer and an indirect contractor contract to the firm and
indeed work for it
All these relationships are expressed using refs:subPropertyOf