Import RDF screen in relationship module
In the beginning, there is the Node (Capital 'N'). The concept of a Drupal Node is a class, a superclass in fact. It is the prototype for all Drupal content types.
Each Drupal Content type - the built-in ones, the module defined ones, and the user-defined ones (through flexinode or CCK)
are subclasses of the basic Drupal node. They are definitions of the content that may be stored, but are not content themselves.
Flexinode node definitions can be looked at as subclasses of the type 'flexinode'. That all fits together nicely.
Only when content is created, content of a certain "Content Type" is made, do we end up with instances of the class (Small 'n' nodes). Pages are at one and the same time things of type {their content type} and of type {Node}. This is a form of inheiritance.
With this structure in mind, we can look at properties, and hence to relationship definitions. A basic node can have the usual properties : nid, title, owner, date, and usually body.
This can be expressed by saying the Node (superclass) CanHaveProperty "nid", "title", "owner" etc. Thus, when instances of nodes (instances of subclasses of Node) are created, these properties may have values. A node (instance) is an object with these values set.
(I won't go into the details of "must have" properties yet. It can be stated later, but for now we'll leave the definitions flexible)
Node content types usually add a few extra properties to the definition of a Node.
And individual node instances instantiate those properties with values.
So far, nothing at all tricky to anyone who's encountered object-oriented programming or set theory before. I've re-capped these basic concepts in order to move forward into the way we can state these rules - using relationships and RDF statements.
N3 format is one of several ways to notate statements. I'll use it here to write the statements, rules and relationships.
"A Node is a type of class" :
<#node> <#type> <#class> ."A node can have certain properties" :
<#node> <#canHaveProperty> <#title> . <#node> <#canHaveProperty> <#nid> .N3 syntax looks a little funny, but it's like this so as to allow for greater complexity and detail later...
<#page> <#subClassOf> <#node> .Here, the shorthand "subClassOf" is meant to represent the absolute definition of the concept of classes as defined by the W3C RDF specification. To be explicit, it can be expressed in N3 with a full URI:
<#person> <http://www.w3.org/2000/01/rdf-schema#subClassOf> <#node> .And there are a few short-cuts, multiple statements about the same object can be combined:
<#adam> <#type> <#person> ;
<#title> Adam ;
<#birthday> 8/9/1972 .
... And it's still a lot nicer than XML/RDF!
That's all we need to know about notation for now.
Many rules about what type of resource can have what type of property can now be expressed. Note that both 'classes' and 'instances' may end up on either side of the statements - as subjects or objects at different times.
Note also that the predicate in the middle is a URI/Resource itself
and may also have statements made about it as well as with it:
EG: The value of a 'title' is always a literal string (not a resource URI)
<#title> <#range> <#Literal>.The property 'title' itself has associated properties. In some ways this is a meta-statement - a statement about other statements. In other ways, it demonstrates that all statements are treated equivalently.
We wish to extend this structure to demonstrate that (nodes representing) people have relationships to other (nodes representing) people. As an implimentation of the FOAF specification, we'll impliment the relation "knows".
Key Point: Wherever possible, re-use existing specifications for terms. The point of having URIs as identifiers for every concept is that everyone who is expressing the same concept can be understood by anyone else who understands it.The term 'knows' as defined by FOAF is a relationship between a person and a person. This interpetation is different from "knowing" trigonometry or knowing the words to a song. To demonstrate this specificity, we can write it as foaf:knows or even http://xmlns.com/foaf/0.1/knows. But not for now.
Find and re-use schemas from your problem space. Mixing and matching from different sources is totally expected.
This is why we are using annoying long namespaces and not just a local vocabulary.
So. Lets say: The relationship "knows" applies to objects of type "person".
<#knows> <#domain> <#person> .Things that can be known are also persons.
<#knows> <#range> <#person> .And while we are at it, "knows" is a predicate stating a relation between two resources (known as an rdf:property)
<#knows> <#type> <#property> .
Having these rules set makes it possible for us to make statements like:
<#adam> <#knows> <#eve> .
Where does this get us?
In Drupal, using the relationship module, we can make exactly these statements.