I could not find this question already on SO, but I might have overlooked. My apologies if that is the case.
I'm trying to understand how to limit the cardinality of an object property using OWL.
I'm not sure this fully/correctly describes what I'm trying to accomplish, so here's an example:
Consider the hasWife and hasParent properties described in OWL 2 Web Ontology Language
Primer (Second Edition).
How do I state that any individual can only have 0 or 1 hasWife relationship, and must have exactly 2 hasParent relationships?
Extra points if you can tell me how to do this using WebProtégé.
Related
Schema.org both defines and uses the predicates named domainIncludes and rangeIncludes to relate types to properties (i.e. <schema:name> <schema:domainIncludes> <schema:Person> and <schema:name> <schema:rangeIncludes> <schema:Text>).
However in RDF Schema 1.1's specification, the predicates domain and range are already defined (giving <schema:name> <rdfs:domain> <schema:Person> and <schema:name> <schema:range> <schema:Text>).
My question boils down to: are schema.org's domainIncludes and rangeIncludes predicates equivalent to the RDFS domain and range predicates?
And if so:
Why does schema.org define them in the first place and not just use the predicates provided by the RDF standard? It already makes use of other RDFS defined predicates such as rdfs:label and rdfs:comment. Was this a stylistic choice? (Did they not like the names "domain" and "range"?)
Why is this relationship between the predicates not defined using owl:equivalentProperty or an equivalent? Schema.org should be explicit when creating predicates that are already defined by accepted standards such as RDFS 1.1, especially given its mission is structuring and standardising the web.
Otherwise remain a big fan of schema.org : )
Why does schema.org define them in the first place and not just use the predicates provided by the RDF standard?
Schema.org doesn't want you to do inferencing using certain properties. If I knew that
<schema:name> <rdfs:domain> <schema:Person>
then whenever I saw a <schema:name> defined for an object, I could infer that the object was of type <schema:Person>. Schema.org uses <schema:name> for lots of things so uses <schema:domainIncludes> to indicate how you could or should use it but doesn't lock it down.
Why is this relationship between the predicates not defined using owl:equivalentProperty or an equivalent?
This is a policy issue for schema.org! My guess is that, like many general purpose ontologies (e.g. Semantic Sensor Network vocab), they like to keep weak semantics to allow for flexibility of application over the kind of strictness you're talking about that you need for inference.
If you look at RDF/OWL as a distributed DB, and an ontology as the DB Schema,
then this explanation might make sense to you:
If you look at the definition of rdfs:domain, you find:
Where a property P has more than one rdfs:domain property, then the resources denoted by subjects of triples with predicate P are instances of all the classes stated by the rdfs:domain properties.
So if you have more then one domain, all those must be true! -> AND
If you have multiple schema:domainIncludess, at least one must be true. -> OR
I find that in (DB-)practice, one almost always wants the later approach (OR).
All this is the same for rdfs:range and schema:rangeIncludes.
I want to create an ontology describing a process with Protégé. I have a concept "process" connected with 5 other concepts (process tasks) by the relationship "is_composed_of". How to express this in Protégé. Do I create an ObjectProperties and I specify the domain and range in this case I will have 5 relationship "is_composed_of".
Is each instance of Process must be related to 5 instances of ProcessTask by the object property isComposedOf, then you'd use an axiom like:
Process ⊑ = 5 isComposedOf.ProcessTask
In the Manchester syntax, which is what you'd use in Protege, you'd go the Process class and add the following as a superclass:
isComposedOf exactly 5 ProcessTask
For more about quantified cardinality restrictions, see Meaning of OWL exact cardinality restrictions. Defining cardinality of data property in OWL include another example.
I'm trying to figure out if Jena (or any other SPARQL Update server) will enforce ontological constraints. For example, I want to enforce that only entities which have type x are allowed to have property y and the value of the property must have type z. I think this is what OWL can provide, but I'm not sure. Also, specifically, will Jena ensure that if I try to write a SPARQL Update query which does not follow these rules, that update will fail to insert and an error will be returned?
For example, I want to enforce that only entities which have type x are allowed to have property y and the value of the property must have type z. I think this is what OWL can provide, but I'm not sure.
What you're asking for is not what OWL provides. In OWL, you can say that:
propertyY rdfs:domain typeX
propertyY rdfs:domain typeZ
but this does not mean (at least, in the way that you're expecting), that only things of type X can have values for propertyY, and that the values must be of type Z. What it means is that whenever you see an assertion that uses propertyY, like
a propertyY b
an OWL reasoner can infer that
a rdf:type typeX
b rdf:type typeZ
The only time those inferences will be any kind of "constraint violation" is if you have some other way of inferring that a cannot be of type X, or that b cannot be of type Z. Then an OWL reasoner would recognize the inconsistency.
I'm trying to figure out if Jena (or any other SPARQL Update server) will enforce ontological constraints. … Also, specifically, will Jena ensure that if I try to write a SPARQL Update query which does not follow these rules, that update will fail to insert and an error will be returned?
I don't know whether Jena supports something like this out of the box, but you probably could probably either:
Use an OntModel with a reasoner attached, and run your SPARQL updates against that graph. Then, you can query the graph and see whether any inconsistency is found. How this would be done would depend on how the reasoner signals inconsistencies. This might not all that hard, but remember that Jena is really RDF-based and for full OWL reasoning, you'll need another reasoner that integrates with Jena (e.g., Pellet, but there are others, too, I think).
Alternatively, you might use a store that has reasoning built in, and probably has this kind of functionality already. I think that Stardog has some of these features.
What you need to understand about OWL is property restriction:
A property restriction is a special kind of class description. It describes an anonymous class, namely a class of all individuals that satisfy the restriction. OWL distinguishes two kinds of property restrictions: value constraints and cardinality constraints.
A value constraint puts constraints on the range of the property when applied to this particular class description.
A cardinality constraint puts constraints on the number of values a property can take, in the context of this particular class description.
Based on the description of your problem, you need to use a value constraint. These value constraints exists: some (someValuesFrom), only (allValuesFrom), and exactly (hasValue).
For example:
Class: Woman subClassOf: hasGender only Female
Class: Mother subClassOf: hasChild some Child
Class: Employee subClassOf: hasEmployeeID exaclty 1 ID
So depending on the restrictions on the individuals that you have defined, these individuals can be classified by the reasoner under the right class, which will be their type. The systems generally won't prevent you from entering false information, but the concept will either be declared unsatifiable or inconsistent. In the case of entering an individual that is incompatible with the constants in the ontology, the ontology becomes inconsistent (everything goes wrong) then you can retract the last fact I suppose. I am not sure about Jena, but OWL-API lets you temporarily add a concept to the ontology manager, and then you can check the consistency of the ontology. Normally when this check goes wrong, you can remove the last unsaved change to the ontology manger (via the change listener), and if everything is correct, you can save the changes in the ontology manager.
I'm getting poor performance doing a Model.find(array_of_ids) in mongodb using mongoid drive, and I don't understand why.
Relevant code:
ids = get_ids() #Get an array of 137 _ids for Topic model.
Topic.find(ids) #Find all data, but take 4 seconds to do it.
_id field is auto indexed, so it doesn't need any manual configuration.
So, why is it so slow?
Please ask if you need more of an explanation, and sorry for my poor English.
seems that you already got the solution.
I just wanna add on.
If the ids can reach 137, I think you should store the relation in Topic collection
instead. It is the other way around. The query will be
Topic.where(:id => self.topic_id)
where self refers to a record of this model.
It is actually has_many and belongs_to relationship.
Mongodb ability to store array, does not mean that for that many (137) records associated from other model you can store that way. The relational method is better.
Just put something in array if the data type is not related to other model/collection.
For example, topic tag that could be "trendy, teen, childish, cheesy, etc where you do not have a predefined tag, instead, they are defined by your users
. This is a good opportunity in using array feature with mongodb.
For your case where the array contains topic lists, where topics are data defined in Topic collection, relational model should have been used.
Just some suggestion, please do not vote me down.
My application is CoreData based but they may be a common theory for all relational databases:
I have a Output-Input to-many relationship in my model. There are potentially an unlimited number of links under this relationship for each entity. What is the best way to identify a specific input or output?
The only way I have achieved this so far is to place an intermediate entity in the relationship that can hold an output and input name. Then an entity can cycle through its inputs/outputs to find the right relationship when required. Is there a better way?
Effectively I am trying to provide a generic entity that can have any number of relationships with other generic entity.
Apologies if my description isn't the clearest.
Edit in response to the answer below:
Firstly thank you for your response. I certainly have a two-way too-many relationship in mind. But if a widget has 2 other widgets linked to its Inputs relationship what is the best way of determining which input is supplying, say, 'Age' or 'Years Service' when both may have this property but I'm only interested in a specific value from each?
I'm as confused as Joshua - which tells me that it may be that you haven't got a clear picture of what you're trying to achieve or that it is somewhat complex (both?).
My best guess is that you have something like:
Entity Widget
Attributes:
identifier
Relationships
outputWidgets <<->> Widget
inputWidgets <<->> Widget
(where as per standard a ->> is a to-many relationship and <<->> is a to-many relationship with a to-many reverse relationship).
So each widget will be storing the set of widgets that it has as outputs and the set of widgets it has as inputs.
Thus a specific widget maintains a set of inputWidgets and outputWidgets. Each of these relationships is also reversed so you can - for any of the widgets in the input or output - see that your widget is in their list of inputs or outputs.
This is bloody ugly though.
I think your question is how to achieve the above while labelling a relationship. You mention you want to have a string identifier (unique?) for each relationship.
You could do this via:
Where you create a new widgetNamedRelationship for each double sided relationship. Note that I'm assuming that every relationship is double sided.
Then for each widget you have a set of named inputs and named outputs. This also allows for widgets to be attached to themselves but only of there are separate input and output busses.
So then for your example "age" in your implementation class for Widget instance called aWidget you'd have something like:
NSPredicate *agePredicate = [NSPredicate predicateWithFormat:#"name='age'"];
NSSet *ageInputs = [aWidget.inputs filteredSetUsingPredicate:agePredicate];
Have I understood the question?
There really is no better way if you want to be able to take full advantage of the conveniences of fast and efficient in-store querying. It's unclear what you're asking in your additional comments, which I suppose is why you haven't gotten any answers yet.
Keep in mind Core Data supports many-to-many relationships without a "join table."
If Widget has many Inputs or Outputs (which I suspect could be the same entity), then a many-to-many, two-way relationship (a relationship with an inverse, in Core Data parlance) between Widget and Input is all you need. Then all you need to do is see if your Input instance is in the Widget instance's -inputs or if a Widget instance is in the Input instance's -widgets.
Is that what you were looking for? If not, please try to clarify your question (by editing it, not by appending comments :-)).