- From: Ken Baclawski <kenb@ccs.neu.edu>
- Date: Fri, 3 Aug 2001 00:04:27 -0400 (EDT)
- To: Brian McBride <bwm@hplb.hpl.hp.com>
- cc: www-rdf-comments@w3.org
On Wed, 1 Aug 2001, Brian McBride wrote: > Hi Ken, > > Ken Baclawski wrote: > > > > The RDF specification states: "The parseType attribute should have one of > > the values 'Literal' or 'Resource'." In addition, the formal grammar does > > not allow for other values of this attribute. > > > > However, the spec contradicts this requirement by allowing a parseType > > other than Resource or Literal, and specifying that in this case it should > > interpret it as if it was Literal. > > > > These two specifications appear to conflict with one another. > > My own personal interpretation of these statements is that the M&S spec > does constrain parseType to take values of either Resource or Literal. > However the working group had the foresight to anticipate that new > values may be defined in the future, and defined the behaviour that an > an rdf processor built according to M&S 1.0 should exhibit if it > encountered such an attribute value. This makes it easier to define > extensions. I agree that it is useful to anticipate future extensions, but not at the cost of making the current specification inconsistent. > > This issue arose when I was puzzling over why SiRPAC was not giving me an > > error message when I gave it the parseType "daml:collection". > > Personally, I would expect a parser to emit at least a warning message, and > an error if in 'strict' mode. There are number of issues known with SiRPAC > and its behaviour should not be considered definitive. There is a need > for an improved 'reference standard' implementation of an RDF parser. > Jeremy Carrol's recently announced ARP parser is a potential candidate for > that role as it is automatically generated from the grammar. Thanks for the pointers. I also expected that some warning be issued, and this led to my original problem. However, the problem is not due to SiRPAC not being definitive. In fact, SiRPAC is consistent with the spec in this case. The problem is that the spec is not consistent with itself. > You might also try the Jena implementation with RDFFilter which has > explicit support for daml:collection. > > > > > I subsequently also wondered whether the "daml" prefix in this case > > should be interpreted as a namespace or as simply part of a literal. In > > particular, if I happened to use "abc" as the namespace for the DAML > > schema, then should I use parseType="abc:collection" or > > parseType="daml:collection"? In other words, how should namespace > > specifications be interpreted in literals, such as attribute literals or > > parseType literals? > > That is a question you should better address to the daml community as > they defined it. I can tell you that the Jena version of RDF Filter > assumes that daml:collection is a fixed string and takes no account > of namespace prefixes defined in the document when processing it. I'll try posting a comment about this. It is certainly consistent to assume that the daml:collection is a fixed string, but could also be confusing if the daml: prefix refers to some other namespace in a document. > I hope these observations are of some help. Yes they have. Thanks, Ken Baclawski Ken@Baclawski.com
Received on Friday, 3 August 2001 00:04:39 UTC