W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > April 2002

addressing requirements around daml:collection (rdfms-seq-representation)

From: Dan Connolly <connolly@w3.org>
Date: 19 Apr 2002 12:54:44 -0500
To: w3c-rdfcore-wg@w3.org
Cc: Lynn Andrea Stein <las@olin.edu>
Message-Id: <1019238884.5315.399.camel@dirk>
I picked up the ball on this 28 Mar:

"Volunteers: DanC, Lynn Stein (some timing issues need to be resolved),
Jos 
De Roo,
Will participate in RDF core working group discussion."
http://lists.w3.org/Archives/Public/www-webont-wg/2002Mar/0352.html

I got some inspiration from today's RDF Core telcon
(and in discussion that followed after the formal
telcon was adjourned).

In case Lynn finds time to participate, I'm also summarizing
the history here. (Brian, maybe you could link this
message or some of the stuff I cite here from the
rdfms-seq-representation issue)


daml:collection is specified in:
  section 3. rdf:parseType="daml:collection"
  DAML+OIL (March 2001) Reference Description
  W3C Note 18 December 2001
  http://www.w3.org/TR/2001/NOTE-daml+oil-reference-20011218#3

Here's the hello-world example:

  <daml:oneOf parseType="daml:collection">
    <daml:Thing rdf:about="#Eurasia"/>
    <daml:Thing rdf:about="#Africa"/>
    <daml:Thing rdf:about="#North_America"/>
    <daml:Thing rdf:about="#South_America "/>
    <daml:Thing rdf:about="#Australia"/>
    <daml:Thing rdf:about="#Antarctica"/>
  </oneOf>

Now RDF Core has decided[26Feb] that using parseType as an
extension mechanism doesn't really work; M&S
says daml:collection should be treated like
parseType="Literal" which is different
from -- inconsistent with, in some cases -- expanding
it to first/rest.

[26Feb] http://www.w3.org/2001/sw/RDFCore/20020225-f2f/#d-2002-02-26-1

Where to go next? WebOnt clearly needs closed containers.
[I should be able to derive that from the requirements
document; I hope you don't mind if I pass over that for now...]

This seems pretty closely related to
  http://www.w3.org/2000/03/rdf-tracking/#rdfms-seq-representation
which we decided to close by punting/postponing
[oops; didn't we? I see it's "currently: for discussion";
ah... perhaps I'm confusing it with...
http://www.w3.org/2000/03/rdf-tracking/#rdf-containers-otherapproaches
which is closed, as of 15Feb.]

RDF/xml has special syntax for containers, but experience
trying to exploit it to come to intuitive conclusions
has exposed problems. Take the class above... say
Continent is the subject of that oneOf property.
If we know

	ex:Bob daml:differentIndividualFrom ex:Eurasia.
	ex:Bob daml:differentIndividualFrom ex:Africa.
	ex:Bob daml:differentIndividualFrom ex:North_America.
	ex:Bob daml:differentIndividualFrom ex:South_America.
	ex:Bob daml:differentIndividualFrom ex:Australia.
	ex:Bob daml:differentIndividualFrom ex:Antarctica.

	ex:NotContinent daml:complementOf ex:Continent.

then we should be able to conclude

	ex:Bob rdf:type ex:NotContinent.

Now this works perfectly well* when the oneOf claim
is spelled out long-hand using first/rest/nil.

*[I should back this claim with running code,
but in the interest of getting this and other
stuff done today, I'm skipping that for now.
I think Jos has the relevant code running.]

But RDF/xml's collection syntax expands to these
rdf:_1 rdf:_2 etc. triples, which don't say
enough to come to the relevant conclusion
without doing closed-world stuff.

So there have been some proposals for closing
RDF collections [apologies for not crediting
the sources; I did a little surfing and
couldn't find them]:

* mint a new "end-marker" term; nothing occurs
after the end-marker in a collection.

I don't like that because you can't have a
collection containing the end-marker.

And it grates against my design intuitions generally.


* add a "count" property to bags.

Exploiting a count property involves all sorts
of equality and integer processing that seem
like overkill and/or intractible inferencing.


* add a 'highest index' property to bags:
it tells you the highest index that's used
to relate a collection to one of its members.
This is only slightly better than a "count" property,
to my mind.

None of those seems worth doing to me.

Now we come to the discussion in today's telcon...

In Amsterdam, WebOnt seems to have come to the
conclusion that RDF/xml is an acceptable transfer
syntax, but it shouldn't be regarded as user interface;
authoring tools and "presentation syntaxes" are how
most folks should see WebOnt's language.

So maybe it's OK to just spell out WebOnt constructs
like oneOf longhand, using first/rest/nil
in normal RDF/xml syntax, even though it's
not pretty. [I think PeterPS
sent one of these monsters to WebOnt a while
ago... I can't find it in a few minutes
of surfing.]

Let's call that the first proposal... I dub it 'longhand-OK'.

But Jeremy pretty much talked me out of that:
daml:collection is a pretty mature mechanism
with considerable implementation experience
behind it, and to tell the users "nope; it's
gone. Deal." is quite a step backwards.

So the next proposal is:

  * add parseType="collection" to RDF/xml;

  * add rdf:first, rdf:rest, rdf:nil too.

  * specify that parseType="collection"
  is notation for first/rest/nil triples
  ala daml:collection.

Let's call that parse-collection-STD,
i.e. standardize this way of parsing collections.


[I'm leaving an equivalent of daml:item
out of the proposal; it relates to
rdf:first by inference rules, which don't
belong in the syntax spec; I could
consider rdfs:item ala rdfs:member...
or even using rdfs:member as the
analog of daml:item... but I'm
not proposing that just now.]



Now... let's look at some costs/benefits:


+ longhand-OK is almost no work for RDFCore

- longhand-OK is kinda rude to the folks
  who are using DAML+OIL and considering
  WebOnt; it's not clear that it'll be
  acceptable to the WebOnt WG, let alone
  the (potential) WebOnt user community.

+ parse-collection-STD recognizes the implementation
  experience in the DAML+OIL community

- parse-collection-STD raises the bar for the general
  RDF implementation community, who has been told
  that we're just working out bugs, and is not
  expecting us to demand more features of them.

  (does anybody in the WG know of anybody in
   the general RDF implementation community
   who hasn't already added support for daml:collection?)

- pase-collection-STD introduces more ways to
  write collections; this is more work for our
  primer, more work for RDF users deciding which
  way to go, etc.

- parse-collection-STD puts more work in the
  critical path for getting the RDF/xml syntax
  spec to last call.

- longhand-OK introduces risk that RDF/xml
  syntax spec won't successfully exit last
  call, cuz WebOnt WG (or DAML+OIL users)
  will object.




On balance, I prefer parse-collection-STD right now.
But I need to sleep on it or something to be sure.
Other thoughts? Lynn? Jos? DaveB?



Appendix: some stuff I found while researching
this message. I thought I'd cite them in 
the message, but they didn't turn out to be
directly relevant. But rather than throwing
them away, I think I'll append them.

Entailment and bags (was:Re: Agenda items for the f2f)
From: Pat Hayes (phayes@ai.uwf.edu)
Date: Mon, Feb 04 2002
http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Feb/0072.html

a theory of rdf:Bags
From: Dan Connolly (connolly@w3.org)
Date: Sun, Feb 17 2002
http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Feb/0483

hm... what ever became of "ACTION: 2002-02-15#4 PatH: Send a few
paragraphs to the list to address this" --
http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Feb/0476
that action isn't mentioned in the next week's minutes.

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Friday, 19 April 2002 13:54:44 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:47:33 EDT