- From: Graham Klyne <GK@dial.pipex.com>
- Date: Fri, 07 Jul 2000 12:40:38 +0100
- To: RDF comments <www-rdf-comments@w3.org>
- Cc: CC/PP WG list <w3c-ccpp-wg@w3.org>
Folks, In our work on CC/PP using RDF, we have come across an issue in designing a schema for representing set values using RDF collections. The desire was to use a new RDF class, ccpp:Set, defined as a subclass of rdf:Bag, to be a restricted bag-like container for CC/PP value sets. Unfortunately, because of the way that collections are expressed using the RDF syntax, this construct cannot be parsed by a non-schema-aware RDF parser, because of the use of <li> elements to represent 'rdf:_n' properties. It is necessary for the parser to be aware that the subject resource is an instance of 'rdf:Bag' to apply this transformation ... information that is available only through the schema. I believe that using schema to build rich class structures for application domains is a powerful tool for future evolution of RDF applications. I have been promoting the idea that using a rich class structure should not impose any additional implementation burden on specific applications, but may open the application data to more general use by schema-aware applications and tools. The issue described above is an impediment to using rich class structures in this way. How might this issue be resolved? Some thoughts: (a) use rdf:_1, rdf:_2, etc. directly as element names in the XML serializatiion of RDF collections. (b) use rdf:li within the RDF model graph to indicate membership of a collection. For an rdf:Bag this raises the issue of whether the same RDF statement (i.e. the same sub-->pred-->obj triple) can appear more than once in a model. (c) have some schema-independent way of indicating that a class is derived from an RDF collection class (or a resource is an instance of a collection). (d) introduce a convention that <rdf:li> elements are mapped to unique, sequential 'rdf:_n' properties regardless of the class to which they are applied. ...etc. #g ------------ Graham Klyne (GK@ACM.ORG)
Received on Monday, 10 July 2000 03:45:41 UTC