Re: Terminology for RDF Statement Sets

There is an attempt within WAI to build a glossary from teh existing ones we
are using. It would be nice to align it with a glossary for this group. (The
idea is that terms can be extracted easily for use in specs, but that the
collected groups  of WAI are expected to sort out an entry for each term in
an attempt to get some consistency among us).

And more importantly there is the work of the SWAG project (Hey Aaron, speak
up!! <grin/>). I would like to align that, too, because I think that it is a
smarter model and I hope it is compatible without having to do too much


Charles McCN

On Fri, 13 Apr 2001, Brian McBride wrote:

  Hi Sandro,

  Sandro Hawke wrote:
  > There's a technique in object-oriented design where you listen to all
  > the different words people are using and then turn those words into
  > class names.  In the RDF community, there seem to be a small number of
  > concepts for which an large number of terms are used.  I'm going to
  > try to list the ones I've heard, suggest what I think they mean, and
  > generally suggest this be on the RDF Issues List.

  Thanks for bringing this up and for the discussion which follows.

  There is an issue on the list:

  which is basically about the need for a glossary.  Does that cover the
  issue you wanted raisedd on the list?  I will add a reference to your
  message to that issue.


  ps:  I try to catch all issues raised on www-rdf-interest and
  www-rdf-logic, but to be sure an issue you raised is picked up, its
  better to send to


  > As background, there are also various other terms in use for "RDF
  > statement".  I've heard (and used) "statement", "assertion", "triple",
  > "3-tuple", "tuple", "sentence", and "property statement", at least.
  > But I think "RDF Statement" is okay for the formal documents and for
  > this message.
  > The area I'm concerned about is sets (in the mathematic, set theory
  > sense) of RDF statements.  Let me list some of the terms I've heard,
  > and see if I can organize them.
  > (set itself)
  >   statement set
  >   graph
  >   subgraph
  >   model
  >   theory   (a set of theorems; rdf statements as simple theorems)
  >   infoset   (an RDF infoset, not an XML infoset)
  >   dataset
  >   corpus (a body of knowledge; term I coined some years back)
  >   world
  >   universe
  >   description
  >   semantic content  ("for is in the semantic content of document bar")
  >   knowledge base
  > (set storage)
  >   triple store
  >   repository
  >   database  (or set itself; ambiguous)
  > (set encoding)
  >   context (in n3)
  >   logical formula
  >   document   ("does RDF document foo include RDF statement bar?")
  >   text     (like document)
  > (set source)
  >   attribution
  >   provenance
  > (The term "model" deserves a special disambiguation: "*The* RDF Model"
  > is the architecture, technique, or method of building things we use in
  > the RDF community.  "*An* RDF Model" is a representation of some
  > knowledge as a collection of RDF sentences (made according to *the* RDF
  > Model).  I would suggest "architecture" for the former sense, and the
  > latter sense is the subject of this message.)
  >  * "RDF" or "RDF Statement" Specializations
  > Some of these terms are well understood in some field, and we just
  > want a specialization.  We can prepend "RDF" to be make our usage
  > precise if the context does not do so.  Terms like "RDF statement set"
  > or "RDF infoset" or "RDF statement repository" work this way.
  > Many of these terms are defined in the appropriate sense only in some
  > fairly narrow field or context.  For example, you need just the right
  > setting to have the phrase "an RDF theory" understood to mean a set of
  > RDF sentences.
  >  * Confusing Information with its Identification
  > We sometimes conflate a set with the attributes of the set we use to
  > identify it, such as where it is stored and where we got it from.
  > Contrast terms for the information itself ("dataset"), the place it
  > exists ("repository"), the thing representing or encoding it
  > ("document"), or the source of the information ("provenance").
  > Quite a bit could be said about this kind of confusion.  In common
  > usage, the term "database" is used for both a collection of data and
  > for a database management system (a running process, or the software).
  > Think of all the ways one might answer "What database did you use?" in
  > different situations.
  > This distinction is intentionally ignored in most programming systems.
  > In C, an "int" is a C object (an area of memory) which represents an
  > integer.  It is not actually an integer itself, of course.  In C this
  > is rarely a problem.
  > For us, though, it may be more pernitious.  In set theory, sets are
  > immutable.  But we programmers are used to Set.add(element) and
  > Set.remove(element) because we conflate mathematical sets with the
  > data structures which can be used to store information about set
  > membership.  To me, every term on the above list could be used in a
  > mutable sense, because I have the programmer's habit of naming data
  > structures (mutable or not) after the objects about which they store
  > data.  So what term can I use to unambiguously denote the
  > mathematically pure, immutable kind of set of RDF statements?
  >     -- sandro

Charles McCathieNevile  phone: +61 409 134 136
W3C Web Accessibility Initiative    fax: +1 617 258 5999
Location: 21 Mitchell street FOOTSCRAY Vic 3011, Australia
(or W3C INRIA, Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, France)

Received on Friday, 13 April 2001 09:13:55 UTC