[Oslc-recon] Proposed addition to the specification for representation and reconciliation of clusters

[John Arwe]

> Various IBM product development teams are implementing the 
> Reconciliation spec and would like to represent the concept of 
"Cluster". 
> Concrete examples being (1) the machines in a failover/load balancing 
> group, (2) a set of application servers or (3) even more generically,  a 

> group of resources as defined by a user. 

Note: I added (#)s in the pasted text above.
(1) seems appropriate for Reconciliation - availability, performance, D/R 
status, automation (running commands) are common ways of looking 
at/operating on those groups, and are typically done by independent 
implementations.
(2) is less clear.  lots of sets are not usefully shared.
(3) even less clear; once you qualify it that way, I get a stronger 
impression that it's the notional equivalent of reblogging something, or 
liking/friending it, or arranging widgets on my home page.  All of those 
actions implicitly or explicitly define groups.  Most of them make zero 
sense to reconcile.

This seems vulnerable to mission creep.  For many (3) cases and some 
subset of (2), I'd say use foaf:Group (or rdfs:Container, or 
ldp:Container) and you're done.  No need for reconciliation in those.

> The use case is that service provider would advertise its knowledge 
> of a cluster and its members and clients would query for provider 
> specific data or issue commands against that cluster. 

That is an interaction model summary, not a use case.  As an interaction 
model, I'm not seeing any difference versus the (existing) OSLC query 
capability model.  Nothing in there requires reconciliation either, as 
only a single provider is involved.  If multiple implementations are 
likely to expose these beasts, that might justify defining a common type 
however so clients are not forced to couple to implementation-specific 
types.

> Multiple service providers could know about this cluster and we 
> would also need to discuss rules for reconciling cluster instances 
> coming from multiple sources. 

I think the ONLY cases for which you need to worry about reconciliation is 
when multiple providers Will know about it, so "could" seems like a 
strange formulation.  Our specs should be based on concrete cases, not 
hypotheticals.

> Internally, IBM is using rdfs:Container and rdfs:member to represent
> a group of systems but also wants to indicate that this is a cluster
> in the IT specific sense. 

Ok.  What does a cluster give me that a Container does not?
If we cannot clearly differentiate them, then why would we invent the 
second?
(to be fair: I'm intentionally taking a Devil's Advocate position here - 
more stuff == more complexity.  added complexity must be justified.)

> The proposal is to add to CRTV the resource type http://open-
> services.net/ns/crtv#Cluster with description "A set of connected 
> systems (either physical or logical) that work together such that 
> the set can be viewed as a single system" 

That sounds exactly like the definition of foaf:Group [fg], once you read 
past "systems" (so general as to have little meaning), "physical or 
logical" (what isn't, and yet is still relevant to the IT management space 
CRTV is in).
It sounds only subtly different than rdfs:Container (which is silent on 
how the members are related).
To be clear, I'm not objecting strongly to the addition (yet); given that 
we have these "similar but apparently different" terms, if we do decide 
that another is justified then we do need to clearly differentiate so 
normal people can figure out when to choose CRTV's vs one of the 
alternatives.

> We'll also need to discuss whether we should be even more specific 
> and create resource types for example crtv#MicrosoftFailoverCluster 
> or crtv#ZsystemCICSPlex 

I do not think it is appropriate to define vendor-specific *anything* in 
OSLC.
Those belong in namespaces owned and controlled by the relevant vendors.
Since not all vendors will be in OSLC (now, or possibly ever), that 
implies that until they own up to their responsibility(ies), 
interoperability will be limited.  Could we possibly re-use types/URIs 
defined by them in other venues?  DMTF CIM comes to mind.  Perhaps this is 
something for Core to discuss; I have not heard this come up from other 
WGs, but it might have.

If we assume for the moment that someone (anyone, including this WG) 
defines such URIs today/tomorrow, and the day after one of the vendors 
steps up and defines (authoritative) types for what they own, then 
reconciling implementations would have to decide how to handle this 
(resources might have any combination/subset of equivalent type URIs).

