Sergio, One observation on your modified diagram....what do you mean by 'Resource Model'? In OGSA, we use the terms information model (abstract) and data model (concrete)....we do not use or define resource model since it is an ambiguous term. Ellen Sergio Andreozzi <sergio.andreozzi@cnaf.infn.it> Sent by: ogsa-wg-bounces@ogf.org 11/29/2007 08:34 AM To Michel Drescher <Michel.Drescher@uk.fujitsu.com> cc ogsa-wg <ogsa-wg@ogf.org> Subject Re: [ogsa-wg] Nov 29 - Info Model call minutes Michel Drescher ha scritto:

Folks,

the minutes of the first slot of today's call are available online at: https://forge.gridforum.org/sf/go/doc14951?nav=1

I apologize for having missed the call. I messed up the start time by one hour. Some comments to the minutes:

Ellen expresses her preference for the "three-bubble-diagram"

I understand that the new diagram can be too complex for the purpose of the section. Coming back to my original OGF comments, the main issue was if we should state, by design, that "advertised capabilities and activity requirements all rely on the same resource description" (maybe optional for the managed instances model). This seems to be the way OGF is taking by dropping the JSDL attributes for resource requirements and by moving to XQuery expression against resource representation. If we agree on this, a new proposal for the diagram that maintains the simplicity but that shows this assumption is attached

The group agrees that the UML diagram should not be discarded, but a proper place has to be found in the architeture document.

Ellen recommends to use Sergio's UML diagram in the same document, for example in chapter 5 or the appendix.

ok, I will work on this

Michel has been working with Sergio on modelling guidelines for how to render the GLUE information model into a GLUE XML Schema data model.

The rendering and the guidelines are not complete yet, but the discussions revolve around the usability in XPATH and XQuery expressions.

the current rendering is aligned with the current GLUE Spec. We can work on adding examples of representation of resources and XQuery/XPath expressions Cheers, Sergio

Cheers, Michel

------------------------------------------------------------------------

-- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg

-- Sergio Andreozzi INFN-CNAF, Tel: +39 051 609 2860 Viale Berti Pichat, 6/2 Fax: +39 051 609 2746 40126 Bologna (Italy) Web: http://www.cnaf.infn.it/~andreozzi -- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg

Sergio Andreozzi wrote:

Ellen Stokes ha scritto:

...

One observation on your modified diagram....what do you mean by 'Resource Model'?

In OGSA, we use the terms information model (abstract) and data model (concrete)....we do not use or define resource model since it is an ambiguous term.

yes, Information Model is a better term in that case. GLUE is a possible instance. I attach the modified version.

I think you need to be careful with GLUE since that's very close to defining both an information model and a data model, making it easy to get confused. For example of how they differ, an information model might say that a particular class supports an extensible list of properties (other than the standard set it defines) and the data model would say what format that list of properties must take (e.g. XML document, Java properties format, comma-separated list, etc.) It's the information model that it is important to standardize at the architectural level, since it is fairly easy to code up data model transformations (though those matter much more for specific protocols). Donal.

Sergio Andreozzi wrote:

The aspect of extensibility is secondary to this and is present because is a requirement from many parties. The fact that the abstract GLUE Information Model (represented using the object-oriented constructs of UML Class diagrams) is rendered on different concrete data models (XML Schema, relational and LDAP) makes it difficult to delegate at the concrete data model level the extensibility aspects. "Hooks" are currently present at the information model level and can be used to advertise information that is not currently captured by the specification without waiting for a new spec version. The GLUE Spec is deliberately not rigorous in defining the format of the content of the extensibility points.

My point was that the information model should state what (in general) the information is (e.g. a set of properties) without stating the format of that information (which is the data model's job). At least back in the GLUE session in OGF21 those two aspects were a bit mixed up. (Or at least as far as I could see at the time; I may have got a false impression. :-)) This isn't to say that the data model shouldn't be worked on. Just that the split between the two is important. Donal.