Re: subject/predicate/object terminology

Let me make the following suggestions for a uniform way to approach 
and present our terminology.

1. A triple *is* a 3-tuple which is made up of a subject, predicate 
and object which are respectively a uriref or bnode; uriref; uriref, 
bnode or literal.

2. An RDF graph *is* a set of triples.

Note that so far there is nothing even remotely graph-theoretic - 
nodes, arcs, etc. - mentioned. This is important for the formal 
documents, so it would be helpful for readers if the less formal 
documents at least didn't give the impression of saying something 
different..

3. One can draw a *picture* of an RDF graph as a node-arc diagram 
(which is why we call them "graphs") using the conventions we all 
know and love. Notice that the labels of the directed arcs *in the 
picture* are always the predicates, and that the bnodes *in the 
picture* really are blank, etc.. Also in this picture one can see a 
distinction between nodes and node labels, and arcs and arc labels. 
But that's all just *pictorial*.

3a.  Maybe, when we are being careless, we might use the 'picture' 
terminology when talking about triples and RDF graphs. But that's 
just being careless and intuitive.

4.  RDF graphs are typically used to make assertions, by being 
published on the Web, and when so used they can be seen as 
*statements*; in effect, they *state* that some condition is true.

4a. When being careless, we might use the 'statement' terminology 
when referring to triples or RDF graphs. But that's just being 
careless and intuitive.
-----
If we all stick to this discipline, then it suggests rewrites similar 
to the following in the places noted:


>Following up on item 9 in today's agenda, here are some potential 
>problem areas in Concepts and Vocabulary (I don't claim these are 
>exhaustive):
>
>Concepts Section 3.1 begins:
>
>"The underlying structure of any expression in RDF can be viewed as 
>a directed labelled graph, which consists of nodes and labelled 
>directed arcs that link pairs of nodes (these notions are defined 
>more formally in section 6). The RDF graph is a set of *triples*:

Change to:

"The underlying structure of any expression in RDF is a collection of 
triples, each consisting of a subject, a predicate and an object. A 
set of such triples is called an RDF graph (defined more formally in 
section 6.) The structure can be illustrated by a directed node-arc 
diagram in which each triple is represented as a node-arc-node link 
(hence the term "graph".)

>[image of the RDF triple comprising (subject, predicate, object)]

When some RDF is published or claimed to be true, the triples in the 
graph are treated as assertions or statements. The assertion of an 
RDF triple says that some relationship, indicated by the predicate 
labelling the directed arc in a diagram, holds between the subject 
and object of the triple, indicated by the nodes linked by the arc in 
the diagram.  The assertion of an RDF graph amounts to asserting all 
the triples in it, so the meaning of an RDF graph is the conjunction 
(logical AND) of all the statements it contains. A formal account of 
the  meaning of RDF graphs is given in [RDF Semantics].

>Each property arc represents a *statement* of a relationship between 
>the things denoted by the nodes that it links, having three parts:
>
>    1. a property that describes some relationship (also called a predicate),
>    2. a value that is the subject of the *statement*, and
>    3. a value that is the object of the *statement*.
>
>The direction of the arc is significant: it always points toward the 
>object of a *statement*.
>
>The meaning of an RDF graph is the conjunction (i.e. logical AND) of 
>all the *statements* that it contains."
>
>I've highlighted *triple* and *statement* in the above.  The text 
>seems mostly to be talking about the subject/predicate/object of 
>*statements*, except for the introduction, which seems to suggest 
>it's talking about *triples*.  A question is whether we're going to 
>use subject, predicate, and object for talking both about components 
>of triples, and components of statements and, if so, how we keep 
>them straight.  Note that the abstract syntax uses these terms to 
>refer to parts of *triples*.

Right. I suggest we all do an edit pass to make sure that the words 
subject/predicate/object are used consistently to refer to the 
syntactic parts of a triple, and not to anything else.

>
>Also, in bullets 2 and 3, tht term "value" is a bit ambiguous:  it 
>could be read either as referring to a URIref, or to the thing 
>denoted by that URIref.  Given the wording in the preceding phrase, 
>changing "a value" to "the thing" would clarify that it was talking 
>about the thing denoted, rather than the URIref (if that's what it 
>is talking about).
>
>Concepts Section 3.4, the third sentence, says:
>
>"A literal may be the object of an RDF *statement*, but not the 
>subject or the arc"
>
>This seems to mix several things.  A literal sounds like the lexical 
>thing, which would be a reasonable object of a triple, but 
>less-clear for a statement (presumably it's the value denoted by the 
>literal that would be the object of a statement).  "Arc" seems to be 
>mixing in the drawing terminology from Section 3.1, and it's not 
>clear it belongs here.

Right, I think it is confusing. Better to say 'predicate'

>
>Concepts Section 3.5 starts:
>
>"Some simple facts indicate a relationship between two objects. Such 
>a fact may be represented as an RDF triple in which the predicate 
>names the relationship, and the subject and object denote the two 
>objects."
>
>In this section, the term "fact" is used as the thing represented as 
>an RDF triple.  In Section 3.1 the thing represented as a triple 
>seemed to be a "statement".  There may or may not be a problem using 
>"fact" in this kind of text, but its relationship to "statement" 
>needs to be made clear.  Also, "object" is used in two different 
>ways, as the things denoted by subjects and objects, and as the 
>third component of a triple.

Right. Suggested rewording might be:

"Some simple facts can be phrased in terms of a relationship holding 
between two things. Such a fact can be expressed by an RDF triple in 
which the predicate names the relationship and the subject and object 
name the things. "

>
>Vocabulary Section 5.3.1:
>
>This section starts with some nice text that is clearly about 
>subjects, predicates, and objects of *statements*.
>
>Section 5.3.2 (rdf:subject) then says:
>
>"A *triple* of the form:
>
>S rdf:subject R
>
>states that S is an instance of rdf:Statement and that the subject of S is R"
>
>This may or may not be problematic.  The question is whether the 
>reader will interpret S and R as the URIrefs involved in the 
>corresponding triple, or as the resources denoted by S and R. 
>Similar comments apply to sections 5.3.3 and 5.3.4.

Right, I have used this form of words in the semantics doc a lot, and 
it caused some confusion. But it is hard to see how else to say it, 
other than by being incredibly long-winded and making the text 
unreadable. Talking about the reification vocabulary is particularly 
awkward, of course.

I'm not sure what else we can do, except maybe add some emphasis 
prose to clarify things at particularly tricky moments, eg:

"...
S rdf:subject R

is used when referring to another triple S. It states that S is an 
instance of rdf:Statement and the the subject of the triple S is R."

But Im not sure that helps very much.

BTW, the above is not strictly true: it asserts that the subject of 
the triple S *denotes* R, not *is* R.

-Pat



>--
>Frank Manola                   The MITRE Corporation
>202 Burlington Road, MS A345   Bedford, MA 01730-1420
>mailto:fmanola@mitre.org       voice: 781-271-8147   FAX: 781-271-875


-- 
---------------------------------------------------------------------
IHMC					(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola              			(850)202 4440   fax
FL 32501           				(850)291 0667    cell
phayes@ai.uwf.edu	          http://www.coginst.uwf.edu/~phayes
s.pam@ai.uwf.edu   for spam

Received on Friday, 21 February 2003 11:36:08 UTC