Copyright ©2001 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
RDF Primer is a non-normative document intended to provide an easily readable description of the facilities defined by the RDF Specifications, and is oriented towards quickly understanding how to create RDF metadata using XML. @@ RDF1 @@, @@ RDF2 @@, @@ RDF3 @@ provide the complete normative description of the RDF specifications. This primer describes the language features through numerous examples which are complemented by extensive references to the normative texts.
This is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use it as reference material or to cite as other than "work in progress".
1) Introduction - Overview of SW (the what, why) / Overview of RDF (the how) - Self Describing Web - Web of Trust Suggestion: In Section 1, I think we want to make sure that people see the motivation for RDF somewhat independently of the "Semantic Web" (the "S word" sometimes turns people off, I find). That is, we need something like RDF for various practical reasons, which happen also to be the motivation for "the Semantic Web"." (frank) 2) Basic Concepts: @@ e.g. The Card Catalog @@ 2.1) The @@ e.g. Card Catalog @@ Schema Note: Note sure of the specific example, but I find it nice to start out with examples to grab the attention of the reader (the who) Another examples might be Routing as suggested by Martyn 3) Identification: Uniform Resource Identifiers (URI) 4) Extensible Markup Language (XML) 5) Resource Description Framework (RDF) 5.1) Goals - Self Describing Web - Data Aggregation - etc. 5.2) Note: The thought here is to partition up RDF in terms of manageable modules the reader would be able to understand and describe each modules, their capabilities, and examples. @@ show how they can be mixed and matched (e.g. lego's @@) - Basic Data Model - Typing System - Collections - Reification - Light Weight Ontology Support - @@ Ontology Language (Web Ont?) @@ - @@ Roll your own (DAML?) @@ 6) Examples Note: Goal here is to step to 2 different individuals through the creation of schema and instance data. And then in example 3, show how these can be combined/aggregated to provide something that is much than the sum of the parts. - Example 1 - Example 2 - Example 3 7) Conclusion Note: future of the web, how RDF provides the basis for this, etc. etc.
Note this is not a complete list of potentially useful documents, but rather a starting point
This document, RDF Primer, provides an easily approachable description of the RDF language, and should be used alongside the formal descriptions of the language contained in @@ RDF1 @@, @@ RDF2 @@, @@ RDF3@@ . The intended audience of this document includes application developers whose programs read and write RDF metadata, and metadata authors who need to know about the features of the language. The text assumes that you have a basic understanding of @@ RDF1 @@, @@ RDF2 @@, @@ RDF3@@ , XML 1.0 and XML-Namespaces. Each major section of the primer introduces new features of the language, and describes those features in the context of concrete examples.
Section 2...
Section 3...
Section 4...
In addition to the sections just described, the primer contains a number of appendices that provide detailed reference information on simple types and a regular expression language.
The primer is a non-normative document, which means that it does not provide a definitive (from the W3C's point of view) specification of RDF. The examples and other explanatory material in this document are provided to help you understand RDF, but they may not always provide definitive answers. In such cases, you will need to refer to the RDF specification, and to help you do this, we provide many links pointing to the relevant parts of the specification. More specifically, RDF constructs mentioned in the primer text are linked to an glossary located at the end of this primer. The glossary contain links to the relevant sections of RDF specifications.
@@ extracted from The Semantic Web In Breadth and still require editing @@
Whenever you want to talk to someone about something, you use some sort of identifier. "The North Star" "The strange man at the grocery store" "Those really sour candies Bob always eats" However, when you want to be as exact as possible, you use a name. "Polaris" "Johnathan Roberts" "Mega Warheads"
On the Web, instead of giving something a name, we give it a URI. Anything that has a URI is said to be "on the Web" and we can give anything a URI: you, the book you bought last week, the fly that keeps buzzing in your ear and anything else you can think of -- they all can have a URI.
The URI is the foundation of the Web. While nearly every
other part of the Web can be replaced, the URI holds the rest
of the Web together. You're probably already familiar with
one form of URI: the URL or Uniform Resource
Locator. A URL is the address that lets you visit a
webpage, like: http://www.w3.org/Addressing/. If
you break it down you can see that
a URL lets your computer locate a specific resource (in this
case, the W3C's Addressing website).
In addition to URLs, there are other
forms of URIs. For example, mid: URIs identify email
messages but they aren't able to locate a copy of the message
for you.
URIs are decentralized -- no one person or organization controls who makes them or how they can be used. You don't need any authority or permission to make a URI for something. You can even make URIs for things you don't own, or abstract concepts that don't even physically exist. While this flexibility gives URIs a lot of power, it also brings with it a lot of problems. Since anyone can create a URI, we will inevitably end up with multiple URIs representing the same thing and we have no way to figure out whether two URIs are definitely the same. And we'll never be able to say with certainty exactly what a certain URI means. However, these are the tradeoffs that were made so that something the scale of the Semantic Web could be built.
Common practice for giving something a URI is to create a web page that describes the object and explains that the URL of that webpage represents it. For example, I created a URI for my copy of Weaving the Web. Now I have said that that specific URI no longer represents the web page you get back when you visit it, but instead the physical book that it describes.
This is an important fact to understand. URIs are not recipes describing to your computer how to get a specific file. Instead, they are names, which may or may not contain one way for your computer to get more information about them. Other ways to find out information about a URI are developing and ways to say things about URIs are an important part of the Semantic Web.
@@ extracted from The Semantic Web In Breadth and still require editing @@
XML was designed to be a simple way to send documents across the Web. It allows anyone to design their own document format and then write a document in it. These document formats can include markup to enhance the meaning of the document. If we include enhanced meaning in our documents, they become much more useful. Instead of only being able to be used by one program (a web browser, for example) they can be used by many programs, each only using the markup it understands and ignoring the rest. Even better, each program is free to interpret the markup in the way that's best for it. For example, in a document where words are marked as "emphasized" a web browser might display them in bold. On the other hand, a voice browser (which reads web pages out loud) my read them with extra emphasis. Each program is free to do what it feels is appropriate.
Here's an example of a document in plain text:
I just got a new pet dog.
And marked-up in XML:
The items that I added to the XML version are called tags,
because they are like attaching descriptive "tags" to certain
portions of the document. A full set of tags (both an opening
and closing tag) and their content is called an element and
descriptions like href="http://aaronsw.com/" are
called attributes.
With XML Namespaces we give each element and attribute a URI. This way, anyone can create their own tags and mix them with tags made by others. Since everyone's tags have their own URIs, we don't have to worry about tag names conflicting. XML, of course, lets us abbreviate and set default URIs so we don't have to type them out each time: