From W3C Wiki

The RDF Schema (RDFS) specification defines a term called rdfs:seeAlso which relates a resource to another resource "that might provide additional information about the subject resource." This grants us NetworkedData.

The RDFS spec tells us:

A triple of the form: S rdfs:seeAlso O
states that the resource O may provide additional information about S. 
It may be possible to retrieve representations of O from the Web, 
but this is not required. When such representations may be retrieved, 
no constraints are placed on the format of those representations.

The rdfs:domain of rdfs:seeAlso is rdfs:Resource. 
The rdfs:range of rdfs:seeAlso is rdfs:Resource.

There has been some discussion in the RDF Interest Group, FOAF developers list and elsewhere about how exactly this is supposed to work. Note that these informal notes do not change the meaning of the spec, here are some observations that may help.

Is it "wrong" to build applications that expect the value of an rdfs:seeAlso property to be a document that parses as RDF/XML?

It is reasonable to expect many (probably even "most") rdfs:seeAlso properties to reference to RDF/XML documents. There are a number of considerations that went into the design of rdfs:seeAlso which argued against the spec making a stricter assertion about the range of the rdfs:seeAlso property. Web applications which expect all rdfs:seeAlso properties to be de-referencable and parseable as RDF/XML are certain to be frustrated on occasion, and hence risk being fragile and unpredictable in their operation.

  • dereferencing is a privilege not a right: many resources (even if named with http: URIs) will be inaccessible (password protected, temporarily offline etc), missing (404'd), broken etc.
  • RDF/XML is just one encoding of the RDF data model (triples/graphs); other encodings (N3, for example) are possible; further additional encodings are anticipated
  • RDF/XML in its current form is W3C's first Semantic Web language for machine-processable information. There may turn out to be successors, eg. a hypothetical "RDF 2.0" (note that no such work has started).
  • RDF and non-RDF information may be made available in ways that make it hard to distinguish their identifiers
    • RDF/XML can be stored inside non-RDF (and non-textual) document formats (eg. PNG, JPEG, PDF etc., eg. using Adobe's XMP approach).
    • RDF/XML markup can be mixed inside other XML document formats (eg. XHTML, SVG)
    • RDF/XML documents may be made available via content-negotiation from same URI as non-RDF versions
  • the notion of 'providing more information about' is intrinsically vague (yet useful); it cannot usefully be reduced to something as simplistic as 'encodes RDF statements whose subject is this resource', since information about a closely related resource is still typically relevant and useful.
  • the exact content of the referenced document might change radically from day to day or be generated based on context (identity, credentials, characteristics of requesting party).

Taking into account these and related considerations, the RDF Schema (1998-2000) and RDF Core Working Groups decided not to specify the rdfs:seeAlso property further than noting that it references another resource that "might provide further information".

It should be remembered, however, that this wording is presented within the context of the RDF project, whose premise is that we can and should move towards the deployment of machine-readable information on the Web.

  • RDF provides a data model and syntax for making such related information available
  • yes, it is possible there may be future syntaxes
  • ... or even future machine-readable information formats
  • ... or that such machine-readable information may be embedded inside other markup or file formats

All such disclaimers aside, it should be clear from rdfs:seeAlso being part of the RDF framework that RDF as a whole is a project which encourages information to be encoded in RDF wherever possible. The formal definition of rdf:seeAlso is couched in very neutral terms, allowing for a wide variety of deployment practices to be experimented with. You could reference a JPEG or PDF or XHTML document with rdfs:seeAlso. However to do so and not have the referenced content contain (ideally in RDF/XML but at least in some form) machine-readable information would be dissapointing. Web applications should expect, on occasion, to be dissapointed.

When you want to be very clear in markup that you are using an rdfs:seeAlso property to reference a document that is available in RDF/XML format, it is possible to do this using additional markup, for example drawing upon the Dublin Core vocabulary. Many RDF applications (crawlers/spiders etc.) are likely to be optimistic and try to find some way of retrieving or extracting RDF from anything that is referenced in an rdfs:seeAlso. Others will be more cost conscious (eg. because of bandwidth, processing or storage concerns) and look for a combination of local (RDF statement) and perhaps remote (HTTP HEAD etc.) metadata to help determine whether a machine-readable version of a resource is available.

Here is an example of using rdfs:seeAlso with Dublin Core's dc:format property to indicate that a document is in RDF/XML format:

    <rdf:Description rdf:about="">

Note that this claims the remote document is in RDF format. It does not guarantee that it is currently available, that it isn't password protected, etc etc. Web applications (RDF or otherwise) need to be robust in the face of such inevitable uncertainties. RDF Schema's rdfs:seeAlso property provides a valuable hint that can be used to cross-reference RDF data to form a Semantic Web of interconnected claims about the world. The formal semantics of this property have been designed in a way that will allow it to serve us even as our machine-processable data formats evolve. On occasion it may be that an rdfs:seeAlso reference cites a document for which no machine-readable variant can be extracted. This, from the perspect of an RDF application which is hoping to find RDF statements, might be treated similarly to scenarios in which the document was in RDF/XML but contained no RDF statements, or in which it was illformed RDF/XML.