Which node types (eg 'page', 'story', blog') can potentially have which relationships (eg 'seeAlso', 'isReplacedBy') is defined in several ways.
Firstly, the node type has to be configured to use relationships (at all). This is done in the admin/settings/relationship page. Doing this will ensure the 'Relationships and Metadata' table will show up as part of the node edit form.
enable relationships for 'page's
Note that target nodes are not required to participate in relationship management, but they can be linked to nonetheless.
The default relationships available to tag to nodes out-of-the-box will include all predicates that:
The most direct way of saying 'this node type can have this relationship' is by saying so directly, using a 'canHaveProperty' statement.
<#person> <#canHaveProperty> <#knows> .
Or using the logical inverse of canHaveProperty: 'domain'. Specific predicate terms are created and associated with this node type by setting the node type to be one of the valid 'domain's of the term.
<#knows> <#domain> <#person> .This is logically identical to the above statement, and should usually be evaluated the same.
OR an entire ontology, a collection of related logical terms, is imported and applied to the node type. This is achieved by making a 'canUseOntology' statement in the node type definition screen.
<#person> <#canUseOntology> <#geneology> .This method should be used when creating ontology plugins.
OR a node type inheirits the right to participate in a relationship. EG if the settings define that all node types may have an assigned 'author' relationship, then pages, being subclasses of nodes, will be able to have that relationship.
<#page> <#subclassOf> <#node> . <#node> <#canHaveProperty> <#author> . => <#page> <#canHaveProperty> <#author> .
Inheiritance need not be from locally-defined classes. Creating a 'personal profile' page type under CCK, then stating that this definition is a subclassOf the FOAF 'Person' class will allow your new page to assume all the logical structure of a FOAF 'Person' and the properties that come with it.
<#person> <#subclassOf> <#foaf:Person> .This method may have unpredictable side-effects.
For illustration, we'll just create one relationship and assign it using method #1.
Predicate terms are created and edited via the admin/relationship/term pages. Create one now called 'seeAlso'
When a new predicate term is created, by default it has no restrictions. It can represent any number of links between anything and anything. This is fine and dandy, but it will make more sense to limit it a bit.
On the term edit page, set the range of seeAlso to 'Node'. This will state that only nodes (all nodes) can be related to. The technical term 'range' is aliased to the nice label Can Have Value Of Type, because it makes better English to read.
In the content type settings admin/settings/content-types
,
configure the node definition.
Add a statement that:
<#page> <#canHaveProperty> <#seeAlso>
Using the relationship manager of the node class, we can list the properties that the node instances may posess. Effectively like adding CCK fields. Note that this interface (and the data management) is identical for predicate terms, node classes, content nodes, ... all resources in fact!
Assign the 'seeAlso' predicate to the 'page' node type
It was equally possible to set the domain of this term to the node type we want, via the term edit screen, but that's conceptually backwards if you are used to editing flexinodes or CCK types. The effect is the same to the logic engine - visit the predicate term edit page again and you'll see a list of nodes it's assigned to apply to.