Semantic Web

RDF Profiles

Buzzword.org.uk Draft XX October 2009

This version:
http://buzzword.org.uk/2009/profiles/spec-XXXXXXXX
Latest version:
http://buzzword.org.uk/2009/profiles/spec
Editor:
Toby Inkster

Abstract

This document describes a technique for creating profiles of RDF — that is, dialects of RDF that datasets can be checked against and judged to be conforming or lacking.

The primary use case is for expressing application-specific requirements and checking input data against those. For example, an application may may be written for which it is very important that all foaf:Person resources must have a foaf:name property. A profile can be written for that application, which specifies that foaf:name is a required property of all foaf:Person resources. Datasets are then judged as non-conformant to that profile if they mention a resource having an rdf:type of foaf:Person but no foaf:name.

RDF Profiles are designed in such a way that it's possible for multiple profiles to be written that each define different requirements upon the same vocabulary terms.

Status of this Document

This document is published by buzzword.org.uk, a web site that hosts various specifications, articles and tools of use to web publishers. This is not a W3C recommendation. It is not even a buzzword.org.uk recommendation yet.

The author welcomes feedback on this draft.

Licence

This document is available under a licence which allows the creation of derivative works under certain conditions. For the purpose of licensing, implementations of the ideas considered in this specification shall not be considered derivative works.

Table of Contents

@@TODO

1. Profiling is a 4-Tuple Problem

This section is informative.

Checking the conformance of a dataset requires looking at a bunch of rules. Each rule consists of:

  1. The profile being checked against.
  2. The type of object being checked.
  3. The property of the object being checked.
  4. The type of restriction/requirement being checked.

For example, if we're checking a description of Alice against Bob's profile; and Bob's profile only stipulates that all people have names, then the rule can be thought of as:

  1. Bob's profile.
  2. foaf:Person.
  3. foaf:name.
  4. It's required.

Representing 4-tuples is not one of RDF's strongest points, though there are various ways it can be done. One of the easiest is to consider Bob's profile to be a named graph. This works, but requires stepping slightly outside the normal RDF model. We want RDF Profiles to fit strictly into the RDF model, so we discard this solution. Reification is another option, but would result in far less readable profiles.

The solution is somewhat unusual, and while quite elegant, probably requires some explanation, as it will be unfamiliar to most people. The solution is that the profile, as well as defining a set of rules for datasets, also defines the language used to express these rules.

Let's see what this means in practical terms. Rather than a profile defining a rule like this, which would not be globally true (i.e. it might be true in Bob's profile, but not in Carol's profile):

foaf:Person  ex:hasRequiredProperty  foaf:name  .

It defines it like this:

ex:hasBobsRequiredProperty ;
	a rdf:Property ;
	rdfs:domain rdfs:Class ;
	rdfs:range rdf:Property ;
	rdfs:comment "Indicates the resources typed with this class require this propery to conform to Bob's profile."  .
	
foaf:Person  ex:hasBobsRequiredProperty  foaf:name  .

This is the approach I've taken for RDF Profiles. It takes a few moments to absorb, but results in a flexible system, with fairly readable profiles.

However, the syntax can be made far simpler than above.

2. Defining a Profile

This section is normative.

Here is an example of defining a Bob's RDF Profile:

@prefix rdfs:      <http://www.w3.org/2000/01/rdf-schema#> .
@prefix profiling: <http://ontologi.es/profiling#> .
@prefix bobprof:   <#> .

<> a profiling:Profile ;
	rdfs:label             "Bob's RDF Profile for FOAF and Dublin Core" ;
	profiling:required     bobprof:bobRequires ;
	profiling:recommended  bobprof:bobRecommends ;
	profiling:optional     bobprof:bobSuggests .

Introducing a little terminology, the three properties bobprof:bobRequires, bobprof:bobRecommends and bobprof:bobSuggests are referred to as profile defined properties (PDPs).

To simplify setting up the PDPs, this document provides a copy-and-paste template. It is a good idea to use this as-is without making any changes. The rest of this document assumes that you have used it as-is.

2.1. Template Profile

@prefix rdfs:      <http://www.w3.org/2000/01/rdf-schema#> .
@prefix profiling: <http://ontologi.es/profiling#> .
@prefix :          <#> .

