Re: What is the most common type of collection or container?

At 13:01 10/11/03 +0200, Patrick Stickler wrote:
> >
> > I tend to use the collection syntax, because they're "closed"
>
>This is actually a claim that has been bugging me for some time. From what
>I can see, unless you manage the source of every statement, such that you
>can differentiate between one assertion and another based on their source
>(and thereby, authority, trustworthiness, etc.), the best you can do is
>identify a conflict in the definition of a collection, but you'd not be able
>to resolve it. You'd e.g. have multiple assertions for rdf:first or rdf:next
>and even though you know they can't all be right, you wouldn't know *which*
>was right.
>
>RDF Lists aren't really "closed" (i.e. immutable).

This is true ... maybe "closed" isn't the best term.

The issue I see isn't really immutability per se, but preservation of 
monotonic semantics.

The situation I was concerned with was a collection used as the antecedent 
for some inference.  In order to ensure that RDF's monotonic semantics was 
properly honoured, it was important in some situations that additional 
values cannot be added to some collections while having them remain 
indistinguishable from valid collections, because this could lead to a 
situation where adding a statement invalidates a previous inference.

Collections avoid this by allowing (in principle) that any ill-formed 
collection be interpreted as False, so the entailment of any conclusions 
obtained from a valid subset of the graph would still hold, if only by the 
rather weak means of ex falso quodlibet.  So monotonicity is preserved.

As a practical matter, I find that the intermediate nodes in a collection 
tend to be bnodes (which, remember, are distinct from any nodes in any 
other graph), so the prospect of uncontrolled addition of statements about 
the nodes in a collection is somewhat remote.

#g


------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

Received on Tuesday, 11 November 2003 10:21:22 UTC