Re: parseType=collection causing confusion (fwd)

forwarded to www-rdf-comments for tracking...

---------- Forwarded message ----------
Date: Sat, 05 Oct 2002 06:22:39 -0700
From: David Martin <martin@ai.sri.com>
To: Dave Beckett <dave.beckett@bristol.ac.uk>
Cc: www-rdf-logic@w3.org
Subject: Re: parseType=collection causing confusion
Resent-Date: Sat, 5 Oct 2002 09:21:51 -0400 (EDT)
Resent-From: www-rdf-logic@w3.org


Folks who are working on RDF, DAML+OIL, and OWL -- *please take note* -- this is a
significant issue.

As best I can tell, RDF and DAML+OIL do not provide any convenient notation for (ordered)
lists.  (I don't know about OWL, and haven't yet taken the time to check the draft spec
for it.)  And, judging from Dave Beckett's very helpful response (copied below), there
are no plans to provide such a notation.

>From the language user's perspective, this situation is precisely analogous to the
situation that would hold if all lists in Lisp programs had to be written in the
canonical "consed-pair construction"; that is, if the familiar (a b c) notation were not
available.

In the DAML-S coalition, we wanted to use parseType=collection to represent ordered
lists.  That is, we wanted to define a property with range = daml:List, and express
instances of that property that are *ordered* lists.  (Nothing mysterious or
complicated.)

We've been forced to the conclusion that we can't, in good conscience, use
parseType=collection in that way.

We've been forced to that conclusion primarily because of this language, in the DAML+OIL
reference description:

"Note that structures of parseType daml:collection are intended to represent unordered
collections, even though the RDF datastructure imposes a specific order on
the elements."

If we are going to represent lists in DAML-S documents, we feel there must be a guarantee
that order will be maintained -- and parseType daml:collection clearly does not provide
that guarantee.  Now, the reference description *does* state that a use of parseType
daml:collection expands to a list construct.  Also, if I understand Dave Beckett's points
copied below, the upcoming RDF spec will guarantee that such uses expand to triples,
which faithfully represent that list construct. But we feel that, especially in light of
the above language, this just isn't good enough!

What we feel a need for is a guarantee that order will be maintained, by parsers and
processing tools of all kinds.  For example, one can readily imagine parsers and tools
that go beyond the mandated triples representation.  One can imagine tools that read in a
parseType = daml:collection construct, and then place the elements into a *set* data
structure, in which order is no longer maintained.  Such a move would be quite
legitimate, given the current language in the DAML+OIL spec, the proposed language for
the RDF spec, and Dave's explanations.  In short, we think there's a need for a construct
that is clearly intended to represent *ordered* lists, and documented in a way that will
unambiguously be understood by all parser and tool builders.

 In deciding this issue, we asked the question:

"Can I feel confident that a DAML+OIL-compliant parser or tool
will maintain the order of elements given inside a parseType=collection
construct, when it's used in specifying an instance of a user-defined
property?"

And ultimately we felt that the answer had to be "no", giving the existing documentation
of parseType=collection.

Therefore, I strongly recommend that something other than parseType=collection be
provided, for the purpose of conveniently representing ordered lists.

Finally, I want to express my appreciation to Dave Beckett, whose response (copied below)
to my questions about parseType=collection has been extremely helpful.

Regards,
David Martin

Dave Beckett wrote:

> >>>David Martin said:
> >
> > DAML+OIL folk -
>
> Well, I'm answering with respect to the RDF(/XML) since I edit
> the RDF/XML document for the RDF Core working group.
>
> > In the section on reference section on parseType=collection:
> >
> > http://www.daml.org/2001/03/reference#collection
> >
> > it states that a use of parseType=collection, such as:
> >
> > <oneOf rdf:parseType="daml:collection">
> >   <Thing rdf:resource="#red"/>
> >   <Thing rdf:resource="#white"/>
> >   <Thing rdf:resource="#blue"/>
> > </oneOf>
> >
> > is equivalent to an RDF List construct (not reproduced here), which
> > "imposes a specific order on the elements".  But then it also says
> > (rather schizophrenically) that "structures of parseType daml:collection
> > are intended to represent *unordered* collections".
>
> The Web Ontology Working Group) asked RDF Core to add this construct
> to the RDF/XML syntax, and I have started to add the appropriate
> grammar changes to the editors draft of the RDF/XML syntax document
> I edit.
>
> The syntax grammar changes:
>   http://ilrt.org/discovery/2001/07/rdf-syntax-grammar/#parseTypeContainerPropertyElt
>
> but this does not tell you what the resulting triples *mean*.
>
> (There will be an explanation of this construct and example of its
> use in due course)
>
> It is intended that this structure is an easy way to create this
> lisp-like structure of triples at the end of a property (daml:oneOf
> in your example).  RDF will not define any further meaning for them;
> in particular nothing is being said about ordering.  The rdf:first
> and rdf:rest properties will allow applications to walk the structure
> and apply an ordering at that level.  In particular, it is expected
> that WebOnt will do that so that their use of rdf:parseType="Collection"
> will define ordered lists.
>
> > Well, I'd like to use it to represent an *ordered* collection.  Since
> > it's clearly defined as an RDF List construct that maintains order, it
> > seems to me I should be able to use it that way with confidence.
>
> I see it as perfectly ok to use the form above for any kind of
> application-specific list, ordered, with duplicates or any other
> structure that may not even be a collection.  That is, the resulting
> triple structure can have your own interpretation.
>
> > In other words, I would like to be able to define my own property,
> > which, like oneOf, has daml:List as its range, and I'd like to be able
> > to use parseType=collection in specifying instances of this property.
> > AND, I'd like to have some confidence that any DAML+OIL-compliant parser
> > or tool will maintain the order that's given inside the parseType=
> > collection construct.  But the wording of the reference document leaves
> > me in doubt.
> >
> > QUESTION: Can I feel confident that a DAML+OIL-compliant parser or tool
> > will maintain the order of elements given inside a parseType=collection
> > construct, when it's used in specifying an instance of a user-defined
> > property?
>
> I'll leave that to DAML+OIL or OWL/WebONT experts.
>
> >
> > RECOMMENDATION: In descendant languages of DAML+OIL, such as OWL, if
> > "parseType" is still used, let there be *both* of the following:
> >
> >   parseType=collection, where it's explicitly documented that a parser
> > *isn't* required to maintain the given order,
> >
> > AND
> >
> >   parseType=list, where it's explicitly documented that a parser *is*
> > required to maintain the given order
>
> The parser requires the same structure of triples to be generated; it
> is the interpretation of that structure which decides if their is an
> order.  A parseType is a rather low-level and syntax-based way of
> doing that, when it would better live inside the semantics.
>
> I expect OWL will have other ways in their abstract syntax (and
> concrete forms) to abbreviate and do such things more concisely.
>
> Dave

Received on Saturday, 5 October 2002 09:37:09 UTC