<> a profiling:Profile ;
	profiling:required     :required ;
	profiling:recommended  :recommended ;
	profiling:optional     :optional ;
	profiling:forbidden    :forbidden ;
	profiling:single       :single ;
	profiling:multi        :multi ;
	profiling:range        :range ;
	profiling:type         :type ;
	profiling:comment      :comment .

You should also provide a name (rdfs:label) for the profile, and may also want to include foaf:maker, dc:created and dc:modified.

3. The Meaning of a Profile

This section is normative.

3.1. Required Properties

A profile may assert that a particular property is required (in the RFC 2119 sense) for all resources of a particular class in a conforming dataset. As an example, a profile may assert that all foaf:Person instances must have a foaf:name:

foaf:Person :required foaf:name .

Tools checking a dataset must issue an error message and declare the dataset to be non-conformant to the profile if the following query produces any results:

SELECT ?profile ?dataset ?instance ?property
WHERE
{
  GRAPH ?profile
  {
    ?profile profiling:required ?required_pdp .
    ?class ?required_pdp ?property .
  }
  GRAPH ?dataset
  {
    ?instance a ?class .
    OPTIONAL { ?class ?property ?value . }
  }
  FILTER( !bound(?value) )
}

3.2. Recommended Properties

A profile may assert that a particular property is recommended (in the RFC 2119 sense) for all resources of a particular class in a conforming dataset. As an example, a profile describing input to an e-mail tool might assert that all foaf:Person instances should have an e-mail address (foaf:mbox):

foaf:Person :recommended foaf:mbox .

Tools checking a dataset should issue a warning message if the following query produces any results. Such results on their own however do not make a dataset non-conforming to the profile.

SELECT ?profile ?dataset ?instance ?property
WHERE
{
  GRAPH ?profile
  {
    ?profile profiling:recommended ?recommended_pdp .
    ?class ?recommended_pdp ?property .
  }
  GRAPH ?dataset
  {
    ?instance a ?class .
    OPTIONAL { ?class ?property ?value . }
  }
  FILTER( !bound(?value) )
}

3.3. Optional Properties

A profile may assert that a particular property is optional (in the RFC 2119 sense) for all resources of a particular class in a conforming dataset. Any property not explicitly required, recommended or forbidden should be considered optional — this is the default. An explicitly listed optional property may be a hint that an application consuming datasets which conform to this profile will process triples using the property is some way that might be vaguely interesting.

Software checking datasets against profiles may take some action based on the use of optional properties, but is not recommended to do so. These hints are primarily useful for humans reading profiles, or documentation generated from from profiles.

3.4. Forbidden Properties

A profile may assert that a particular property is forbidden (in the RFC 2119 sense) for all resources of a particular class in a conforming dataset. These may be useful to flag up inappropriate use of properties.

Tools checking a dataset must issue an error message and declare the dataset to be non-conformant to the profile if the following query produces any results:

SELECT ?profile ?dataset ?instance ?property
WHERE
{
  GRAPH ?profile
  {
    ?profile profiling:forbidden ?forbidden_pdp .
    ?class ?forbidden_pdp ?property .
  }
  GRAPH ?dataset
  {
    ?instance a ?class .
    ?class ?property ?value .
  }
}

3.5. Single Properties

A profile may indicate that conforming datasets should not provide multiple values for a property for any resource of a particular class. For example:

ex:Wine :single ex:vintage .

Note that the above example does not imply that ex:vintage is a required property — just that at most one vintage should be given.

Tools checking a dataset should issue a warning message if the following query produces any results. Such results on their own however do not make a dataset non-conforming to the profile.

SELECT ?profile ?dataset ?instance ?property ?value1 ?value2
WHERE
{
  GRAPH ?profile
  {
    ?profile profiling:single ?single_pdp .
    ?class ?single_pdp ?property .
  }
  GRAPH ?dataset
  {
    ?instance a ?class .
    ?class ?property ?value1 , ?value2 .
  }
  FILTER( ?value1 != ?value2 )
}

3.6. Multi Properties

A profile may indicate that conforming datasets may provide multiple values for a property for any resource of a particular class. For example:

ex:Wine :multi ex:grape .

Any property not explicitly specified as single should be considered multiple — this is the default.

These hints are primarily useful for humans reading profiles, or documentation generated from from profiles.

