> The only way to represent extra information
about the model of context elements is to revise these interfaces.
> For example, say there's a need to associate an image with the
attribute called
>
“http://example.com/some/name/space#telephoneNumber” (this image might be
used by a management UI).
> To
make that association we need a new method like
IAttributeModel.getManagementImage().
There is a
problem in your new proposed model. We need to know there is such
an image
associated with “http://example.com/some/name/space#telephoneNumber”
attribute. In other words we need to know about
“http://example.com#telephoneNumber_Image” property, which we
can use to get an image. As a result, we need additional schema with information
about this property (i.e. additional schema which will be used to
describe an HOWL schema).
From the other
hand, for existent IdAS, information about an image would be
represented using metadata of attribute. IMetadataModel interface should be
used to know there is “http://example.com#telephoneNumber_Image” metadata
for “http://example.com/some/name/space#telephoneNumber” attribute. In this case
both, the metadata type and the value of metadata of this
type can be provided by the same HOWL schema. In the other words,
IModel interfaces should describe which kind of nodes, attributes,
metadata, values can the context contain, but real
data (including image for attribute) should be represented by other
interfaces.
----- Original Message -----
Sent: Wednesday, March 05, 2008 11:02
PM
Subject: Re: [higgins-dev] preliminary
work on "IdAS data model asnodes"
Sergey,
I
updated the page with a more complete problem description. I'll repeat
it here:
Today,
IdAS defines a set of special interfaces for accessing a context's model
elements. There are a number of problems with these interfaces:
1. They are 'fixed' in nature. The only way to
represent extra information about the model of context elements is to revise
these interfaces. For example, say there's a need to associate an image with
the attribute
called “http://example.com/some/name/space#telephoneNumber” (this
image might be used by a management UI). To make that association we need a
new method like IAttributeModel.getManagementImage().
1. Even if we
felt like it's ok to revise the current I*Model interfaces, we do not know
what kinds of information will need to be associated with the models of
elements in a context. It may be the case that some people will have needs
that we think are unworthy of revising the interfaces for. For example, say
someone wants to associate an astrological symbol to each different attribute
model. Does that mean we should add a new
IAttributeModel.getAstrologicalSymbol()?
2. There is no way to update a context's model. We
have a need to be able to add models for new node types, attribute types and
so-on. We also need to be able to change existing models (such as changing the
cardinality of an attribute). Also, we may need to remove models.
3. We cannot look up a model with partial
information. For example, say I know there's an attribute with the word
"telephoneNumber" in its ID, but I don't know the entire ID. It would be nice
to be able to have a way to find what I need without enumerating through the
entire set of attribute models.
>>> "Sergey Lyakhov"
<slyakhov@xxxxxxxxxxxxxx> 03/03/08 12:15 PM >>>
> I’m interested
in the “direction you are going” because XDI also has the
requirement to be self-describing. I like what you’ve done so far. Keep going.
We already have a set
of well-defined IModel interfaces which describe the context
perfectly. Is there any reason/benefits to replace the existent
model with a new proposed?
> It may be better to not
define special interfaces for this purpose, but instead simply re-use the
existing
> interfaces that are used
to access normal information within a Context (nodes and their attributes).
Why it is better to use INode
interface to describe a model of IContext, IAttribute,
IAttributeValue and others? Really, we see only disadvantages in
describing a context model in such a way. Using of new
model does not look convenient for a user. For an
example, he will need to investigate a complicated
sructure of INode instances to know the list of possible values
of simple attribute (defined by owl:oneOf data
range). Moreover, in case of such a model we
need to create a new special schema to describe HOWL
schema. So, we think that re-using of INode interface is not a
reason to reject existent IModel interfaces. I only agree with "top node". It
will be helpful to add getTopNodeModel() method to IContextModel
interface, and getSuperNodeModel() and getSubNodeModels() methods to
INodeModel interface.
----- Original Message -----
Sent: Friday,
February 29, 2008 6:45 AM
Subject: RE:
[higgins-dev] preliminary work on "IdAS data model as nodes"
I’m interested in
the “direction you are going” because XDI also has the requirement
to be self-describing. I like what you’ve done so far. Keep going.
On a number of occasions,
I've mentioned my desire to explore the notion of using existing IdAS APIs
to access a context's data model (schema).
This page (
is a start, but it
needs polish. It has a number of known (to mee) problems that
need to be dealt with. I just thought I'd mention it in case
anyone is interested in at least seeing the direction I'm going.
_______________________________________________
higgins-dev
mailing
list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________
higgins-dev mailing
list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
