RE: williams-01, proposal to close

Summary:
3.1 quite a lot of change but reflecting the rewording needed for
williams-01. I am happy with it.
3.1 Last Paragraph - not relevant, please excise from this proposal (maybe
relevant to some other issue)
3.2 The only substantive change here was changing
"Arcs are labelled with URI references" to "Arcs are URI references"
This change is incorrect. Please undo that change so that 3.2 proposed
changes are minor wording changes like s/The/A/ and s/node in an RDF
Graph/node/.

(I am not sure if the issue is still open, however the actual changes to
concepts in response to the issue certainly are still open).

Jeremy



> -----Original Message-----

Grahams proposed text:
>
> [[
> 3.1 Graph data model
>
> 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)]
>
> 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 an arc is significant: it always points toward
> the object
> of a statement.
>
> The nodes of an RDF graph are its subjects and objects.


Good so far.

Ugggh this para:
>
> 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 property, holds between the
> subject and object of the triple. 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].
>

This was text from elsewhere and should be considered under a different
issue.


> 3.2 URI-based vocabulary
>
> A node may be a URI with optional fragment identifier (URI reference, or
> URIref), a literal, or blank (having no separate form of identification).
> Arcs are URI references. (See [URI], section 4, for a description of URI
> reference forms, noting that relative URIs are not used in an RDF graph.
> See also section 6.4.)

The LC phrase "Arcs are labelled with URI references" is correct.
The proposed phrase "Arcs are URI references" otherwise OK.

>
> A URI reference or literal used as a node identifies what that node
> represents. A URI reference used as an arc identifies the relationship
> between the nodes connected by the arc. The arc URI reference may
> also be a
> node in the graph.

s/The/A/ at beginning of para OK, but otherwise LC text is more correct.

>
> A blank node is a node that is not a URI reference or a literal.
> In the RDF
> abstract syntax, a blank node is just a unique node that can be
> used in one
> or more RDF statements, and has no globally distinguishing identity.
>
> A convention used by some linear representations of an RDF graph,
> to allow
> several statements to contain the same blank node, is to use a blank node
> identifier, which is a local identifier that can be distinguished
> from all
> URIs and literals. When graphs are merged, their blank nodes must be kept
> distinct if meaning is to be preserved; this may call for
> re-allocation of
> blank node identifiers. Note that such blank node identifiers are
> not part
> of the RDF abstract syntax, and the representation of statements
> containing
> blank nodes is entirely dependent on the particular concrete syntax used.
> ]]
>
>
> -------------------
> Graham Klyne
> <GK@NineByNine.org>
> PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E
>
>

Received on Friday, 4 April 2003 07:30:55 UTC