3.7. Ranges

A profile may perform some basic checks on the values of properties. For example, the following statements indicate that the value of the foaf:name property must be a literal, the value of the foaf:homepage property must be a URI, and the value of the foaf:mbox property must be a URI beginning with "mailto:".

foaf:name     :range profiling:Literal .
foaf:homepage :range profiling:URI .
foaf:mbox     :range profiling:MailTo_URI .

Ranges that the profiling vocabulary defines are:

These ranges may also be used to qualify classes. For example, to insist that all foaf:Person resources must have an HTTP URI:

foaf:Person :type profiling:HTTP_URI .

3.8. Additional Comments

Additional comments about how a class or property should be used in a particular profile may be provided using :comment. For example:

foaf:Person
	:required foaf:name ;
	:recommended foaf:mbox ;
	:optional foaf:mbox_sha1sum ;
	:comment "If no mbox is given, an mbox_sha1sum should be provided instead." .

Conformance checkers may use these comments as part of error messages; documentation generators can use comments in the generated documentation.

4. An Example Profile

This section is informative.

The following defines a profile for representing books and their authors in RDF. It insists that people and organisations have names, and books have titles. Books should also have publication dates and publishers. To make matters easier for the consuming application, it requires people to use dc:creator instead of foaf:maker or foaf:made.

@prefix :          <#> .
@prefix profiling: <http://ontologi.es/profiling#> .
@prefix rdfs:      <http://www.w3.org/2000/01/rdf-schema#> .
@prefix dc:        <http://purl.org/dc/terms/#> .
@prefix foaf:      <http://xmlns.com/foaf/0.1/#> .

<>
	a                      profiling:Profile ;
	profiling:required     :required ;
	profiling:recommended  :recommended ;
	profiling:optional     :optional ;
	profiling:forbidden    :forbidden ;
	profiling:single       :single ;
	profiling:multi        :multi ;
	profiling:range        :range ;
	profiling:type         :type ;
	profiling:comment      :comment ;
	rdfs:label "Publications Profile" .

foaf:Person
	:type        profiling:NonLiteral ;
	:required    foaf:name ;
	:optional    foaf:mbox , foaf:homepage ;
	:forbidden   foaf:made ;
	:comment     "Represents an author." .

foaf:Document
	:type        profiling:NonLiteral ;
	:required    dc:title , dc:creator ;
	:recommended dc:publisher , dc:issued ;
	:optional    dc:contributor , dc:abstract ;
	:forbidden   foaf:maker ;
	:comment     "Represents a book." .

foaf:maker     :comment "Use dc:creator or dc:contributor instead." .
foaf:made      :comment "Use inverted dc:creator or dc:contributor instead." .
foaf:homepage  :range profiling:HTTP_URI .
foaf:mbox      :range profiling:MailTo_URI .
dc:creator     :range profiling:NonLiteral .
dc:publisher   :range profiling:NonLiteral .
dc:contributor :range profiling:NonLiteral .

Assuming a non-inferencing profile checker, the following RDF dataset would fail its check:

@prefix dc:        <http://purl.org/dc/terms/#> .
@prefix foaf:      <http://xmlns.com/foaf/0.1/#> .

[]
	a foaf:Document ;
	dc:title "The Scarlet Band" ;
	foaf:maker [
			a foaf:Person ;
			foaf:name "Arthur Conan Doyle"
		] .

The errors would be that the document's required property dc:creator was missing, and the foaf:maker property is forbidden. The dataset could be corrected by changing foaf:maker to dc:creator, or by changing the rdf:type of the document. Warnings would be issued that the document had no dc:publisher or dc:issued.

5. Profile Checking Behaviour

This section is informative.

Profile checkers may run the profile through an RDFS or OWL reasoner to inference additional triples and check the expanded graph.

Profile checkers may issue additional errors or warnings as a result of OWL constraints. (e.g. an assertion that two resources are both owl:sameAs and owl:differentFrom each other; or a resource which has two rdf:types that are owl:disjointWith each other.)

Profile checkers may issue warnings about subject nodes which do not have an rdf:type which is described by the profile. This behaviour should be configurable by the end user.

Appendix A. Acknowledgements

Initial discussions with Libby Miller et al at Vocamp Bristol.