I would like to represent the following relationships using rdf and rdfs:
"Assessment Technique" (AT) has a property of "Assessment Characteristics" (AC). In a database, this would be represented by there being two tables, one for AT and the other AC linked with a foreign key in AC pointing back to the primary key in AT.
So what I have come up with so far using rdf and rdfs is the following classes that would represent the two tables:
ex:AssessmentTechnique rdfs:label "Assessment Technique" .
ex:AssessmentCharacteristic rdfs:label "Assessment Characteristic" .
My question is about the specific characterstics in the AC table. Can these be - or are they - properly called sub-properties of hasAssessmentCharacteristics? Or should each specific characteristic be its own property? I have tried to create them as sub-properties, but then the range of hasAssessmentCharacteristics is a class and those of sub-properties are usually of type xsd:string or xsd:int, and this goes against the rule that sub-properties have the same domain and range adn the parent property. So the following is incorrect, though it expresses the intent.
ex:hasAssessmentCharacteristics
rdf:type rdfs:Property;
rdfs:label "has Assessment Characteristics";
rdfs:domain ex:AssessmentTechnique;
rdfs:range ex:AssessmentCharacteristics .
ex:hasNumberOfItems
rdfs:subPropertyOf ex:hasAssessmentCharacteristics;
rdfs:label "has Number of Items";
rdfs:domain ex:AssessmentTechnique;
rdfs:range xsd:int .
The only other way I have been able to think of doing this is to ignore the fact that each column from the AC table comes from the same table and instead have a series of property assignment statements like this:
ex:hasNumberOfItems
rdf:type rdfs:Property;
rdfs:domain ex:AssessmentTechnique;
rdfs:range xsd:int .
ex:hasPublicAvailability
rdf:type rdfs:Property;
rdfs:domain ex:AssessmentTechnique;
rdfs:range xsd:string .
ex:hasURL
rdf:type rdfs:Property;
rdfs:domain ex:AssessmentTechnique;
rdfs:range xsd:string .
and so on....
I've see that there are ways to have containers in rdfs but from my reading of the reference material it seems that this pertains to hen houses and the hens contained therein and not a way of containing or collecting different types of characteristics of a hen (to extend the use of the metaphor) to things like
So if I am to create a long list of properties without any "tagging" to keep them organized, I'll do something with comments. But if there is a way of organizing these using rdf or rdfs or owl then I'd appreciate someone pointing me the way.
Paul
My question is about the specific characterstics in the AC table. Can these be - or are they - properly called sub-properties of hasAssessmentCharacteristics? Or should each specific characteristic be its own property?
Without even knowing the specifics of your domain model, the answer lies in the actual meaning of subproperty. A property p is a subproperty of property q exactly when:
p(x,y) implies q(x,y)
That's how subproperty assertions are used in RDFS inference. If one property is a subproperty of another, then whenever you see a usage of the first, you can infer the other. So, for instance, hasDaughter is a subproperty of hasChild, since we know that if someone has a x as a daughter, then they have x as a child.
It sounds like you're looking to have a toplevel property (names simplified) hasCharacteristic and define some subproperties that specify individual characteristics. There's no problem with that. For instance, we might, in describing a person, do:
:hasCharacteristic a rdfs:Property .
:hasHeightInInches rdfs:subPropertyOf :hasCharacteristics ;
rdfs:range xsd:int .
:hasName rdfs:subPropertyOf :hasCharacteristic ;
rdfs:range xsd:string .
You're right about the domains and ranges, though; if the domains or ranges of the subproperties are incompatible, then you need to make sure that you either have a common enough superclasses on the super property, or just don't declare them at all. In the sample above, you could ask for all the values of :hasCharacteristic for a person, and you'd get their name and height in inches,, and there'd be no problem with the fact that you're getting numbers and strings.
Regarding domains and ranges, remember that a property p having domain D simply means that:
p(x,y) implies D(x)
and having range R means that:
p(x,y) implies R(y)
One of the consequences of this is that domains and ranges are "inherited" by subproperties. Suppose p is a subproperty of q, and q has domain D. Then from p(x,y), we can infer q(x,y) (since p is a subproperty of q), and then we can infer that D(x) (since D is a domain of q). That means that in my example above, you could declare a common domain on the superproperty:
:hasCharacteristic a rdfs:Property ;
rdfs:domain :Person .
:hasHeightInInches rdfs:subPropertyOf :hasCharacteristics ;
rdfs:range xsd:int .
:hasName rdfs:subPropertyOf :hasCharacteristic ;
rdfs:range xsd:string .
Now, whenever you see, e.g.,
hasName(x,y)
you can infer this additional information:
hasCharacteristic(x,y)
Person(x)
xsd:string(y)