URI Practices main page . URI Note main page

URI Resolution Ontology

resolution: finding a solution to a problem (dictionary.com)

In order to follow the advice in the URI note, the following ontology should be used. The ontology allows the expression of definition linking, 303 semantics, broken link repair, and second sourcing. It also provides a way to say that a term denotes a particular document that is not changing over time [TimBL: "fixed representation"], and a way to talk about versions.

This ontology is under construction. Take the spirit seriously, but not the letter.

Terminology here has not been aligned with the URI note draft yet... beware...

We'll fight about whether this is to be RDFS or OWL-DL, but as this is immaterial right now let's put that off.

How to comment on this draft

Please put your comments on the [[/../../DraftTalk]] page. I am editing this file off line, and keeping comments on a separate page helps ensure that your comments are heard and tracked. I will attempt to address all concerns and record dissenting views fairly.

History of this vocabulary

Matthias Samwald and Alan Ruttenberg presented the idea of using an ontology to describe URI resolution rules at the HCLS F2F in Amsterdam, October 2006. The ontology addresses the problems that LSIDs were meant to solve, as well as others that had been articulated by the group. See [http://tinyurl.com/y5tmud Ontology-based URI Resolution] (PDF file, 39 "slides").

Some of this was reinvented by JAR 2007-10-16 after concluding that there was no way that the advice in [[/../ShorterSputnikDraft]] could be taken without introducing some RDF vocabulary.

URI Resolution assertions

The overall resolution framework is as follows:

			 a locator (URI) L1
		       -- is used to access --
			 a defining document
			  -- that defines --
			    a term (URI) T
			  -- that denotes --
			  a thing (anything)
	    -- that is accessed (via an endpoint) using --
			  a locator (URI) L2

Nose-following says that T = L2 when there has been a 2xx response, while a 303 response, when there is one, may specify L1. The assumption is that if T can take you to a defining document then you don't need to get to an endpoint, and vice versa.

The locator-specifying part of the vocabulary is defensive, allowing agents to find second sources of endpoints when follow-your-nose has failed for any reason. However, it could also be useful for directing agents to alternative sources, such as a local file system, for connectivity, performance, or privacy reasons. It also establishes a way to provide both a definition and an endpoint.

@prefix urinote: <tag:neurocommons.org,2007/uri-note/>
@prefix foaf: ...
@prefix xsd: ...
@prefix rdf: ...
@prefix rdfs: ...

# Example defining document -> term -> denotation -> endpoint chain:
#   <http//mumble.net/foodefiner.rdf> urinote:defines "tag:mumble.net,2007/foo"^^xsd:anyURI .
#   <tag:mumble.net,2007/foo> urinote:isDenotedBy "tag:mumble.net,2007/foo"^^xsd:anyURI .
#   <tag:mumble.net,2007/foo> urinote:hasAssociatedEndpointAt "http//mumble.net/fooendpoint.html"^^xsd:anyURI .

# thing isDenotedBy URI .
# Forall URIs u that denote, <u> isDenotedBy "u"^^xsd:anyURI .
# Not really needed, but included here for completeness.
# Related to log:semantics, but I think it's not the same.
#
urinote:isDenotedBy a rdf:Property ; 
  rdfs:range  xsd:anyURI ;
  rdfs:comment 
"To say that X urinote:isDenotedBy T means that the URI T 
denotes (refers to) the thing X.  Ordinarily this doesn't 
need to be stated, as it is part of the way RDF is 
interpreted." .

# rdf_document defines URI .
#
# Maybe domain is a graph, not a foaf:Document  ...?
urinote:defines a rdf:Property ;
  rdfs:domain foaf:Document ;
  rdfs:range  xsd:anyURI ;
  rdfs:comment 
"To say that D urinote:defines T means that document D contains
statements involving T that sufficiently constrain the
use of T.  This relation constrains D to be an RDF document." .

# a stronger statement would be that D is a Boothian declaration of T.
# rdfs:isDefinedBy is akin to the composition of defines and denotes
# except that the description may be something other than RDF.
# compare http://dublincore.org/documents/dcmi-terms/#requires

# thing hasAssociatedEndpointAt URI .
#
# This property reflects Alan's view that the thing may differ from
# the endpoint.
# 
urinote:hasAssociatedEndpointAt a rdf:Property ;
  rdfs:range  xsd:anyURI .

# thing isLocatedBy URI .
#
# Reflects Pat's view that the thing is the endpoint (assuming 2xx).
# 
urinote:isLocatedBy a rdf:Property ;
  rdfs:range  xsd:anyURI ;
  rdfs:isSubPropertyOf urinote:hasAssociatedEndpointAt .

How to use SPARQL endpoints?
Do we need to be able to deal with web services?
A property that connects a thing to a browser-friendly presentation of it?

URI Resolution rules

URI resolution rules (rules for finding definitions and endpoints) are pretty much a shorthand for asserting large numbers of urinote:defines and urinote:hasAssociatedEndpointAt statements. This is a straw man proposal.

URI resolution rules are used for two purposes:

term -> definition locator
term -> endpoint locator

A definition resolution rule says that if T denotes something, and the match template matches T, and U' is the result of substituting the template variable values into the replacement template, then U' is a locator for an RDF document that defines T. (In the diagram, L1 = U'.)

An endpoint resolution rule says that if T and U' are as above, then U' is a locator that can be used to access U's denotation. (In the diagram, L2 = U'.)

To accommodate SOAP and SPARQL we would need a more general framework, like Alan's.

See URI Template.

urinote:rewriteRule a rdfs:Class .

# The range is really a URI template (see draft-gregorio-uritemplate-01)
urinote:hasMatchTemplate a rdf:Property ;
  rdfs:domain urinote:rewriteRule ;
  rdfs:range xsd:String .
urinote:hasReplacementTemplate a rdf:Property ;
  rdfs:domain urinote:rewriteRule ;
  rdfs:range xsd:String .

urinote:definitionResolutionRule rdfs:subClassOf urinote:rewriteRule .
urinote:endpointResolutionRule rdfs:subClassOf urinote:rewriteRule .

Promises about endpoint behavior

At the very least we need to be able to say that a document is unchanging ("fixed representation" or perhaps a weaker notion permitting some CN).


# "pure document", "unchanging document", "piece of data",
# "representation", etc. -- mathematically same as mime type +
# content.  Operationally we want to say that every 
# GET response ("representation") from the endpoint is the same.
#
urinote:fixedDocument a rdfs:Class ;
  rdfs:isSubclassOf foaf:Document .

This is completely open-ended - we could talk about media types, service types (blog / wiki / news), and so on. But for HCLS I don't think there's much demand, other than perhaps to have a way to say we can expect RDF.

TBD: deal with language and format variants (i.e. content negotiation in RDF) - not that HCLS much cares.

Versioning

Surely an ontology already exists that treats this.

urinote:isVersionOf a rdfs:Property ;
  rdfs:domain urinote:fixedDocument ;
  rdfs:range foaf:Document .

# This should be transitive
urinote:versionSupersedes a rdfs:Property ;
  rdfs:domain urinote:fixedDocument ;
  rdfs:range urinote:fixedDocument .

Standard rule sets

Someone (Science Commons, if no one else) will publish a set of URI resolution rules for use by the science and health care communities. These rules will be revised to add or change redirection and second source rules as they become known.