Resource Description Framework

ResourceDescriptionFramework is a graph-based model for describing Internet resources (like web pages and email messages), and how these resources relate to one another. It can be considered as a means of representing a SemanticNet. It can be represented in a number of ways, using ExtensibleMarkupLanguage or RdfTriples. See PracticalRdf for a discussion of the alternatives. Part of the SemanticWebLayerCake described in the ExplorersGuide (to the SemanticWeb).

More information on RDF is available at http://www.w3.org/RDF/.

A model for metamodel that ExtensibleMarkupLanguage is not good for
- TimBray article at http://www.xml.com/lpt/a/2001/01/24/rdf.html

The EswWiki is all about the SemanticWeb and RDF: http://esw.w3.org/topic/FrontPage

How is this related to RichSiteSummary (RSS)?

See http://www.xml.com/lpt/a/2002/12/18/dive-into-xml.html

"RSS is an acronym for RichSiteSummary and also for RdfSiteSummary and they aren't the same thing. Do you agree?" -- PaoloCastagna

Different forks of the same product; see link above and RssFeeds.

Moved from RdfPrimerOutline

A document being done by SeanPalmer and AaronSwartz.

Sales Pitch


        Narrative: Boss says we need an RDF export for our sprockets right away. 

        Why should I be using RDF anyway? What's this document going to tell me?

Right on! Wait a sec... what's RDF?


        Introduction to basics of RDF.

What's this Resource thing?


        Introduction to URIs and Resources.

But Bob says that's what XML is for!


        Introduction to uses of XML and self-describing documents.

So let's write some RDF...


        Writing out information and data into RDF formats.

Where do I go from here?


        RDF is developed by the W3C, but there's a large independent 

        community, lots of apps and implementations. (Lots of pointers 

        to related material.)

N.B. From here on down, it would be suitable to segue into the RDF Cookbook stuff; once they are able to deal with rudimentary serializations concepts, it should be a simple matter of guiding them through the rest.


        - Introduction to developing schemas.

        - More advanced stuff with DAML and WebOnt.

        - Proof and digital signatures.

Online Query example (uses PrologLanguage) - see http://www.w3.org/1999/11/11-WWWProposal/atagdemo.

RDF is generally loaded into what SemanticWeb folk call a "TupleStore."

Around here, it seems to be called a "TupleSpace." - No, in fact a TupleSpace is something quite different, to do with sharing memory between different computer processes. -- JohnFletcher

Basically, a TupleStore is a gigantic graph. See RdfTriples.

RDF describes a graph. The graph consists of nodes connected by edges. When you describe the graph, you do it in triples. That is, you do it like this: (Node A)----(is connected by edge E)----(to Node B). See? Three things, making a triple. "A,E,B." It's also called a tuple.

Together, a bunch of triples/tuples describe a graph.

ALL data, in the entire world, can be described with a graph. That is: a graph is the most generic data structure in the world. Think about it: All data represents stuff connected to other stuff. A graph isn't necessarily the most efficient way to do it, but it's a pretty generic way to do it.

Why is RDF important?

Because it's easy to merge.

If you have two graphs, it's easy to automatically snap them together.

Why is merging data together important?

I haven't seen the canonical reasons "why," but here are some reasons.

Fabrication: Lots of people can describe the little bit that they know, and then it can automatically be hooked up together. (Sort of like the WorldWideWeb!)
Extension: If someone made some data, and you wanted to add something to it, you can ask them to do it, without requiring something of them. (Without going to their meetings, and trying to convince them to extend their data format.)
Partial Description: If you have a program that can only give some necessary details, and another program gives the other necessary details, then you can merge them together, and then perhaps you will have all the details you need.

For instance, RSS v1 data is in RDF. If you want to extend the information there, you can just extend it with RDF. It'll "just work." Anything that knows how to interpret your additional graph nodes will be able to figure out what's going on. Anything that doesn't will (if it's reading the RDF right) just ignore it.

-- LionKimbro

Weaknesses:

