

Re: Discussion-Paper: A Logical Interpretation of RDF

Date: Tue, 05 Sep 2000 00:30:48 +0200
Message-ID: <39B42298.B09A5A8F@wi-inf.uni-essen.de>
To: "McBride, Brian" <bwm@hplb.hpl.hp.com>
CC: www-rdf-interest@w3.org
[This is an answer to Brian's last EMail]

Brian McBride wrote:

:> There are no (in the strict sense) anonymous resources in the 
:> RDF triple
:> entity its existence. Anonymous resources seem to be a by-product of
:> "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
: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
: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
: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

Ah, ok. There is the "Basic RDF Model" (described in 2.1. with text and
graphs), than we have the different serialization syntax(es) and
finally, in Section 5, the "Formal Model of RDF" (first mentioning the
triples) shows up. We concentrated on the "triple representation" (which
should, in principle, make no difference in comparison to consider all 3
flavours of the model, because Section 5 says:

 " This specification shows three representations of the data model; as
3-tuples (triples), as a graph, and in XML. These representations have
equivalent meaning."

But it makes a little difference. I'll try to give the argument. A first
hint is given in the Appendix A (Glossary) with the defintiion of

"A representation of a statement used by RDF, consisting of just the
property, the RESOURCE IDENTIFIER, and the property value in that order.

A second aspect comes from the formal model itself: 
"1. There is a set called Resources. "


member of a set other than by giving it a NAME (completely in accordance
entities is a member of a set and if this construct is "give the entity
"NAMES FOR UNNAMED RESOURCES", but this does not look to plausible...).
{pred, sub, obj} if you can literally "write down" what it is (i.e. give
thing to be indentified). 

Hm, well, sounds probably a bit too "philosophical". The point I want to
make is not to say that there are no anonymous resources in the RDF data
model, but that, in a flat triple model (and as triples are members of
flat) there is no (logically consistent) way to express anonymity. And,
postulated equivalence of the above mentioned three representations of

"Each propertyElt E contained by a Description element results in the
identifier is given by the value of the about attribute of the

magically known in the triple model - no, the resource "behind" r IS its
IDENTIFIER. (In the graphical model, it is trivial to make a seperation
between named and unnamed resources -- simply leave the name out of the
oval - but this option is not present in the triple model - so, what do
you replace r for?).

However, some will find this discussion probably rather academic because
the "practical" solution of Parsers is to GENERATE names for "anonymous"
necessities for generating names could be diminished if a nested triple
model would be used.

:> :
:> :
:> :  I was curious why there is no equivalent 
:> :
:> :      res(o) => instanceOf(o, rdfs_Resource)
:> :
:> "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"/>
:<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">
: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.

Violation depends on the "tripleization" of the above. In the paper, we
took the (easy and comfortable) point of view that the model we want to
reason about (check constraints, query it, extend it) is already given
as triples. To complement the discussion there, a detailed analysis of
"what serialization syntax leads to which triples" should be done (this
is, clearly, already encoded in SirPAC or Jan's Prolog-Parser). Ideally,
this would end in an commonly accepted TRANSFORMATION GRAMMAR (Jan's
grammatical rules could be a good start).

information in the syntax above explicit, no violation would be
incomplete tripleization and a violation will (reasonably) detected.

position (and everything not a literal in object position) should
"automatically" be considered to be an instance of rdf:Resource - if you
would like to have it this way (and you seem to want it ;), the rule you
probably add it).

: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.

Maybe it should read: anything identified by a URI can be a resource? I
say this because only if "something" is part of the model, it becomes a
has to be in subject or predicate position somewhere - which is probably
not in accordance to "declaring" an object explicitly as resource as is
identifier (uri(x) predicate in our rules) for a "modeled" resource. So,
our statement would be "every x that makes the (logic) predicate uri(x)
true is considered to be a resource. 

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

Thanks, good to hear. Maybe something useful will grow out of it. More
of your valuable remarks are always welcome.

Wolfram and Reinhold

Received on Monday, 4 September 2000 18:20:45 GMT
