W3C home > Mailing lists > Public > www-rdf-interest@w3.org > September 2000

RE: RE: Discussion-Paper: A Logical Interpretation of RDF

From: McBride, Brian <bwm@hplb.hpl.hp.com>
Date: Mon, 4 Sep 2000 15:46:23 +0100
Message-ID: <5E13A1874524D411A876006008CD059F23938E@0-mail-1.hpl.hp.com>
To: "'Wolfram Conen'" <conen@wi-inf.uni-essen.de>
Cc: www-rdf-interest@w3.org
> There are no (in the strict sense) anonymous resources in the 
> RDF triple
> model. One may argue that in a "flat" (this will be explained below)
> semantic network/triple model, it is (only) the NAME that gives an
> entity its existence. Anonymous resources seem to be a by-product of
> "convinient" RDF syntax - on first (and second?) sight this induces a
> "mismatch" between (triple) model and 
> (graphical/serialization) syntax.

I find the spec confusing on this issue.  I do agree that to have a 
mismatch between the model and the syntax is unfortunate.  I
resolved this by interpreting the spec to say that the model also had
anonymous resources.  I am beginning to wonder whether I have over
generalised what the spec actually says.

My interpretation of:

  The intention of this sentence is to make the value of the Creator
  property a structured entity. In RDF such an entity is represented
  as another resource. The sentence above does not give a name to 
  that resource; it is anonymous, so in the diagram below we represent
  it with an empty oval:

from 2.1.1 of the spec is that the model does allow anonymous resources.
There are several subsequent references in the spec to 'anonymous bag
containers' where the anonymous bag is a model construct.

I'd like to see the argument about entities only existing when they have
a name.  I'll borrow an example from Dan Brickley - an entity can be 
referred to by its properties e.g. the person who's email address is
lassila@w3.org refers to an entity which to my knowledge has no URI.

I think this is a grey area of the spec.  One of the great benefits
an effort such as yours to formalise the specification is that it 
highlights such issues.  It is for you to consider whether this is an
issue that deserves such a spotlight.  I'd argue that it is more
significant than the issue you raised over properties having multiple
values.


> 
> Let us elaborate a bit on this: if one wants to make a 
> statement 2 about
> a statement 1, the easiest way to express this would be:
> 
> statement 2:  
> 	  [subject: [statement1], predicate: p2, object: o2]
> with [statement 1] being a triple [s1,p1,o1].
> 
> (please, note that here triples are represented with [] and in the
> sequence subject/predicate/object)
> 

Absolutely, and in fact that is what I, and if I remember correctly
SiRPAC, have implemented.  I have never really understoodd why
statements are not a subset of resources.

> 
> :
> :o (5) lit(o) => instanceOf(o, rdfs_Literal)
> :
> :  I was curious why there is no equivalent 
> :
> :      res(o) => instanceOf(o, rdfs_Resource)
> :
> 
> res(o) => instanceOf(o, rdfs_Resource) should not be asserted
> "automatically" because if it is NOT INFERABLE, this allow 
> the detection
> of domain/range constraint violations.

Hmmmm, consider (forgiving the shorthand):

<rdfs:Property rdf:about="http://foo/linksTo">
  <rdfs:domain rdf:resource="rdfs:Resource"/>
  <rdfs:range  rdf:resource="rdfs:Resource"/>
</rdfs:Property>

<rdf:Description rdf:about=
    "http://www-uk.hpl.hp.com/people/bwm/index.htm">
  <foo:linksTo rdf:resource=
    "http://www-uk.hpl.hp.com/people/bwm/rdf/index.htm">
</rdf:Description>

Have the domain or range constraints been violated?  If I am 
undertanding correctly, the model you have proposed would
say yes, because there is no explicit type property in the
model for the web pages which are the subject and object
of the linksTo statement.

If so, I disagree.  Anything identified by a URI
is a resource and even though there are no specific type
properties, no constraint violation exists.

Reminds me I really should have asked for a validation
algorithm to accompany the schema spec.

Good work.  Its great how it highlights issues in the spec.

Brian McBride
HPLabs
Received on Monday, 4 September 2000 10:46:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:51:44 GMT