If that is true, would it make sense to fold Pellet into the Apache Jena 
project, or would that detract from supporting multiple reasoners?

-----Original Message-----
From: Olivier Rossel [mailto:[email protected]] 
Sent: Thursday, February 07, 2013 5:54 AM
To: [email protected]; Milorad Tosic
Subject: Re: Is Jena / RDF / OWL the right fit?

I think RDFS (aka RDFSchema) is good with a slight dose of OWL.
Please note that Jena alone cannot handle some advanced OWL structures all by 
itself.
We usually rely upon the Pellet add-on in that case.
Unfortunately, the Pellet library is (as far as I know) no longer maintained.




On Thu, Feb 7, 2013 at 11:21 AM, Milorad Tosic <[email protected]> wrote:
> Hi Travis,
>
> GENI project [1] have developed OWL extension of the NDL (Network Description 
> Language) [2] set of ontologies. You may find it informative as well as 
> useful for your purpose particularly NDL-OWL since it has extensions for 
> computational infrastructure.
>
> Regards,
> Milorad Tosic
>
>
>
> [1] https://geni-orca.renci.org/trac/wiki/NDL-OWL
> [2] http://www.science.uva.nl/research/sne/ndl
>
>
>
>
>>________________________________
>> From: "Tripp, Travis S" <[email protected]>
>>To: "[email protected]" <[email protected]>
>>Sent: Thursday, February 7, 2013 12:06 AM
>>Subject: Is Jena / RDF / OWL the right fit?
>>
>>Hello all,
>>
>>I am on a project where we are investigating a new OASIS spec called TOSCA.  
>>I am looking for advice on whether or not it would make sense to leverage RDF 
>>/ OWL and that we can then use Jena to store the whole ontology and use it 
>>for querying and performing searches against.
>>
>>It has a concept of requirements and capabilities which allow you to use 
>>capabilities to describe the capabilities of an entity and then can use a 
>>requirements document to find entities the provide the needed capabilities. A 
>>capability typically will be related to concepts like hardware, software, 
>>etc.  For example, I may have a capability of Java.  The java capability 
>>might have properties like JAVA_HOME. It could have descendants for specific 
>>versions of Java (Java 6, Java 7, etc) with descendent specific properties.  
>>Or I may have a capability called block storage and the storage will have a 
>>minimum size and maximum size associated with it. A capability is essentially 
>>something that can have hierarchy (e.g. Ubuntu can inherit from Linux), 
>>traversal ordering (Java 6 comes before Java 7), may have quantity associated 
>>with it (Memory), and may have available properties (INSTALL_DIR).
>>
>>The TOSCA spec itself has a language for describing capabilities and 
>>requirements in their format, which I have attached.  It also doesn't provide 
>>any specification on how to process the capabilities and requirements.  Below 
>>is another example snippet from the TOSCA primer working draft:
>>
>>In TOSCA, requirements and capabilities allow to define dependencies between 
>>node types. For example, the following 
>>"ApacheWebApplicationContainerCapability" capability type allows to express 
>>the capability of a node type to serve as a runtime container for an Apache 
>>web application; note, that the capability type inherits from the 
>>"WebApplicationContainerCapability". Each node type that includes a 
>>CapabilityDefinition of this type warrants that it can serve as a container 
>>for Apache web applications.
>>
>>What I am curious is whether or not it would make sense to have the ontology 
>>of capabilities and requirement internally stored in a format like RDF / OWL 
>>and that we can then use Jena to store the whole ontology and use it for 
>>querying and performing searches against. We would then support a translation 
>>format to the TOSCA format on demand. I don't want to kill a fly with a 
>>sledgehammer, but also don't want to reinvent anything. Any thoughts on this 
>>would be appreciated.
>>
>>Secondarily, are there any available ontology libraries that we could use to 
>>bootstrap our library of capabilities / requirements?  For example RDF or OWL 
>>ontologies that already have a standard description of database vendors and 
>>properties?
>>
>>I hope this isn't an abuse of the mailing list, but I certainly appreciate 
>>any guidance that can be provided.
>>
>>-Travis
>>
>>
>>


Reply via email to