[glue-wg] Capacity representation

[Paul Millar]

Hi Stephen,

On Thursday 10 April 2008 00:32:47 Burke, S (Stephen) wrote:
> Paul Millar [mailto:paul.millar at desy.de] said:
> > As a counter-example, the same is true for the CE-SE-Bind (in
> > whatever form it might take).  This leads no independent existence from
> > the CE and SE it connects, yet is represented as an object.
>
> I'll reply to the rest tomorrow, but just on this since I thought of
> another example: consider a coffee mug. That has a handle, and in
> principle I could consider it as a separate object (I could break it
> off), although for any practical purpose it's only useful when attached
> to the mug. Now consider that the mug has a capacity (I can put 300 ml
> of coffee in it). In that case it clearly makes no sense to consider the
> capacity as having an independent existence of any kind, there's no way
> to detach it from the mug. ("I've often seen a cat without a grin,"
> thought Alice; "but a grin without a cat! It's the most curious thing I
> ever saw in all my life!")

I think this illustrates our different points of view.  If I may summarise 
your position (please correct me if I'm wrong), you see object classes as 
necessarily being something concrete---something you can (in principle) hold 
in your hand (e.g. a cup), or that you could separate and similarly hold in 
your hand.  From your point-of-view, a smile cannot be held in a hand, so 
necessarily cannot be an object.

If so, I see I have a different point-of-view.  For me, an object class is any 
well-defined logical concept defined only by its relationships with other 
object classes and the attributes it may have (there are probably some 
stronger statements one can make).

An object class may (or might not) have an independent life from other 
logically defined concepts.  For example, a smile, whilst having no 
independent life from the mouth it describes, is still a pretty well defined 
concept in most peoples heads.  For example:

	http://images.google.co.uk/images?um=1&hl=en&q=smile&btnG=Search+Images
or, perhaps better results with ESP:
	http://www.captcha.net/esp-search.html

In a "hand wavy" way, the fact that Google or ESP can find a bunch of images 
that people can identify something that's the same ("yep, they're all 
smiling") suggests that there is some common concept that they all have.

There are then two questions:
	a. do we want to model this common feature?
	b. how do we best model this feature?

If the answer to a. is "yes", then the question is how best to model it.  If 
there is no metadata associated with the concept (someone is either smiling 
or they're not), then it could be as an attribute or an attribute value in an 
enumeration.  For example:

	Face:
		smiling <boolean> := true {or false}
or
	Face:
		mouth-posture <open enumeration> := smiling {or shocked, upset,  ...}

If there is metadata to be recorded and we want to keep this as an attribute, 
then this metadata must either be encoded within the attribute value 
(embedding the metadata within the name) or be encoded as associated 
attributes; either:

	Face:
		mouth-posture <open enumeration> := smiling-smirk, smiling-broad, 
smiling-faint, ...

or

	Face:
		mouth-posture <open enumeration> := smiling
		smiling-type <open enumeration> := smirk {or broad, faint, ...}

respectively.  (There may be other ways of recording the information as 
attributes, but I can't think of them just now.)
		
Neither of these solutions is very satisfactory, as it requires the client to 
understand the additional semantics; e.g., if you see "smiling-", split at 
the "-" and treat the second part as a type value; or, if you see "smiling" 
look for the smiling-type attribute, ignore it otherwise.

I would say that the natural solution is to express the information as a new 
object class, subclassing from a generic type, with the attributes you need 
to record.

  Face:
	mouth-posture <mouthPostureType> := smileMouth

  smileMouth extends mouthPostureType:
		smiling-type <open enumeration> := smirk {or broad, faint, ...}

The same information is recorded, but here the structure is made explicit.

One of the goals of modelling is to make community knowledge explicit, so 
writing clients that consume this information is easy.  This is how I see the 
transition from Glue-1.3 to Glue-2.0: GLUE-2.0 should (if feasible) make 
explicit what was previously implicit knowledge (such as, custodial-online, 
means D1T1, means guaranteed to be stored on disk and tape).

>   Similarly with the MappingPolicy: if the mug belongs to me that's an
> access rule, and although other things may belong to me the specific
> "instance" of belonging that applies to the mug is not transferrable or
> shareable

OK, counter example.  When you buy the mug at the shop, they give you a till 
receipt (typically).  That receipt proves that you've bought the mug in the 
store.  If you are challenged whilst leaving the shop, you can produce the 
receipt, proving you've bought that mug.  So the receipt is a concrete object 
that represents your ownership of that mug.

Your ownership is transferable (you give the receipt and mug to someone else 
whilst in the shop, they walk out with the mug) and sharable (a group of 
people all club together to pay for the mug, they sign a document saying they 
have part-share of the ownership, the two documents are stabled together).

> if I own two mugs and give one away it doesn't affect the 
> other one

True, no one suggests that it is should affect the other.

> (rules and capacities may be equal but that doesn't make them 
> identical).

True, again no one is suggesting that two objects with equal properties are 
the same thing.

>   In the case of the CESEBind there is something real underneath, some
> kind of network connection and/or firewall rules and/or policies about
> which protocols are allowed where.

(I fear you're grasping at straws here ;-)  Network infrastructure (networks, 
routers, firewalls, etc...) connects everything together, this isn't special 
about CEs and SEs that they require network connectivity.

> It might well be pointless to publish 
> [network/firewall/policies] without relating it to a CE and an SE, but not
> nonsensical (indeed in principle it's interesting to know it for a UI).

Yes, indeed.  In effect the CE-SE bind is some summary information, giving a 
brief describion of the "connectivity" between a CE and an SE.  It summaries 
the network topology, configuration and policies that would be (potentially) 
too complex to represent explicitly.

But, going back to your original point: I can't hold a CE-SE bind in my hand, 
but I can hold a network cable in my hand, likewise a switch, router (if not 
too heavy).  If I followed your argument to its logical conclusion (and if I 
understand it correctly), I should replace CE-SE bind objects with a 
description of the networking (routers, switches, cabling) and allow jobs to 
deduce which SE they should use.

>   For that matter you could say the same about e.g. the AccessProtocol:
> we wouldn't publish one independently of an SE, and indeed we can't
> because it only has a LocalID. Nevertheless it does deserve to be an
> object and not just an attribute of something else because it describes
> a discrete part of the SE, much like the handle of a mug.

OK, I accept the analogy: comparing an AccessProtocol to a handle of a mug 
(more or less) works, although there's a few questions about the similarity 
of snapping off the handle vs. "detaching" an AccessProtocol.

But, this then leads to the question: what is it about the handle of a mug 
that means you're happy describing it with an object?

Sorry for the noise, but I don't understand!

Cheers,

Paul.