Re: Clarifications needed for the Collection construct

>Dear Pat,
>I am not sure about the process. What does it mean to close the issue.
>I understand that the issue probably will not be re-opened at this 
>point of time. I also can
>life with the found solution at the moment, but I also hope that 
>this issue will be solved in
>future. If accepting means that the problem will not be stated 
>somewhere, I can not accept it.
>... otherwise I accept the decision.

Thanks, Karsten.

"Closed" in this context means only that this working group (in this 
rather tightly scheduled period between last call and dealing with 
subsequent comments) has decided that it has done all that it is 
going to do about that comment. It is just to enable us to formally 
move to publication of a W3C working note.  It does not mean that 
nobody will ever think about this matter again.


>Best greetings,
>Karsten Tolle
>----- Original Message -----
>From: <>pat hayes
>To: <>
>Cc: <> ; 
>Sent: Saturday, May 03, 2003 1:19 AM
>Subject: Re: Clarifications needed for the Collection construct
>>Dear Pat,
>>sorry for the late reply.
>>I understand why this new collection is included and I agree that there
>>was the need to extend RDF to allow to integrate an upper bound for
>>entailing. What I do not like in the found solution is that we now have
>>the containers with at least a minimum of semantic for it and we have
>>the collection in addition.
>I don't exactly LIKE it myself :-)
>>The collection comes with no semantic and
>>there are no rules given when to use a collection or a container. This will
>>irritate the people that want to create some RDF and will also makes it
>>more difficult to deal with it. This is contra productive!
>>There could have been a property introduced (I think it would still 
>>make sense)
>>that gives the length (number of members) for a container. Of course the
>>processing would be different but it would also guarantee an upper bounding.
>We did discuss this some time back. The problem was, for some 
>people, that having a special 'last thing' in a container would mean 
>that this thing couldn't itself be a real member of a container.
>Another possibility was to associate a number (of items) with a 
>container, but that requires incorporating a numerical datatype into 
>core RDF.
>Still another , which we didn't think of at the time, would be to 
>have a property of membership properties, so that one could write say
>_:x rdf:lastMemberProperty rdf:_17 .
>to indicate that _:x has only 17 things in it. But this kind of 
>'higher-level' assertion is likely to be confusing, and to break a 
>lot of deployed UML-style code.
>None of these is completely satisfactory; and there were no users 
>clamoring to have this feature added in any case, so we felt it was 
>better, and closer to our charter, to adopt the strategy that if it 
>isn't broken, to not try to fix it.
>>This way the collection would not be needed any more.
>The real point is that the collection syntax was explicitly 
>requested by another WG, so we have to include that, whatever we do 
>about containers. And given that the collection syntax is available, 
>it doesn't seem worth 'fixing' the container syntax; particularly as 
>our WG charter explicitly asks us not to make any changes that are 
>not absolutely necessary; and particularly as we had no existing 
>users of the container syntax who positively requested that it be 
>>In case the way of
>>structuring the collection has additional advantages we could think of a
>>mapping between containers and collections.  we would need a container
>>without any meaning and attributes for collections to represent the semantic
>>for the existing container types.
>I tend to agree that this would be a more perfect world, but the 
>exigencies of history have landed us in this one, and it doesn't 
>seem to be bad enough that it is worth the considerable effort to 
>change it.
>Our process requires one of three possibilities at this point. Your 
>reply did not say whether or not you 'accept' our decision. Finding 
>it acceptable is not necessarily approving of it wholeheartedly, 
>notice. If you do accept our decision, then we can close this issue. 
>If you do not, then either we re-open the discussion, or we formally 
>note, and archive, that you do not find our decision acceptable.
>I think it is very unlikely that we will re-open this issue at this 
>stage.  Your call.
>Please reply to this email, copying 
><>  indicating whether this decision 
>is acceptable.
>>Karsten Tolle
>>----- Original Message -----
>>From: "pat hayes" < <> >
>>To: < 
>><> >
>>Cc: < <> >
>>Sent: Tuesday, April 22, 2003 12:30 AM
>>Subject: Re: Clarifications needed for the Collection construct
>>  Dear Karsten'
>>  re. your comment at
>>  <>
>>  The general point you make here can, I think, be summed up by saying
>>  that RDF does not impose any well-formedness conditions on its
>>  collection vocabulary, so that it is possible to write RDF graphs
>>  which make no 'sense' relative to the indicated intended
>>  interpretation of the collection vocabulary. This is correct, as RDF
>>  provides no syntactic constraints of this kind.
>>  You also ask about the reason for introducing the collection
>>  vocabulary. The collection vocabulary was requested by the DAML joint
>>  committee and the Webont WG. The difference between the collection
>>  and container vocabularies lies in the fact that it is possible to
>>  write an RDF graph which entails that the number of things in a
>>  collection has an upper bound, while it is not possible to do that
>>  with the container vocabulary.
>>  We have not made any changes to the document as a result of your
>  > comment. Please reply to this email, copying 
> <>
>  > indicating whether this decision is acceptable.
>>  Pat Hayes
>>  --
>>  ---------------------------------------------------------------------
>>  IHMC (850)434 8903 or (650)494 3973 home
>>  40 South Alcaniz St. (850)202 4416 office
>>  Pensacola (850)202 4440 fax
>>  FL 32501 (850)291 0667 cell
>> <> 
>> <> for spam
>IHMC					(850)434 8903 or (650)494 3973   home
>40 South Alcaniz St.			(850)202 4416   office
>Pensacola              			(850)202 4440   fax
>FL 32501           				(850)291 0667    cell
>   for spam

IHMC					(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola              			(850)202 4440   fax
FL 32501           				(850)291 0667    cell	   for spam

Received on Tuesday, 6 May 2003 17:25:04 UTC