Thoughts about Collections

[jeshaw2]

Paolo;  Thanks.  This is going well I think.

Well, technically the Tag is not the Item, so it can come from anywhere.  It's not even the function of the Collector to find the Tag, they just have to accept it.  The object asking to add the Item provides the Tag.  How it got it is its business.

We trust that, having received the tag, the collection will have some mechanism for keeping the tag visible and associated with the Item it identifies? (This is also needed to test isUnique and to support isOrdered.)

A Key uniquely identifies the Row in the Table, the Item in the Collection.

Sounds like a Primary Key to me?

The enumeration literal name is scoped within and must be unique within its enumeration

Sounds similar to SQL's SELECT ... DISTINCT capability.

Quote:Where you do not have ordering, you can also have all the operations of unTagged Collections (see below).  
 
Gee! Can't I, at least, have some of them? Wondering if the uniqueness impacts their availability?

Yes, that was exactly my assessment, uniqueness robs you of their availability.

But I can have some restricted access to support Priority queues?

procedural   concerned with how to manipulate symbols, concepts, and rules to accomplish a task or solve a problem
declarative    concerned with the recall of facts and events
In a declarative request, I ask the system to return me some result.  The System figures out how to do it.
In a procedural request, I have to tell the system how to return me the result.  You can better appreciate the difference by comparing a DBMS stored procedure to a DBMS select statement.

So, in my CIM model, I might include some dynamic diagrams to support the procedural request, but probably not for the declarative?

Might I suggest Priority Queues?  
 
Yeah, I looked at them before I moved them out.  I couldn't see how they differed from sufficiently from a normal queue to warrant their own type.  They are certainly a specialization of Queue.  Do we have a new Feature... Prioritiser?

Well, it seems natural to access a priority queue in the same way as we access a normal queue.   I wouldn't want to burden the accessor with prioritizing responsibilities.  But we now have a queue that would allow the Prioritizer to add in middle to supporting an ordering that is not purely FIFO. (Perhaps a FIFO ordering within a priority level.)

[jeshaw2]

In order for the notions of isOrdered an/or isUnique to be applicable, each item in the collection must expose or provide or be associated with a Tag for this purpose.

I must admit that the first time I saw the term Tag in the above context, I almost confused it with the concept of UML Tagged Values.  I have a natural aversion to overloading terms in technical documents.

Instead of Tag, might I suggest another term, such as Moniker?

[Paolo F Cantoni]

I must admit that the first time I saw the term Tag in the above context, I almost confused it with the concept of UML Tagged Values.  I have a natural aversion to overloading terms in technical documents.

Instead of Tag, might I suggest another term, such as Moniker?

I've no particular penchant for Tag.  But...

There are two basic types of Collections:
Monikered and Unmonikered  
...sounds a bit naff, as the Brits say...

How about I see your Moniker, and raise a Label?

Paolo  

[jeshaw2]

How about I see your Moniker, and raise a Label?

For me, Label carries more of a burden than Tag  

I'll see your Label and check for a bit.  *Headed for my Thesaurus*  

[Paolo F Cantoni]

Paolo;  Thanks.  This is going well I think.

Yes, I agree.  But what about others?  I think Jim and I would like feedback.

We trust that, having received the tag, the collection will have some mechanism for keeping the tag visible and associated with the Item it identifies? (This is also needed to test isUnique and to support isOrdered.)

Yes.  This is implicit in Tagged(Labelled) Collections.

Sounds like a Primary Key to me?

I don't want to publish my monograph on DB keys and Indexes, unless specifically requested.  But just like we are doing with Collections, it presents a Unified Theory of Keys and Indexes and their names that clarifies the terms very precisely.  In that Ontology, a Key is a unique identifier (A primary Key is just one of these).

Sounds similar to SQL's SELECT ... DISTINCT capability.

Precisely.

But I can have some restricted access to support Priority queues?

No, you can't you naughty boy!  Take your medicine like a man!  Even in a priority queue, you put things in at one end and get them out at the other...  It's what goes on inside the queue - to which you don't have access that's the real issue.

I suspect we can handle this by saying that just as Stacks have special operations: Push & Pop.  A Queue also has special operations:  Enqueue and Dequeue.  The Enqueue operation can be defined to determine where in the collection, the Enqueued Item will go.  Dequeue just takes the Item off the end.  The action of Enqueue can be determined by the Prioritization Policy (which could be quite complex).

How does that sound?

So, in my CIM model, I might include some dynamic diagrams to support the procedural request, but probably not for the declarative?

No, you can have diagrams for both.  My point is really that because the Indexer and Enumerator are essentially declarative, they operate at the (mathematical) Set level and can return manifold Items at a time.  The Iterator only returns one Item at a time.

Well, it seems natural to access a priority queue in the same way as we access a normal queue.   I wouldn't want to burden the accessor with prioritizing responsibilities.  But we now have a queue that would allow the Prioritizer to add in middle to supporting an ordering that is not purely FIFO. (Perhaps a FIFO ordering within a priority level.)

