Re: ISSUE-5 Definition of Resource

Resource Shapes

Summary: When we say "resource" we mean "the RDF representation of an
information resource" - no - "an RDF representation of an information
resource" - no - "the RDF graph obtained by parsing the response returned
when dereferencing an IRI that represents an information resource while
asking for an RDF syntax (and each such response should be parsable into the
same RDF graph)" - no - "the RDF graph obtained by parsing the response
returned when dereferencing an IRI that represents a resource while asking
for an RDF syntax (...)" - no - "the RDF graph obtained by parsing the
response returned when dereferencing an IRI while asking for an RDF syntax
(...)".


 > The term "resource shape" is an abbreviation for the "shape of the graph
 > of the RDF representation of an information resource".

How can one understand this definition?

An information resource is something that can be considered to be (just)
information - whose essential characteristics can be packaged up into a
message (http://www.w3.org/TR/webarch/#id-resources).  Some information
resources are identified by URIs accessible via URL dereferencing.  When
using a URL to access an information resource it is possible to retrieve
representations of that information resource, which can be lots of things,
including RDF graphs.  If an information resource is accessible via URL
dereferencing, it is possible to request an RDF representation when
dereferencing a URL for the information resource and if there is an RDF
representation available at that URL it should be returned.  That
representation can be parsed to produce an RDF graph.

RDF graphs, like other graphs, can be considered to have certain properties,
such as connectivity, size, and diameter.  It is possible to go beyond these
standard graph properties to other kinds of properties.

So resource shapes works by taking a URL that dereferences to an information
resource, dereferencing it to get an RDF graph representation, parsing the
representation into an RDF graph, and then checking to see whether that
graph has certain properties.

But this is *not* the "shape of the graph of the RDF representation of an
information resource".  Information resources can accessed via dereferencing
multiple URLs (http://www.w3.org/TR/webarch/#uri-aliases), and the RDF
graphs obtained via dereferencing different URLs for the same information
resource might be different.  So it doesn't make sense to talk about *the*
RDF representation of an information resource.

So the whole idea behind "resource shape" is ill formulated in my opinion.


However, there is something that can be rescued, I think, and it might be
something that the working group could consider.  Consider an API that takes
an IRI and a constraint or shape that takes a single parameter.  What
happens is that the IRI is turned into a URL, the URL is dereferenced to
produce an RDF graph, and the RDF graph is validated against the constraint
or shape using the IRI as the parameter.

Suppose the IRI is a hash IRI.  Then the RDF graph would usually be the
graph available at the URL "obtained" by stripping off the hash part of the
IRI.  This graph would contain information about the resource denoted by the
IRI (normally a non-information resource).  Useful constraints would be
descriptions of what information is supposed to be in the RDF graph starting
at the IRI node of the graph.  This would work just as well for non-hash
IRIs that represent non-information resources.

For information resources the situation is a bit more murky.  They could be
treated the same as non-information resources, or perhaps for information
resources the shape or constraint should not have a parameter and should be
instead applied to the RDF graph as a whole.  This latter option appears to
be how resource shapes works.

This is no longer resource shapes, however.  It is instead something like
IRI constraints.


Which of the formal proposals can be made to work in these fashions?  (I can
only answer for OWL constraints and SPIN, guess for ShEx.)

OWL constraints can work in either of these ways.  The parameterized version
would take an IRI and a description, get the RDF graph, and determine
whether the IRI node in the canonical model of the graph satisfies the
description.  The unparameterized version would take an IRI and a set of OWL
axioms, get the RDF graph, and determine whether the axioms are true in the
canonical model of the graph, which is the normal way of working with OWL
constraints.

SPIN can also work in either of these ways.  The parameterized version would
take an IRI and a parameterized constraint, get the RDF graph, and determine
whether the constraint is satisfied in the graph when ?this is bound to the
IRI.  The unparameterized version would take an IRI and an RDF graph
containing SPIN constraints and links from classes to these constraints, get
the RDF graph, and then perform normal SPIN processing.

I'm not sure how ShEx would work either way.  Maybe in the parameterized
version the ShEx input would have a distinguished shape that the IRI has to
satisfy.  Perhaps the unparameterized version would also utilize a
distinguished shape and require that some node in the graph satisfies the
shape.


So maybe it would be worthwhile for the working group to specify an API that
uses an IRI to start the constraint/shape validation process, instead of
just saying that the validation process starts with an RDF graph in hand.
However, obtaining an RDF graph solely by dereferencing a single IRI does
not handle situations where one might want to combine several RDF graphs or
use a separate RDF graph containing an ontology.


Peter F. Patel-Schneider
Nuance Communications

Received on Friday, 19 December 2014 13:05:57 UTC