Re: RDF(S) triples, statements, and resource

[Apologies for posting to the WG list but it seemed appropriate to 
follow up here.]

Christopher Welty wrote:

> 1) The belief that triples are not resources is widespread.  If the 
> intention is indeed that triples are resources, we need to get the word 
> out somehow.  Software is being written today that will fail to 
> interoperate with other RDF software, as each implementation appears to 
> use a different out-of-standard way of referring to triples. 

The final sentence does not follow from the rest of your premises. Do 
you have any specific incompatibilities between specific implementations 
  in mind?

Whether or not a given *implementation* class is a subclass of another 
implementation class is an API issue not an interoperability issue. 
Existing RDF APIs may differ in this area but they as far as I know they 
inter-operate quite happily via RDF/XML. In particular, the RDF specs do 
provide the reification vocabulary as a way of associating URIRefs or 
bNodes with the occurrence of a triple and is supported by all 
conformant RDF software.

> 2) There is still no defined or recommended "mechanism" for assigning a 
> triple a URI.  Despite this, the specs seem to be telling us they are 
> intended to be resources. Perhaps it is time to at least recommend 
> something.

Surely all you need is a way to know what URIs have been assigned and 
the reificiation vocabulary provides at least one way to do that.

Do you have a use case for which this is insufficient?

> 3) I believe the correct data model here is to make the ODM "RDF Triple" 
> class a subclass of "RDFS Resource".  Does anyone see a problem with that?

Yes.

If ODM were some form of semantic model of RDF I might agree. However, 
and please correct me if I'm wrong, surely ODM is a data model intended 
to enable MOF-based software systems to store and manipulate RDF & OWL 
data? That seems to me to be a different thing.

Specifically in this case if you make RDFTriple a subclass (in the UML 
sense) of RDFSResource then that would mean that MOF implementations 
would expect to be able to put an RDFTriple directly as the subject or 
object of another RDFTriple. That would create a data structure which 
you could not directly serialize (other than by use of non-standard 
features of N3).

Conversely if an application wishes to refer to an RDFTriple from 
another Triple in a standards-compatible way then it would use the 
reification vocabulary to relate the RDFSResource used as the 
subject/object to the contents of the RDFTriple being referred to. Yet 
the resolution of the statement identity issue:
http://www.w3.org/2000/03/rdf-tracking/#rdfms-identity-of-statements
tells us that the mapping from an RDFTriple to its reifiying resource is 
one-to-many and thus not representable by a subclass relationship.

Let me risk an analogy. Arguably a car is also a resource, we might not 
be very clear on how to give one a URI but once we have such a URI we 
can use it to talk about properties of the car. If you had a MOF class 
Car to represent cars you wouldn't then make Car a subclass of 
RDFSResource, you would define an association between Car and 
RDSFResource to enable retrieval of the URI you used for a given Car 
instance. The RDFTriple case seems analogous to me except that the 
reification vocabulary gives us some additional hints on the nature and 
naming the association we should use.

Dave

> The Jena documentation is a little less vauge. In
> [http://jena.sourceforge.net/javadoc/com/hp/hpl/jena/graph/Triple.html] we
> see that a Triple is not a Resource (or a node), and in
> 
[http://jena.sourceforge.net/javadoc/com/hp/hpl/jena/rdf/model/Statement.html]
> it specifically says "A Statement is not a Resource".  While Dave Reynolds
> corrected us on interpreting the Jena class/interface names as being
> formal representations of their namesakes in the RDF specs, such a caveat
> will not prevent people from doing so, as Jena is very widley used by
> people writing RDF software, and it has become a defacto standard.   In
> fact, before copying Dave, this documentation was used as evidence to
> support the position that triples are not resources.  I doubt it is the
> first or last time that will happen.

To be clear for the record. The terms "Statement" and "Resource" in the 
quoted javadoc is referring to the java interfaces 
com.hp.hpl.jena.rdf.model.Statement and ..Resource and the "is not" is 
referring to the absence of a java subclass relationship. These are 
different things from the conceptual entities "RDF triple", "RDF 
resource" and "is-a-kind-of".

Received on Tuesday, 23 August 2005 20:20:44 UTC