[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[higgins-dev] New IdAS Model Interfaces [WAS: Re: Improved i-card.owl checked in]

Title: New IdAS Model Interfaces [WAS: Re: Improved i-card.owl checked in]

Sorry. I haven’t been very clear. Let me try again here.

The changes that we’ve made in the Context Data Model 1.1, and implemented in IdAS mean that we now have a data model that can represent RDF graphs as CDM entities, simple (literal) attributes and complex (entity-valued) attributes in a very natural way. This opens up the possibility of CDM/IdAS contexts containing not just “instance” data (e.g. the (entity attribute attribute-value) statement (paul eyeColor green)) but also statements like (paul rdf:type :Person) and, more to the point of what we are discussing here, statements about the Person class itself. And of course of this is exactly how things are done in in the world of RDF.

I’m proposing that we model in CDM classes of entities and kinds of attributes using entities and attributes. We would use the URI rdf:type to link an instance entity to its class entity(ies). And we would use various RDF vocabularies to describe these classes of entities and attributes. All that remains for us (e.g. me) to do is to document on the CDM page on the Higgins wiki exactly which vocabularies we are using, and which parts of them. The obvious choice is to use the RDFS vocabulary. Some of OWL is may be useful. I find that parts of the SPIN (see http://spinrdf.org) vocabulary may also be extremely useful. SPIN introduces ways to model closed-world, OOP concepts of classes and attributes that I think Context CP developers will find familiar and useful, which still allowing open world models like native RDF.

With this approach no further changes are required to IdAS, and we don’t need the current Model interfaces. What does change with this approach is that if a context developer wants to express the “class” aspects of the entity and attribute instances in their context data set, they would need to populate their context (or some context) with yet more entities that describe classes of entities and attributes (e.g. as owl:Classes, owl:DatatypeProperties and owl:ObjectProperties). If they do this, the the existing Higgins IdAS 1.1 API can be used to inspect and navigate these “class” entities.


On 10/20/09 11:07 AM, "Sergey Lyakhov" <slyakhov@xxxxxxxxxxxxxx> wrote:


>> Actually, Model API could correctly treat a polymorphism in a schema. Are you going to replace it with a model proposed by
>> Jim a year ago (I and Valery think it is not convenient to use it) or plain just to use owl schema instead of Model API?

> ## I have yet another idea up my sleeve. Valery probably won’t like it either, but we’ll see. I’ll let you know within 1 week.
When I wrote  "...replaces IModel interfaces with something you were going to propose" here http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg06101.html <http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg06101.html>   , I supposed you have a new idea to replace IModel interfaces with something.  It looks I misunderstood your sentence.