> I think that a crtv:Cluster type makes sense, since this is itself 
> an IT resource, not just an arbitrary grouping of resources. 

I presume with arbitrary you are alluding to rdfs:Container; fair enough.
I don't think it's as easy to dismiss foaf:Group given it's 
membershipClass property, but there might still be a sensible reason that 
these are different.
I also have a gut reaction that Cluster is reasonable, it's pinning down 
why that is (how it differs from the others) that is proving hard for me.

> crtv:name seems like a good identifying property. 

Unless you are assuming that name is a namespace-qualified value, and the 
namespaces follow the delegation of authority pattern associated with 
domain names, I don't see how that addresses (3) at all.  I suspect if we 
drilled into (2) there is a subset in there that is equally problematic.

> Subtypes might 
> make sense if different identifying propertes are needed for 
> different subtypes or if the same name can exist in different 
> clusters of different types. 

I don't see how Clusters (without further subtyping) could possibly be 
reconcilable then.  Once you allow for dup names across different 
clusters, you've said that Clusters don't reconcile.  Which is OK, but it 
conflicts with your statement above wrt crtv:name.

> Reuse of rdfs:member for cluster members makes sense, although, I 
> don't really see the need for the rdfs:Container rdf:type, since 
> crtv:Cluster itself is presumably defined as making use of the 
> rdfs:member property. As I mentioned above, these are real-world IT 
> resources and not arbitrary groupings.

That definition (crtv:Cluster expresses membership via rdfs:member) would 
be part of the Reconciliation spec, not the RDFS Class definition.

I'll also note that W3C is working on general linked data containers, 
whose membership predicates need not be rdfs:member.  It's not clear 
how/if those would relate to what you're doing here. [ldp]

> For reconciliation, we need a way to determine if Cluster1 from 
> service provider 1  is the same object as Cluster2 from service 
> provider 2.  We could posit that if Cluster1.crtv#name is 
> the same as Cluster2.crtv#name then Cluster1 and Cluster represent 
> the same object. Any other potential rules ? 

Once you admit (3), I don't see this being sufficient.  (2) might also 
break it.

> I think crtv:name will not be sufficient to uniquely identify a 
> cluster when there are different types of clusters in the 
> environment.   Some clusters (e.g.  Microsoft Server Clusters)  have
> user-defined cluster names and, if administrators across different 
> cluster types do not coordinate their naming conventions, there 
> could be conflicts if the same user-defined name is chosen. 
> Therefore,  it may be best to use a combination of crtv:name and a 
> subtype for the naming rule. 

> I think that just means that the crtv type should be the subtype, 
> rather then Cluster, and the identification rule should be defined 
> for each subtype.

I think that means Cluster (alone) is not reconcilable.  Which is fine, it 
just means that (assuming we decide to keep it) it lives in the vocabulary 
but not the Reconciliation spec, which is not a new case.

> Another approach would be to define a special property (e.g. 
> crtv:clusterType) which can be used as an identifying property, 
> rather than rdf:type. 

IMO the world has enough names for the semantic "type"; ditto description, 
title, etc.  Adding more does not help the world, it's just more 
(gratuitous IMO) complexity.

> If we try to use rdf:type as an identifying property and these 
> resources all have rdf:type Cluster, then they will reconcile even 
> if they have other subtype rdf:type values that are different.

"we" who?  As I remember, the Reconciliation spec defines the *inputs* for 
reconciliation, not the method by which it is accomplished.  It's 
perfectly reasonable to say that some types are irreconcilable... e.g. any 
not listed in the Reconciliation spec.  That's exactly the case for the 
vast majority of types (even "just RDF types") in existence today.  Every 
RDF resource has an (implicit) type of rdf:Resource, so (trivially) this 
case already exists and apparently implementations are capable of 
tolerating it, given that 2.0 has implementation reports and no mention of 
this problem to date.



[fg] http://xmlns.com/foaf/spec/#term_Group
[ldp] http://www.w3.org/TR/ldp/

Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-recon_open-services.net/attachments/20130917/71908939/attachment-0003.html>