This should have been dealt with above.

Paolo

[jeshaw2]

Quote:But I can have some restricted access to support Priority queues?  
 
No, you can't you naughty boy!  Take your medicine like a man!  Even in a priority queue, you put things in at one end and get them out at the other...  It's what goes on inside the queue - to which you don't have access that's the real issue.
 
I suspect we can handle this by saying that just as Stacks have special operations: Push & Pop.  A Queue also has special operations:  Enqueue and Dequeue.  The Enqueue operation can be defined to determine where in the collection, the Enqueued Item will go.  Dequeue just takes the Item off the end.  The action of Enqueue can be determined by the Prioritization Policy (which could be quite complex).
 
How does that sound?

Oh man!!!  I wanted to play too!    Well, as long as I have some pretty buttons to push, I'll get by ... I think.  

I like the pretty Enqueue button.    Is it <<Stereotyped>>

[jeshaw2]

I don't want to publish my monograph on DB keys and Indexes, unless specifically requested.  But just like we are doing with Collections, it presents a Unified Theory of Keys and Indexes and their names that clarifies the terms very precisely.  In that Ontology, a Key is a unique identifier (A primary Key is just one of these).

Well I, for one, am interested!  That topic seems to be relevant to our discussions here and it would be useful to get those terms clarified too.

Is anyone else in this forum interested?

[jeshaw2]

Paolo;

I've been giving thought to your Tags and an Item's opaqueness trying to imagine what their UML notations might be.  That triggered some questions:

In your Ontology, does the concept of an Interface exist at the UML Level?  I'm thinking that there might be some utility for implementing Tags with them.

RE:  Items being opaque.  If the association is navigable from the Collection end, as I think is it must be for the collection to be useful, why is the Item so opaque that a tag construct is needed?

[Paolo F Cantoni]

Paolo;

I've been giving thought to your Tags and an Item's opaqueness trying to imagine what their UML notations might be.  That triggered some questions:

In your Ontology, does the concept of an Interface exist at the UML Level?  I'm thinking that there might be some utility for implementing Tags with them.

RE:  Items being opaque.  If the association is navigable from the Collection end, as I think is it must be for the collection to be useful, why is the Item so opaque that a tag construct is needed?

Two issues here I think Jim,

1) I used the word Opaque to imply that there is nothing special in the Item to make it part of the Collection.   The Item is what it is.  The Collector has to use whatever the Item exposes in order to determine (according to its Policies) whether the Item should be accepted into the collection or not.  With hindsight, Opaque may not have been the best word. The Item has an Interface which the needs to provide everything the Collector needs to manipulate the Item successfully.  Does this clarify things?

2) Tags are used to provide Associativity.  In an Associative Collection, the Collector (Sgt Schultz) says:  About the Item, "I know Nozzink"; but give me the Tag and I'll get the associated Item for you.  The Tag can be arbitrary and may contain no information directly related to the Item.  Associative Collections are built with two parts for each slot - the Tag and the Item (or reference thereto).

Paolo

[size=0]©2005 Paolo Cantoni, -Semantica-[/size]

[jeshaw2]

Paolo;

Once we have Tags, if the there can only be unique Tags in the Collection, then the Tag acts as a Key (uniqueness constraint). Such Collections are known as Enumerations.

In addition, where the Item contains an attribute whose values are an Enumeration one can define an:
Enumerator: Retrieves one or more items at a time by applying a filter on an Enumerable property of the Items.

sounds similar to SQL's ... DISTINCT capability
Precisely.

I submit that a requirement for collected parts to have an Enumeration attribute is not a requirement of an Enumerator. The Enumerator may certainly return an Enumeration by applying a Distinctness filter to the collection.  The Tags in the returned collection would then, of necessity, be unique, not necessarily the Parts themselves.  

Further, I would suggest that a collection's isEnumerable property would be true if an Enumerator is defined for the collection.

[lex_cz]

Hi,
some thoughts that came into my mind while reading this interesting discussion.

I think maybe a better idea to describe the all possible collections would be gen-spec instead of a "Collection subtype" x "Policy" table. Ie. the mother of all collections is: Collection (defined as collection of elements of some type, where collection implements methods(policies) eg. Add (not defined if at start, end,...), Del (not defined if from start, end, ...), Iterate)
Subtype of Collection is eg. CollectionIndexed (defined as Collection with additional method GetAt (returns an element thats nth) )
Another subtype is eg. CollectionOrdered (defined as Collection where elements must support the less, greater methods and when calling Iterate() the next element is always greater or equal than the previous)
Another subtype is eg. CollectionUnique (defined as Collection where elements must be unique = elements must support the equals method and there are no elements elem1, elem2 such that elem1 = elem2)
Etc.

Usage in PIM should be easy than. When I write in the model: CollectionUnique, in PSM must be used some sort of CCollectionUnique or subtype of CollectionUnique but not CCollection.

Regards Martin

[Paolo F Cantoni]

