Re: ACTION 2001-08-24#9 : issues with containers

Frank,

I suspect that some of the issues you raise are beyond the remit of RDFcore 
to resolve...

At 02:18 PM 8/30/01 -0400, Frank Manola wrote:
>1)  In general, a (perhaps *the*) basic reason we say we can't constrain
>the members of containers is that "anyone can say anything about
>anything".  That means that if a container is specified in some
>collection of RDF, someone somewhere else might assert that there are
>additional items in the collection.  Right?

Well, yes, but that wouldn't necessarily make such an assertion correct, or 
meaningful.  Although the RDF core allows any new statements to be added, I 
think that the intended interpretation for some vocabulary would not 
necessarily yield a valid result.  For example, what about this container:

    [ a rdf:Bag ; rdf:_1 "member A" ; rdf:_1 "member B" ]

I think this violates the intent of the container construct, but is not 
forbidden by the rules of construction of core RDF (and I don't think it 
reasonably can be).

>2)  However, in the specific examples used in Sections 3.1 and 3.2, the
>containers are all anonymous.  So, e.g., in Figure 4 (p95), the model
>that defines the container says that the container has 5 members.  How
>can anyone else assert that there are additional members, since the
>container is anonymous?  Even if there were a gap in the sequence of
>property sequence items, if the container is anonymous, how could you
>assume there were any additional members?

In core RDF, there appears to be no way.  But when used with DAML-like 
constructs (and noting Eric's comment at the F2F that probably the most 
immediately useful feature of DAML being to indicate equivalence between 
two resources) I can imagine being able to say something like:

   "The container whose 1st member is 'X' also contains 'Y' as its 5th member"

>3)  Suppose that the containers are assigned actual URIs, and so even
>though I may define a container with 5 members, someone else could
>assert the existence of additional members.  I hope, even in that case,
>that we're assuming that there is some way to distinguish the members I
>asserted from the ones asserted by someone somewhere else (and possibly
>also to identify who created the container in the first place)?  That
>is, if I assert that I have two children, while it may be possible for
>someone else to say that I in fact have one additional child, normally
>my assertion would be taken as that of a "closed" (having only the
>members I specified) set *as far as I'm concerned*.  Perhaps that
>ability to distinguish who said what is all we need;  Frank said the
>members are a, b, c;  Joe said the members are x, y, z.  The receiver
>gets to decide who the members really are.

This seems to me to be a provenance issue.  I think many folks have 
commented on the desirability of being able to indicate provenance, but 
I've seen no indication that such would be part of the RDF core.

>4)  On the other hand, we might want to explicitly say whether, when I
>defined the container, I *intended* the container to be "closed" (having
>only the members I specified) or "open" (having possibly other
>members).  Note that even if my intention was for the container to be
>closed, that may not (and it probably won't) prevent others from
>asserting additional members (maybe I was wrong);  but it is an
>expression of my intent, and would at least indicate (if any more
>indication was necessary) that I'm not responsible for those other
>members.

I think Pat's "rdf:lastThing" suggestion, or the DAML style collection, 
provide for this.

>5)  It seems to me that if "anyone can say anything about anything", and
>we interpret this to allow anyone to add additional members to
>containers I define which I intended to consider "closed", there ought
>to also be a way for me to express that "closed" intent;  otherwise,
>there's something I can't say about my own container!

I agree that some way to say this would be useful.  I'm not sure if it 
needs to be in the RDF core.

But I'm not clear why containers need to be in the RDF core at all;  the 
DAML work illustrate that alternative container constructs can be 
built.  (The original RDF spec uses containers for its aboutEach over a bag 
of reified statements.  But that seems an ill-considered construct to 
me:  it operates at the XML-syntactic level over a container defined at the 
graph-syntax level.)

...

I think that enforcing consistency of any RDF graph with the properties of 
some arbitrary intended interpretation is beyond our scope.  It was my 
understanding that the price of allowing anybody to say anything about 
anything was that the base language could not enforce such consistency.

In summary, I think the discussion of containers would usefully focus on 
what we can usefully express, rather than being concerned with various 
useless things that can also be expressed.  Some of the issues you raise 
will, I think, be addressed by work that builds upon RDF.

#g
--

>pat hayes wrote:
> >
> > Re: ACTION 2001-08-24#9 Pat: Write up a summary of the issues with 
> containers
> >
>snip
> >
> > 1. There is no way to say that some set of container contents is
> > *all* that is in a container. So it does not follow that all the
> > things that are mentioned as being in a container are all the things
> > there are in the container. Making that assumption might indeed be a
> > Bad Thing as it would be non-monotonic, but allowing an *explicit*
> > way of saying that some things are precisely the things in a
> > container would make the language much more useful and wouldn't
> > create any obvious problems (and is what the XML examples in the M&S
> > strongly seem to suggest, BTW.).  One way would be to provide a way
> > of saying that a container has a certain number of members, but that
> > would require the use of numbers. Or we could introduce a special
> > 'last thing in container' thingie so that if
> >
> > xxx rdf:_n rdf:lastThing
> >
> > then it would follow that
> >
> > xxx rdf:_m yyy
> >
> > would be false for any m>n.
> >
> > It seems to me that in order to be really useful, containers need
> > some such device. Without it they are really only orderings.
> >
>
>--
>Frank Manola                   The MITRE Corporation
>202 Burlington Road, MS A345   Bedford, MA 01730-1420
>mailto:fmanola@mitre.org   voice: 781-271-8147   FAX: 781-271-8752

------------------------------------------------------------
Graham Klyne                    Baltimore Technologies
Strategic Research              Content Security Group
<Graham.Klyne@Baltimore.com>    <http://www.mimesweeper.com>
                                 <http://www.baltimore.com>
------------------------------------------------------------

Received on Tuesday, 4 September 2001 14:49:32 UTC