Lower-arity predicates: a proposition is a predicate of zero-arity, and there are a great many predicates of arity one. These can be represented in RDF easily enough by making one of the objects blank or 'TRUE', or using 'predicate.APPLIES_TO.subject'. However, none of the options are exactly natural.
Higher-arity predicates: many facts cannot readily be described by a simple pair of objects (e.g. 'likes_more_than(A,B,X) for 'A likes X more than B'). One can force higher-arity predicates by essentially currying the missing objects into the predicate (e.g. likes_X_more_than(A,B)), but doing so is both unnatural and a source of significant redundancy.
Cannot represent confidence (or, more accurately, the lack thereof), contingency (if A.Q.X is true then B.R.Y is true), or probability (A.Q.X has a P% probability of being true... not all that useful without contingency), volatility (I know it's true now, but... look again in 10 seconds), etc.
Abstraction and construction of predicates and inference rules: one cannot relay (at least directly in the graph) the abstraction of facts about predicates (e.g. "fact: forall predicate pairs A,B (<- denotes abstraction) that meet the second order logic requirements P(A) and Q(B) (<- contingency), an additional fact holds with 98% confidence: R(A,B)"). RDF is incapable of supporting much by way of meta-knowledge or rules of inference, both of which are necessary for it to extend naturally into a 'Knowledge' system (one capable of making predictions or discovering new facts rather than just representing data). (In my own study, I've discovered that meta-data and inference rules should be stored directly with the data because, in predictive or knowledge systems, the inference rules are just as subject to change AND use in the production of more inference rules as the other parts of the data.)
Open-world logic: In an open world, enough things are simply unknown that it's unreasonable to assume that not knowing it makes it false. Rather, one must explicitly track and store what they know is untrue: NOT(A.Q.X). The absence of information should result in 'unknown', not 'false'. RDF provides no field for indicating falsehood of a proposition/ RDF-triple. Again, it can be curried into the predicate (A.NOT_Q.X), but that is once again increasing redundancy and such (all the same problems as higher-arity predicates).

Like everyone else, I wrote a brief introduction to RDF [http://slashdot.org/~Quantum%20Jim/journal/94721]:

A Brief Introduction to the Resource Description Framework

Note: The following is a draft. Will revise and webify. ASCII art is formatted for 80 character lines.

Definitions

RDF is a language framework for describing directed graphs. First, some definitions:

A directed graph is a bunch of nodes connected by arrows.
The node at the beginning of an arrow is called the subject.
The node at the end of an arrow is called the object.
The arrow is called the predicate.
The whole thing is called a statement.

Example Graphs in Pictures

Here's a graph composed of only one statement:


        -----------   predicate    ----------

        | subject |--------------->| object |

        -----------                ----------

A subject node for one statement can be the object node of another statement:


        -----------   predicate    -----------   predicate2    -----------

        | subject |--------------->| object1 |---------------->| object2 |

        -----------                -----------                 -----------

Node and Arrow String Values

Now each node can have a string value:

It could have no string value; these nodes are called blank nodes.

It can also have a URI value; a URL is an example of an URI. In fact, every "node" with the same URI value is actually the same node (i.e. they are not separate nodes).

Objects can also be any arbitrary string - including the empty string ("") - but subjects can only be URI strings. These types of objects are called literals.

Note that every predicate MUST have a URI value; they can't be blank or arbitrary strings. It is also a VERY BAD IDEA to let predicates end with anything other than the characters a-z, A-Z, or 0-9 (that is, the end of the uri SHOULD be a valid xml name).

URI Examples

Here are some examples of URIs that could be a subjects, predicates, or objects. There is no way of knowing in isolation which is which. Each URI is DIFFERENT (even if they point to the same thing on the web).

http://example.com/subject

http://example.com/subject/index.html

http://example.com#predicate

file:///C:/Files/old/Video%20Game/mario.jpg

http://www.google.com/search?q=mario

If the URIs are all predicates, then 1, 3, and 5 are formatted best. Here are some real-world examples of predicates:

Here are some example strings that could be literals:

http://purl.org/dc/elements/1.1/creator
Mary had a little lamb
HTML is cool
47

Note that predicates can be objects. Thus RDF is capable of representing second-order-logic statements.

Datatypes

Literals can also have a property called its datatype. For example, the literal string "47" is also an integer, so it could be described by a datatype that means integer. This isn't required, of course, and many literals have no defined datatype.

The datatype is like a predicate and can only be a URI. Here are some real-life examples of datatypes:

Review of Values of Nodes and Arrows

In review:

A subject can either have:
- No string value.
- URI string value.
A predicate MUST have ONLY a:
- URI string value.
An object can either have:
- No string value.
- URI string value.
- Literal string value.
A literal object can optional have:
- A datatype
A datatype MUST have ONLY a:
- URI string value.

Graphs as Databases

Graphs can be thought of as collections of statements, and statements can be thought of as subject/predicate/object tuples. I tend to think of statements as English sentences and graphs as paragraphs or stories. The analogy holds up pretty well.

Graphs can also be looked at as tables in a database. Here's an example (First set is the format):


        Subject

        Predicate

        Object

        (Datatype) .


        http://example.com#subject1

        http://purl.org/dc/elements/1.1/creator

        "Jimmy"

        http://www.w3.org/2001/XMLSchema#string .


        http://example.com#subject1

        http://purl.org/dc/elements/1.1/creator

        "John" .


        http://example.com#subject1

        http://purl.org/dc/elements/1.1/creator

        http://example.com/subject2 .


        http://example.com/subject2

        http://purl.org/dc/elements/1.1/creator

        "Jimmy"

        http://www.w3.org/2001/XMLSchema#string .

Conclusion

There's a lot more, but these are the basics.

-- JimmyCerra

I soitenly hope this is ain't no secret attempt to resurrect JobControlLanguage (JCL). -Curly

It's not. The resources are not a machine resources needed but domain resources on offer. The resource description is metadata that describes data and services on offer by a domain. -- MartinSpamer.

CategoryFramework CategoryXml CategoryIdeaForm CategorySemanticWeb