One of the first design issues encountered when using the Entity Framework is the design of your description types. The role of a description type is to define the data that makes up an entity. So you need to start with a clear understanding of your data model. Let’s start with a simple class of object like a Person and work through an example.
A Person will have a couple of simple literal properties such as:
- Full Name
- First Name
- Last Name
The simplest way to define a description type with the Entity Framework is with a rulebase. So let’s define a rulebase for the Person description.
select ?s ?p ?o ?r where {?s ?p ?o. filter(?s=?r).} as <description>
We start by adding a description rule that includes all direct properties of the entity. This is the most basic form of a description type. Things get more complicated when we introduce references to other objects. This introduces some rather common data modeling concepts such as is an object contained by another object or just referenced. So let’s add an example of each type of property.
- Address (contains an Address object)
- Knows (references another Person object)
So I will add two additional rules to the description rulebase to include these new properties.
select ?s ?p ?o ?r where {
?r x:Address ?s. ?s ?p ?o.
}as <description>
select ?s ?p ?o ?r where {
?r x:Knows ?s.
?s ?p ?o.
filter(?p=x:FullName)
} as <description>
The first rule includes all the direct properties of the contained Address object. The second rule includes just the full name of the referenced Person object to provide some user-friendly identity for the reference.
This description type is useful for retrieving an entity from the store. However get and put operations are often asymmetric. Meaning you often retrieve more data than you want to store after editing. In this example we would not want to store any a statements about the referenced Person object. To handle this we use a different description type when storing the entity. One that does not include any of the statements for the referenced object.
So we would remove the following rule from the storage description type.
select ?s ?p ?o ?r where {
?r x:Knows ?s.
?s ?p ?o.
filter(?p=x:FullName)
} as <description>
Note these description type rules are for illustrative purposes. It it sometimes much easier to classify containment vs. reference through annotations on the property in the ontology. In this case, you can have one set of rules for all Classes in your data model.
For example we could get all contained objects using a generic rule.
select ?s ?p ?o where {
?r ?x ?y.
?x x:referenceType x:Containment.
<description>(?s, ?p, ?o, ?y).
}
as <description>
The rule above recursively includes all properties that are marked with a reference type of Containment.
As you can see description types are just a tool that can be configured to meet the needs of your data model.
0 comments:
Post a Comment