Re: Alternate parseType Issues

Brian McBride <bwm@hplb.hpl.hp.com> wrote:

> I'd like to see if we can try and clarify what the issues here are.

Thanks for looking at this with me.

>> The first is that alternate parseTypes, while allowed by the text of the
>> specification, are not allowed by the grammar which constrains them to
>> either Resource or Literal.
> So I'm not sure that's really that inconsistent.  Only parseType's 'Resouce'
> and 'Literal' are allowed, either by the the grammar or by the the text.
> There is a statement, defining the behaviour for RDF 1.0, should it be
> processing something other than RDF 1.0.  My guess is that was done so
> that those defining new parseType's would know exactly how it would be
> processed by an RDF 1.0 processor, even though it was not legal RDF 1.0.

That's an interesting point of view, but if an RDF 1.0 parser is expected to
process documents with new parseTypes, then it should be able to have some
knowledge of where to expect it. I think this is a simple change to
production 6.32, making it:

[6.32] parseLiteral   ::= ' parseType="' Qname '"'

>> It does not state that the value of the parseType must be passed along with
>> the literal, which seems essential for proper processing by an application.
> M&S is about defining the language and its interpretation.  It doesn't
> talk about processing models, API's for parsers or the like.  When you talk
> about the parseType being passed along, what is it being passed from and to.
> We have no language in the spec to talk to about that.

I'd suggest that we use language along the lines of xml:lang:

    There is no specific data model representation for xml:lang (i.e., it
    adds no triples to the data model); the language of a literal is
    considered by RDF to be a part of the literal.

So something like:

    There is no specific data model representation for a parseType (i.e., it
    adds no triples to the data model); the parseType of a literal is
    considered by RDF to be a part of the literal. Literals with no
    parseType are considered as if they were parseType="Literal".

would be just fine.

>> Finally, it would be nice if parseTypes were namespace qualified, as DAML
>> (daml:collection) and CWM (log:Quote) seem to have done. However, the
>> semantics of these QNames is unclear, as DAML seems to state the name must
>> be daml:collection regardless of the prefix for the DAML namespace in the
>> document.
> 
> That's an interesting thought.  I guess the web principal is that everything
> should be identified by a URI, and then daml:collection could be thought
> of as an encoding of a URI.
> 
> That sort of thing is only really needed though if we expect parseType to be
> used as a kinda general purpose extensibility mechanism where anyone can
> come along and define a new parse type.  If there are just a few of them
> defined by the language, then its a controlled vocabulary and we don't need
> an open naming scheme like that.
> 
> So I'm wondering if the issue you are really getting at here is to propose
> that the spec acknowledge that parseType's can be defined by anyone as an
> open extensibility mechanism.

Well, what I am really getting at is that like it or not, parseTypes are
being used as an open extensibility mechanism, and this mechanism is clearly
useful. There are many things (base64, new list structures, additional
logical semantics, datatypes of literals, etc.) that people would like to
add to RDF, and parseType provides a good place for them in a reasonably
backwards-compatible manner. I think that as long as this ability is in the
spec, people will continue to use it, and so we should document this
feature.

> Do tell if I've missed the mark.

Not at all, your comments were quite helpful.
-- 
[ Aaron Swartz | me@aaronsw.com | http://www.aaronsw.com ]

Received on Tuesday, 12 June 2001 11:39:20 UTC