 |
Semantic Web Support |
| Semantic Web Support is committed to providing support in semantic web and dependent technologies including cloud computing. Support is provided in terms of training and seminars in semantic web and cloud computing.In addition we provide personalized consulting, design reviews and technical evaluations. |
| Solving hard problems is our focus. Whether the problems are large scale memory management or a configuration issue impacting your production environment, Semantic Web Support provides dedicated, highly skilled, professionals committed to a solution in the shorted time period possible. We value communication, transparency and provide these resources and values in solving your problem. |
| Our inventory of tools we support included Jena, Blackbook, Hadoop, Lucene and Solr. Our customers and partners leverge experts in each of these core technologies. Commercial and government partners find Semantic Support a one stop shop for solutions to challenging technical problems. |
| Our Semantic Web Center developed the Semantic Web Methodology enabling the "how to" of every semantic web deployment. |
| The Semantic Web Center works with domain holders including Hewlett Packard and the National Institute of Science and Technology in formulation and support domain vocabularies and ontologies. |
| Semantic web support provides a common platform for individuals to share concerns and insights in semantic web computing. The Semantic Web Center aids developers and researchers in delivering high quality, production ready software to the production community. |
| Our five rules of software engineering typify our values and goals. |
| W3C specifications ahead of JSR specifications |
| The
World Wide Web Consortium (W3C) develops interoperable technologies
(specifications, guidelines, software, and tools) to lead the Web to
its full potential. W3C is higher level than the Java Specification
Requests (JSR) specifications due to the fact that the W3C
specifications are language implementation independent. As a practical matter, today's application requirements regularly include free form objects and references to these objects. These free form objects and their structures signify the need for variable ontologies. Looking at item #1 we find the W3C specification for Resource Description Framework (RDF). Taking this requirement one step further, consider the need for inferencing. We have the OWL standard available to us in another W3C specification. |
| JSR ahead of de facto standards |
| Java
Specification Requests (JSRs) are the actual descriptions of proposed
and final specifications for the Java platform. Java adheres to the
write once run anywhere paradigm and is routinely used to implement W3C
specifications. JSRs may result in containers, application programmer
interfaces (API) or remote procedure calls (RPC) among other techniques. Using our practical example, a remote calling mechanism for accessing RDF may be web services through the Simple Object Access Protocol (SOAP) or JSR 181 or alternately representational state transfer (REST) or JSR 311. Alternately we could use the defacto standard of Apache Axis. In exploring the problem in more detail, we first consider each technology. JSR 181 defines an annotated Java syntax for programming Web Services. The principal goal of the specification is to provide a simplified model for web services development that is easy to learn and quick to develop. The specification focuses on enabling the commonly needed forms of web services required for achieving robust, maintainable, and highly interoperable integration. Using this specification, removes the need to hand code web services. Using java annotations, the web services description language (wsdl) is automatically generated and supported on a variety of java platforms. This is design consistent with the write once run anywhere paradigm. Next, consider JSR 311. JSR 311 develops an API for providing support for RESTful(Representational State Transfer) Web Services in the Java Platform using annotations. Initially, REST was a defacto standard promoted by Google and others. As REST gained acceptance, the JSR 311 represented REST is a write once run anywhere paradigm. REST is uniform resource indicator (URI) oriented using the hyper text transfer protocol (http) methods, get, post, put and delete. Finally, Axis is the de facto standard for wsdl oriented web services. Whereas, JSR 181 only allows data types supported by java and non-java languages (.net, visual basic, etc), Axis allows more flexibility in the use of data types. The tradeoff for this flexibility is web services may not run in both the .net and java paradigms. This examination leads to a conclusion. Since they are virutally for free, applications shall implement web services with JSRs 181 and 311. Since Axis is not part of a specification and may not have long term support, and standards exist for similar functionality, we remove the consideration of Axis. |
| De facto standards ahead of custom development |
| An excellent rule for controlling engineering costs is to avoid custom software development. An examples of de facto standards includes the google widget toolkit (gwt). Another example, from the past was XDoclet. Both techniques allow the developer to save time in creating software. The gwt and XDoclet techniques are not standards, but provide productivity enhancements to justify their usage. XDoclet was ultimately replaced by annotations in the java software development kit (sdk) 5. A practical example of de facto standards is the use of the Jena api for the creation of RDF systems. This api is extremely well designed and requires very little code to produce RDF implementations. No implementation specification exists at this point and the cost reduction and quality improvement makes Jena a worthwhile choice. |
| Compositional patterns to create software systems |
| In Design Patterns, Erich Gamma told us that composition is inherently higher level than inheritance. Using the specification oriented approach, we compose systems by combining specifications. This entire process is composition. A practical example of this type of composition is the use of JSR 181 annotations in conjunction with Jena for an RDF implementation and doing this within the same java class. |
| Use design patterns when creating custom code |
| In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects without specifying the final application classes or objects that are involved. Algorithms are not thought of as design patterns, since they solve computational problems rather than design problems. Since we established software development is an expensive activity, consider lessening the number of development hours by using pre-defined design patterns. Mark Grands book Design Patterns In Java offers 47 unique patterns. Use of these patterns improves the quality of software by using previously vetted interactions. |
| Additional Rules |
| Implement single sign on. strategy. No client side plug in dependencies. Write one run anywhere paradigm (Java) |
