Semantic Web Hints And Tips


It is important that on the Semantic Web, people produce data that is clean and interoperable. Some RDF techniques can currently only be learned through the RDF community, through hours of research, or through implementation experience, so this is an attempt to gather some useful but quick hints and tips into one place.

This is being developed as a collaborative project: if you have comments or additions, please send them in! You can either a) edit the Wiki page SemanticWebTips (if you've not used Wiki before, try WikiWikiWebFaq), or b) send comments directly to the editor at [], CCing the publically archived [] list.

Table Of Contents

URI Hints and Tips

All things on the Semantic Web are resources, and all resources may be identified by URIs. To create stable applications on top of the Semantic Web, you need to choose good URIs, similar to needing to choose good URLs for the "Web", except that the need for stability is even more important.

Ensure that URIs used in your applications are persistent.
If you don't have a domain name that you think you're going to keep, consider using a tag: URI, or something similar.
cf. Cool URIs Don't Change
Use URIs that contain as little information as possible.
For example, avoid URIs with file extensions. The Semantic Web is media independant, so using file extensions may decrease the persistence of a URI.

RDF Hints and Tips

When possible, use rdf:about rather than rdf:ID
Your data will be able to be stored locally then, and will port much easier.
For example, if you use: <rdf:Description rdf:ID="myProp"> in the file is stored at "", then the ID resolves to "". However, if this is then moved onto a local filing system, the URI might change to "file:///c:/blargh.rdf#myProp".
Use any method to create RDF files, and then convert them to XML RDF later on.
If need be, model your languages using a simple notation, and then convert later. For example, by using Notation3 or NTriples, you can increase your productivity. Some people prefer to use graphical interfaces than text, which is also acceptable.
Validate your XML RDF.
Invalid XML RDF isn't machine readable, and is therefore often worthless for its main task (a machine readable RDF interchange format) without some needless human intervention first. Checking code is advisable whenever possible. For example, you should make sure that your authoring tool is producing valid XML RDF, etc.
Try using the W3C's RDF Validation service.

RDF Schema and RDF Model Hints and Tips

Make use of rdfs:label
Don't assume, for example, that processors will use the string after the last non-XML-names character in the URI as a label. Always provide a label for terms.
Use rdfs:isDefinedBy and describe your schema
Providing a link to a description of the schema wil let developers know what its purpose is.
State all important information explicitly.
For example, state all ranges and domains explicitly. Remember: humans can often do guesswork, but machines can't. Don't leave important information out!
Don't include unnecessary data.
By adding data such as x = x, or links to other schemata that aren't used, or don't have a chance of interoperating, you're just wasting space, and adding to people's confusion. This is a caveat to the above point.
Don't create over-constrained, brittle models; leave some flexibility for growth.
For example, use DAML restrictions (try: daml-walkthru) instead of ranges and domains where appropriate, because these are less restrictive (even though they are called restrictions!), and make your ontology more extensible.
Provide for both humans and machines.
At this stage in the development of the Semantic Web, more people will be coming across your code than machines, even though the Semantic Web is meant for machines. Don't forget to add prose, e.g. using rdfs:comment for each term invented.
Make use of other people's terms.
Using other people's schema terms, or providing relationships to them, helps to promote the level of data interchange on the Semantic Web, in the same way that HyperText links built the common World Wide Web.
When using a list, be aware that it is exhaustive
For example, if you say that you have a brother called Jon, and a brother called Paul, people cannot test whether you have an extra brother or not. If, on the other hand, you make a list (cf. lists in DAML) out of your brothers, then that list is exhaustive: people can infer that if a person is not in that list, then it is not one of your brothers.
q.v. Dan Connolly's discussion of this on #rdfig.

With thanks to William Loughborough for the countless "terse guideline" efforts, and Dan Brickley, Dan Connolly, Libby Miller, and Eric Miller for suggesting the guidelines and other improvements.

Sean B. Palmer