Paolo;
[size=13][SNIP][/size]
I submit that a requirement for collected parts to have an Enumeration attribute is not a requirement of an Enumerator. The Enumerator may certainly return an Enumeration by applying a Distinctness filter to the collection.  The Tags in the returned collection would then, of necessity, be unique, not necessarily the Parts themselves.  

Further, I would suggest that a collection's isEnumerable property would be true if an Enumerator is defined for the collection.

To part 1 of your post, Jim:
Do we agree that Iterators and Indexers work on the Items?  If so, then so must the Enumerator.

If we allow (as I think we've now agreed) an Indexer to return multiple items.  Then I could probably substitute an (equivalent) Indexer for every Enumerator (of the type I've previously defined).

However, you've sparked an idea with the "SELECT DISTINCT".  Perhaps the Enumerator should return the Set (unique) of a particular Enumerated Property in the Item.  For example:
I have 12 Red pebbles, 6 Green, 2 Blue.  The Colour attribute has 8 possible values.
The enumerator would return the Set: Red,Green,Blue - since these were the only values in this collection at this time.

This would make the Enumerator sufficiently distinct from the Indexer and still keep the notion of Enumeration.

If this isn't what you'd like the Enumerator to do, can you spell it out with an example?

To the second part:

This seems a logical consequence.

I presume that the isIndexable and isIterable would come under the same banner?

I haven't worked out yet whether a Collection is Iterable (by definition).  I suspect it is, but I haven't worked out the proof yet.

HTH,
Paolo

[size=0]©2005 Paolo Cantoni, -Semantica-[/size]

[jeshaw2]

Martin;

Welcome to the discussion, glad to have you in here.  

You raise some interesting points and I confess that, early on, I had similar ideas.  You arguments (as you say) are relative to models at the PIM and PSM level of abstraction.  There it is permissible to think in terms of how collections may be implemented in code and how the computations might go forward in methods.

Paolo and I haven't gotten that far yet.  We are discussing collections in terms that do not allude to how the collections are implemented within a computer.  In our discussion time-line, we have yet to make a decision to use a computer for system's implementation.  Our models would also apply to a non-automated (manual) technology too.  But be it automated, or non-automated, we don't foreclose on any options until we leave the CIM level and head for the PIM level of modeling. In the Top-down, Bottom-up methodology, we are at the first step, you are at the second step.  Therefore, we are denied use of the concepts you find so useful.

[jeshaw2]

Paolo;

Do we agree that Iterators and Indexers work on the Items?  If so, then so must the Enumerator.

Agreed. But if a Tag is available in the collection it may contain information of interest not in the Item, I don't see any reason why the accessors can't work on Tags also.

If we allow (as I think we've now agreed) an Indexer to return multiple items.  Then I could probably substitute an (equivalent) Indexer for every Enumerator (of the type I've previously defined).

(We have so agreed) and yes an equivalent Indexer could be substituted.  I see an Enumerator as a specialization of an Indexer, at least in terms of the derived collection, but I'm keeping my thoughts open on this. I havent fully evaluated the possibilities of your filter concept.

However, you've sparked an idea with the "SELECT DISTINCT".  Perhaps the Enumerator should return the Set (unique) of a particular Enumerated Property in the Item.  For example:
I have 12 Red pebbles, 6 Green, 2 Blue.  The Colour attribute has 8 possible values.
The enumerator would return the Set: Red,Green,Blue - since these were the only values in this collection at this time.

This is a good illustration of the nature of the Enumerator's specialization.  It also conforms to my earlier stated specifications which allows an enumeration to be derived, by an enumerator, from any base collection type.

If this isn't what you'd like the Enumerator to do, can you spell it out with an example?

 No need, its what I expect of an Enumerator.

I presume that the isIndexable and isIterable would come under the same banner?

That is my view.

I haven't worked out yet whether a Collection is Iterable (by definition).

By definition?  In my view, probably not at the CIM level.  In the real-world, except for queues at the bank teller's window, few of the parts of a collection are conveniently lined up in a ordinal fashion.  

Just as I assert a required presence of an Enumerator object for isEnumerable to be true, I also assert the required presence of an Indexer object and Iterator object.  I think of isEnumerable, isIndexable and isIterable a interfaces which define a method which returns a reference to the respective Enumerator, Indexer, or Iterator object that is nested within the collection.
Collections having such access objects implement the appropriate interfaces (note the plurality here).

BTW:  I now see Trees as a specalization of Linked-lists which in turn is a specalization of a List.  I no longer think of trees as a base collection type.

[Paolo F Cantoni]

Looks like we're in violent agreement again!      

(I also came to the same conclusion as you wrt to Trees.)

Also, did I understand you correctly as agreeing with me that a collection need not be Iterable?

If so, that means that Deque, Stack and Queue are not Iterable by default.  One may provide an Iterator (or do you believe you shouldn't be able to); but if you don't, you can only use their default Interface which doesn't include one - thus confirming our restricted access Policy.

Paolo

[size=0]©2005 Paolo Cantoni, -Semantica-[/size]