(tentative) container model proposal

rdfcore,

	http://www.w3.org/2001/05/rdf-c/ (copied below in text form)

I have written up a first pass at a proposal that simplifies and clarifies
the M+S "formal model" for containers. The intent is to accompany the
Beckett/McBride simplification of container syntax by proposing a clean up
of the container "formal model".

I am well aware that the proposal is currently in a skeletal state, and
lacks test cases. I hope it provides at least some useful background for
discussion on friday. Regarding test cases, I have to say I'm stumped: the
implementations this relate to are databases, APIs etc rather than
parsers, and I am not sure how best to represent tests of that kind.

Basically, the formal model section on containers adds nothing but
confusion to the spec. I am proposing that the material about containers
be moved to a less central part of the specifcation.

Dan (in transit to Boston for the next several hours)



                  [1]RDFCore notes: Container model problems

      [1] http://www.w3.org/2001/sw/RDFCore/

   Author: [2]danbri@w3.org $Id: Overview.html,v 1.4 2001/06/07 03:12:09
   danbri Exp $

      [2] mailto:danbri@w3.org

   Nearby: [3]proposed interpretation of RDF containers, 2000-12-13

      [3]
http://www-uk.hpl.hp.com/people/bwm/rdf/issues/containersyntax/current.htm

Overview

   This document is concerned with the RDF formal model treatment of
   containers. It is unconcerned with syntactic issues; those problems
   are covered by the 'container interpretation' doc above.

   The issue here is raised in the container interpretation doc:
     * M+S says that container members have properties starting at rdf:_1
       and running contiguously through to rdf:_n where n is the number
       of elements in the container. Whilst this is true of the abstract
       container, M+S does NOT say that an implementation cannot
       represent a partial model of a container, and thus might not
       contain all the properties.

   This document motivates and proposes a simplification to the
   specification of the RDF model consistent with the proposed container
   syntax simplification.

Problem statement

   The RDF Model and Syntax recommendation includes two kinds of special
   case support for three types of "container" or grouping construct:
   Bags, Seqs and Alts. The specification expresses support for these at
   both syntactic and formal model levels. Regarding syntax, M+S defines
   some XML structures (based around the rdf:li construct) that make it
   easier to serialise representations of containers. There are known
   problems with the detail of this syntax, see Beckett/McBride
   [4]proposed simplification.

      [4]
http://www-uk.hpl.hp.com/people/bwm/rdf/issues/containersyntax/current.htm

   In addition to the problem with container syntax, RDF's specification
   of a formal model for containers is also problematic. This document
   proposes editorial changes to the Model and Syntax specification to
   simplify the spec's description of the model.

   The [5]"formal model" section of the spec tells us:

      [5] http://www.w3.org/TR/REC-rdf-syntax/#model

     [[ As described in Section 3, it is frequently necessary to
     represent a collection of resources or literals; for example to
     state that a property has an ordered sequence of values. RDF
     defines three kinds of collections: ordered lists, called
     Sequences, unordered lists, called Bags, and lists that represent
     alternatives for the (single) value of a property, called
     Alternatives.

     Formally, these three collection types are defined by: 10.There are
     three elements of Resources, not contained in Properties, known as
     RDF:Seq, RDF:Bag, and RDF:Alt. 11.There is a subset of Properties
     corresponding to the ordinals (1, 2, 3, ...) called Ord. We refer
     to elements of Ord as RDF:_1, RDF:_2, RDF:_3, ...

   The next paragraph in the specification is problematic. It tells us
   that collection elements are numbered in sequence using the ordinal
   properties rdf:_1 rdf:_2 etc. Note that this is with regard to the
   formal model for representing RDF containers, and not with regard to
   any particular XML representation (complete or partial) of this
   information.

     To represent a collection c, create a triple {RDF:type, c, t} where
     t is one of the three collection types RDF:Seq, RDF:Bag, or
     RDF:Alt. The remaining triples {RDF:_1, c, r1}, ..., {RDF:_n, c,
     rn}, ... point to each of the members rn of the collection. For a
     single collection resource there may be at most one triple whose
     predicate is any given element of Ord and the elements of Ord must
     be used in sequence starting with RDF:_1. For resources that are
     instances of the RDF:Alt collection type, there must be exactly one
     triple whose predicate is RDF:_1 and that is the default value for
     the Alternatives resource (that is, there must always be at least
     one alternative).

   Two problems are posed by this formulation:
     * it can be read as suggesting that any RDF model which describes
       some container is in possession of a complete description of that
       container. The phrase "the elements of Ord must be used in
       sequence starting with RDF:_1" appears to rule out the use of the
       formal RDF container model for descriptions where only partial
       information is available. Use case: an rdf:Seq representing the
       (incompletely represented) houses in a street.
     * it interacts with the syntactic sugar provided by the rdf:li XML
       syntax machinery: RDF parsers written with (one reading of) this
       text in mind could assume that containers encoded using this
       construct contain complete descriptions of some Bag, Seq or Alt.
       But there is no syntax-level support for making this clear.

   This situation is in tension with a broad design goal of RDF: to allow
   Web services to aggregate and process partial descriptions.

(Tentative) Proposed Simplification

   Note: It is is possible to take a permissive reading of the "formal
   model" for containers, and read these paragraphs as describing the
   structure of containers "in the abstract". This permissive reading
   would allow for actual RDF representations of containers to be
   partial, incomplete etc., while insisting that the container itself
   (in some idealised form) does consist of a complete (ungappy)
   collection. For example, it could be true that some container has 20
   elements, yet no RDF representation of that element actually had
   representations of the complete data structure.

   The alternative to this reading is to take the paragraph about
   sequential numbering to apply to instances of RDF data, not just when
   serialised as XML/RDF but also in the context of databases, APIs etc.
   To the authors knowledge (@@refs to the contrary welcome), there are
   no implementations of RDF that take this view, since it makes exchange
   of partial information about containers highly problematic.

   If the permissive reading is taken, and RDF databases, APIs etc are
   allowed to represent partial (gappy) information about containers, a
   substantial simplification to the "formal model" section of RDF M+S
   becomes possible: the text, making no strong claims about RDF
   implementations, can be removed (or transferred to a less central part
   of the spec). RDF Schema already contains a section describing Model
   and Syntax constructs; it is proposed that the section of M+S formal
   model relating to containers be moved to RDF Schema.

   Rationale: The M+S container constructs, like properties, classes
   etc., have no special relationship to the RDF model. The only reading
   of M+S that gives them such a privileged role is (?) unimplemented. By
   removing the priveleged role given to containers in the RDF formal
   model, the spec can be made simpler and clearer without changing the
   model.

  Test Cases

   I want to show some test cases here couched against RDF APIs, rather
   than in terms of syntax. Suggestions needed on how to do this in a
   machine friendly format....

Received on Wednesday, 6 June 2001 23:23:05 UTC