I am a bit lost. This is what I like to model in an ontology:
A isConnectedTo B via ConncetionTypeClass1.
A isConnectedTo D via ConncetionTypeClass2.
E isConnectedTo F via ConncetionTypeClass3.
For A and (B and D), I can create two classes that would have an object property isConnectedTo. But how can I specify the type of connection for each pair (i.e., ConncetionTypeClass)?
I mean, I like to avoid creating a properties such as isConnectedViaConnectionType1 , isConnectedViaConnectionType2 etc.
Related
I'm trying to write a SPARQL query that, given a node, returns the connected nodes up to the root.
I've tried using property paths:
SELECT ?subproperty WHERE { <leaf node URI> <http://www.w3.org/2000/01/rdf-schema#subPropertyOf>+ ?subproperty . }
but I want to also traverse subclasses if possible in the same query. Basically, I'd like to find all parent nodes up to the root from any given node.
So my model currently has:
Class A
Class B and Class C (subclasses of A)
Property D (property of B)
Property E (subproperty of D)
I want to make a query that if given E, returns something like:
Property E, Property D, Class B, Class A
The model may change in the future, so I'd like the query to be able to handle any length between the leaf and root node. Thanks for any help or pointers! (also sorry for the simplified representation of the model, very new to ontologies)
I ended up using a wildcarding trick from SPARQL: is there any path between two nodes? to traverse the nodes. I just edited the wildcard so that it only looks at parent nodes.
Suppose we have 2 tables 'Departments' & 'Users'. There is also another table called 'UserDeps' for user<->department relation. For the first 2 tables we have 2 classes for domain objects. There is a layer in the app. for converting tables into objects and vice versa.
Now The Problem:
I have a method like this:
List GetDepartmentUsers(long depid);
My question is : Where do you put this method?
As a static method inside 'Department' class? ( obviously syntax would be something like this :
List<Users> GetDepartmentUsers(long depid, DataHelper dh);
As an instance method for every 'Department' object?
Department dep = new Department(depid);
DataHelper dh = new DataHelper();
dep.GetDepartmentUsers(dh);
Note: 'DataHelper' is a class which handles DB/SQL operations.
Without knowing the whole context, just based on what is provided, the second solution is better. A Department has Users, therefore, it makes sense to ask a Department to get the list of its Users.
The first one is not object-oriented. Because static method is just a function not a method in OO sense. Such functions kill the purpose of OO.
I have OWL ontology TBOX only (no instances), I need to formally express it using algebra to define some structure.
I have looked for that, I found some representations
(C, P, A) the reference is http://www.dblab.ece.ntua.gr/pubs/uploads/TR-2007-20.pdf
where C is the set of classes, P is the set of properties and A is the set of axioms.
A is used to express subsumption, restrictions etc...
C includes primitive types used in data properties definition
(C, P, Sub, Func) the reference is http://dl.acm.org/citation.cfm?id=1871946
where C is the set of classes, P is the set of properties, Sub is subsumption relationships and Func relates each class to its applicable properties
Actually, I'm not sure what is the right representation. could you refer my to some reference please if any?
Is it possible in OWL to add a property onto a single class? So far, I see properties joining a pair of classes (like defining whether or not properties are symmetric, etc.). For example, what kind of property would I use to tag whether or not an animal is a pest. If it matters, I'm using Protégé to construct the ontology.
If your question is whether or not a property can have same domain and range, then yes, it is possible.
If X is a class and p is a property, it is possible to have
p range X
p domain X
and an assertion would look like:
i type X // an instance of X
i p i // a self assertion
I'm not sure how this fits your example though: how are you modeling 'being a pest'? It looks to me like you could model this as
i type Pest
e.g., as a class assertion not a property.
Having the SOLID principles and testability in mind, consider the following case:
You have class A and class B which have some overlapping properties. You want a method that copies and/or converts the common properties from class A to class B. Where does that method go?
Class A as a B GetAsB() ?
Class B as a constructor B(A input)?
Class B as a method void FillWithDataFrom(A input)?
Class C as a static method B ConvertAtoB(A source)?
???
It depends, all make sense in different circumstances; some examples from Java:
String java.lang.StringBuilder.toString()
java.lang.StringBuilder(String source)
void java.util.GregorianCalender.setTime(Date time)
ArrayList<T> java.util.Collections.list(Enumeration<T> e)
Some questions to help you decide:
Which dependency makes more sense? A dependent on B, B dependent on A, neither?
Do you always create a new B from an A, or do you need to fill existing Bs using As?
Are there other classes with similar collaborations, either as data providers for Bs or as targets for As data?
I'd rule out 1. because getter methods should be avoided (tell, don't ask principle).
I'd rule out 2. because it looks like a conversion, and this is not a conversion if A and B are different classes which happens to have something in common. At least, this is what it seems from the description. If that's not the case, 2 would be an option too IMHO.
Does 4. implies that C is aware of inner details of B and/or C? If so, I'd rule out this option too.
I'd vote for 3. then.
Whether this is correct OOP theory or not is up for debate, but depending upon the circumstances, I wouldn't rule C out quite so quickly. While ti DOES create a rather large dependency, it can have it's uses if the specific role of C is to manage the interaction (and copying) from A to B. The dependency is created in C specifically to avoid creating such dependency beteween A and B. Further, C exists specifically to manage the dependency, and can be implemented with that in mind.
Ex. (in vb.Net/Pseudocode):
Public Class C
Public Shared Function BClassFactory(ByVal MyA As A) As B
Dim NewB As New B
With B
.CommonProperty1 = A.CommonProperty1
.CommonProperty2 = A.CommonProperty2
End With
Return B
End Function
End Class
If there is a concrete reason to create, say, a AtoBConverterClass, this approach might be valid.
Again, this might be a specialized case. However I have found it useful on occasion. Especially if there are REALLY IMPORTANT reasons to keep A and B ignorant of eachother.