Re[2]: [higgins-dev] schema updates in IdAS (was Re: IdAS API and Higgin

[Valery Kokhan <vkokhan@xxxxxxxxxxxxxx>]

Jim,

On #1, Personally, I'd rather prefer to consider context's schema as an
ontology resource (probably located somewhere in the web like higgins
ontology itself) than as a giant string but even in such case it still
useless.
So, I'll commit proposed interfaces tomorrow. Actually I'd prefer to
commit basic implementation as well but it requires Jena library...
Unfortunately we can't put any third party library to Eclipse CVS
without legal approval which we didn't have for Jena yet... If I
commit my implementation you'll need to download Jena library and put
it to lib folder manually. Would you agree to bear such discomfort?

On #2, It seems to me that we need to have clear understanding what is
context's schema (3) and its difference from context's data (4).

On #3, From my point context's schema consists of subject's
definitions (types of digital subjects, attributes, properties, etc)
which could be used with particular context. Our context's providers
should be able to understand/verify all kind of digital subjects,
attributes, etc defined in context's schema and we shouldn't restrict
people from adding *any* kind of digital subject definition, or from
adding *any* attribute definition to a particular digital subject
type. But we need to define clear rules how to make subject's
definitions for context's schemas.

On #4. At the same time, if we want to have owl representation of
context's data (for example for import/export), it will consists of
subject's instances whose definitions are in context's schema.

Thanks,

Valery

Thursday, October 19, 2006, 12:54:12 AM, you wrote:

>>>> Valery Kokhan <vkokhan@xxxxxxxxxxxxxx> 10/18/06 2:57 PM >>>
>>Thanks Jim!
>>
>>I think that behavior of setSchema() method is responsibility of context
>>providers - in some cases they may try to add new schema to existing one
>>while in others they may replace it. In case of our context provider
>>we're going to allow set up context's schema only once (when it
>>doesn't set yet) and all other attempts will throws an exception.

> I prefer to have some specific rules documented so IdAS consumers
> know what to expect.  On the other hand, a method like setSchema()
> as it is today, is not conducive to making specific and reasonable
> schema updates (such as adding a new attribute definition and
> allowing it to be placed on some different kinds of subjects).

>>Actually, I want to discuss one more thing related to IdAS and
>>context's schemas.

> <snip>
>  
> I actually got two points from your message:

> 1) (what you intended) Schema as a giant string is fairly useless to most IdAS consumers.
> 2) (what I initially thought you were getting at) There is no
> mechanism in the schema that restricts people from adding *any* kind
> of digital subject, or from adding *any* attribute to a digital subject.

> On #1, I agree. I've also been thinking it would be more useful
> from the IdAS consumer point of view to return schema as lists of
> subject definitions, attribute definitions, etc.  If you already
> have interface proposals let's take a look.

> On #2, Tom asked Paul about this some time back, but I don't think
> we resolved anything. In practice, we're doing it like you -- we
> restrict allowed subjects to be those listed in our OWL and restrict
> attributes on them to those specifically named as being in their domain.

> Jim