I want to reuse existing vocabulary. Instead of importing whole ontologies, I want to do it by referring to URIs of selected classes and properties in my ontology.
If ontologies are imported then axioms are also imported in my ontology, so reasoner obviously will take care of the imported axioms.
But if I reuse classes/properties by referring to their URIs then axioms are not imported in my ontology. So, My question is that will the reasoner respect the rules applied on the referred terms?
====
Added Later
instead of copy past or OWL Import if terms are reused by referring to their URIs then axioms are not imported into target ontology.
But my question is that if internet is available then will the reasoner Fitch and respect axioms applied to that specific (reused) term.
for example, if I am reusing nfo:fileSize by referring to semanticdesktop.org/ontologies/2007/03/22/nfo/#fileSize , so if in case I am connected to internet then will reasoner go over internet to check for the axioms applied to nfo:filesSize?
The answer is no, reasoners are not expected to find out more axioms online if presented with the IRI of a class or property. They are meant to use all and only the axioms in the import closure of their ontology.
However, there are other ways of including only part of an ontology into a new ontology, for the purpose of reusing classes and properties with their original meaning. There are techniques such as modularisation and atomic decomposition that allow you to select a subset of the axioms of an ontology, e.g., all the axioms used in defining a specific class - which you can then copy over.
Related
agda-stdlib has facilities for doing equational reasoning for various specific library defined relations (example). It also has a type that identifies equality relations defined here. What is the easiest way for me to get access to the same facilities for equational reason I get with propositional equality.
The kit is defined in Relation.Binary.Reasoning.Setoid.
You only need to define a proof S that your relation defines a Setoid and then you can open import Relation.Binary.Reasoning.Setoid S to get the equational reasoning combinators.
In statically typed language, people are able to use algebraic data type to abstract data and also generate constructors, or use class, trait and mixin to deal with data abstraction.
In dynamically typed language, like Python and Ruby, they all provide a class system to users.
But what about scheme, the simplest functional language, the closest one to λ-calculi, how does it abstract data?
Do scheme programmers usually just put data in a list or a lambda abstraction, and write some accessor function to make it look like a tree or something else? like EOPL says: specifying data via interfaces.
And then how does this abstraction technique relate to abstract data type (ADT) and objects? with regard to On understanding data abstraction, revisited.
What SICP (and I guess, EOPL) is advocating is just using functions to access data; then you can always switch one set of functions for another, implementing the same named set of functions to work with another concrete implementation. And that (i.e. the sets of such functions) is what forms the "interfaces", and that's what you put in different source files, and by just loading the appropriate one you can switch the concrete implementation while all the other code is none the wiser. That's what makes it "abstract" datatype.
As for the algebraic data types, the old bare-bones Scheme way is to create closures (that hold and hide the data) which respond to "messages" and thus become "objects" (something about "Scheme mailboxes"). This gives us products, i.e. records, and functions we get for free from Scheme itself. For sum types, just as in C/C++, we can use tagged unions in a disciplined manner (or, again, hide the specifics behind a set of "interface" functions).
EOPL has something called "variant-case" which handles such sum types in a manner similar to pattern matching. Searching brings up e.g. this link saying
I'm using DrScheme w/ the EOPL textbook, which uses define-record and variant-case. I've got the macro definitions from the PLT site, but am now dealing with ...
so seems relevant, as one example.
I have two ontologies ontology1.owl and ontology2.owl where the first depends on the second (ontology1.owl imports ontology2.owl).
I have an RDF file instance1.rdf that conforms to ontology1. instance1.rdf refers to individuals from instance2.rdf which conforms to ontology2.owl.
I have an application that employs instance1.rdf to do some specific logic. However, data from instance2.rdf are also required for the processing as instance1.rdf refers to individuals from instance2.rdf. Let's assume that all instances and ontologies are available on the web. For example:
http://www.example.com/ontology1.owl
http://www.example.com/ontology2.owl
http://www.example.com/instance1.rdf
http://www.example.com/instance2.rdf
QUESTION
The entry for my application should be instance1.rdf which the user should provide (or provide a link to it). However, it's not the user's responsibility to know the required instance2.rdf, it's rather the application responsibility and this can be known by encoding such dependency in instance1.rdf. Is there any elegant way to make instance1.rdf refer to instance2.rdf, so that my application knows where to retrieve instance2.rdf from and load it? The
NOTES
I do not want to use owl:import. The reason is that both files instance1.rdf and instance2.rdf are RDF files, I do not want to use owl constructs here.
A possible workaround is that in instance1.rdf, I create a special property, e.g., dependsOn, and set the value of the property to the link to instance2.rdf, and handle the rest in my application. Is this straightforward?
I have two OWL files each file describes what a receipt is, OWL-A has class named RecBody with property hasItem. OWL-B has the same class but has a property called hasField. both are identical
My question is how specify to the RDF engine that hasItem and hasField are the same "thing" I need a solution do this automatically since I face such problem when I try to bind data from heterogeneous sources
Well, you can use the owl:sameAs tag to do this, according to the Owl language reference.
Using this tag will make it clear to a reasoner that these two constructs refer to the same thing.
Sources: http://www.w3.org/TR/owl-ref/#equivalentProperty-def
http://www.w3.org/TR/owl-ref/#sameAs-def
For classes be sure to use owl:equivalentClass and not owl:sameAs as the latter if used on classes will make your ontology OWL-Full
Source : http://www.w3.org/TR/owl-ref/#equivalentClass-def
In this beginners guide to Dependency Injection I noticed that the UML diagram distinguishes between "uses" and "depends upon".
Since both require some form of a reference in the class that "uses" or "depends upon", I wonder: What is really the difference between the two?
Check out the blockquotes about relationship types taken from IBM Rational Software Architect documentation.
"depends upon" means the following:
A dependency relationship indicates
that changes to one model element (the
supplier or independent model element)
can cause changes in another model
element (the client or dependent model
element). The supplier model element
is independent because a change in the
client does not affect it. The client
model element depends on the supplier
because a change to the supplier
affects the client.
"uses" means the following:
A usage relationship is a dependency
relationship in which one model
element requires the presence of
another model element (or set of model
elements) for its full implementation
or operation. The model element that
requires the presence of another model
element is the client, and the model
element whose presence is required is
the supplier. Although a usage
relationship indicates an ongoing
requirement, it also indicates that
the connection between the two model
elements is not always meaningful or
present.
As I read it "usage" is a less strict "dependency".
"Uses" is where one Class refers to another Class for some of it's operations.
"Depends on" is where a Class A uses another Class B within it's implementation (e.g. as a parameter to a method). In this case changing Class B may necessitate a change to class A.
Note I've said Class, but it applies equally to Interfaces.
Wikipedia has a good article on this: http://en.wikipedia.org/wiki/Dependency_%28UML%29
So for example you could have a Uses relationship between a Class Driver and an Interface IVehicle which exposes a method called Drive(). Changes to the implementation of Drive do not require any changes to Driver, so you say Driver uses IVehicle.
However Class Driver has a Dependency on Class Hand, since Driver has two properties: Hand LeftHand and Hand RightHand. If the implementation of these changed, one would need to consider if Driver needed updating accordingly.