RE: [higgins-dev] Changes to IdAS.model utility package

["Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>]

Actually, we discussed this in the F2F; I should have been more clear. The
concept is this: the consumer who wishes to know about a given attribute
instance A (e.g. http://example.com/email) has to: (a) find the containing
IContext of the object (e.g. Digital Subject) that has A, (b) pass BOTH the
Attribute type URI AND the IContext instance to the IdAS.model utility
package. You are correct that the utility package must first search for
local, context-dependent metadata about A from IContext, but if it can't
find any then it can attempt to do a GET on A to read a global metadata
description document that is in HOWL format (HOWL = OWL that imports
higgins.owl).

-Paul

> -----Original Message-----
> From: Valery Kokhan [mailto:vkokhan@xxxxxxxxxxxxxx]
> Sent: Friday, February 02, 2007 10:06 AM
> To: Paul Trevithick
> Cc: Higgins (Trust Framework) Project developer discussions
> Subject: Re: [higgins-dev] Changes to IdAS.model utility package
> 
> Hi Paul,
> 
> I do not know their motivations but I'm afraid such design will not
> work. At first thought about similar approach but then... Have you
> ever took into account that definition of, say, an attribute could be
> context dependent? What I mean is that the same attribute (for example
> "email") could be required in one digital subject while in another
> not. Or one digital subject could contains only one "email" attribute
> while another may contains more then one. It appears impossible to
> obtain complete information about attribute without information about
> digital subject it belongs to.


> 
> Valery
> 
> Thursday, February 1, 2007, 5:56:08 AM, you wrote:
> 
> > Valery,
> 
> > At the F2F Raj (IBM) and Tom (Novell) both suggested a change to the
> design
> > of your proposed IdAS model package. The proposal was that if the IdAS
> > consumer wants to inspect the model of, say, an attribute we would make
> this
> > an explicit two step: first, the consumer would look up the type (URI)
> of
> > the attribute and second it would hand this URI to the .model package to
> get
> > back its model.
> 
> > This is a change from your current design. Beyond Raj and Tom's
> motivations,
> > this approach has one distinct advantage over your current proposal
> wherein
> > the attribute can be directly queried as to its model (in one step
> instead
> > of two). The advantage that I see is that it allows us to support a new
> > possibility: where the attribute's "model" metadata not managed locally
> by
> > the Context Provider (e.g. as retrievable by our 'getSchema' method),
> but in
> > fact exists as metadata document retrievable by dereferencing the
> > attribute's type URI (URL in this case) and using either WS-Addressing
> to
> > retrieve the attribute's type metadata or doing an HTTP GET and reading
> an
> > XRDS document.
> 
> > The consumer would pass the URI to a general purpose query method in the
> > IdAS.model package and it would (a) first search for the local schema
> for
> > this attribute's containing Context, and then if it didn't find any OWL
> > metadata "about" this URI, would then (b) attempt to dynamically
> retrieve
> > the OWL metadata by dereferencing the URI and using WS-Addressing or
> OASIS
> > XRI/XRDS as described above.
> 
> > We do NOT need to implement (b) right now. I'm only adding support for
> Tom
> > and Raj's suggestion that we decouple the .model package a bit, use the
> two
> > step lookup method, and have a more general purpose query method in the
> > .model package.
> 
> > -Paul
> 
> 
> > _______________________________________________
> > higgins-dev mailing list
> > higgins-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/higgins-dev