RDF Studio Beta 1 Release includes OWL API Integration

We’re pleased to announce that we have finished integrating Manchester’s OWL API into RDF Studio, and so now we have support for OWL2/XML and OWL2 reasoning.

Given the huge number of requests for student licenses, we’ve also decided to allow students to have 1 year’s license for free, with the option to renew their license for the duration of their time as students.

More details will be published next month.

Coming Up In Version 1.00

We’re excited and working hard to get all the features you want into RDF Studio’s first version 1 release. After plenty of downloads and interest in version 0.9 last month, we’ve compiled a roadmap of what we want to put into our first full release. What’s coming up? Here’s a sneak peek:

- WSYWYG editing of classes, properties and individuals.
- Categorisation of all properties and settings throughout the software (so it’s easier to see what properties mean).
- Clear errors and handling if you have a syntax error in your document that needs correcting.
- Vocabulary search and support for ‘loose’ ontologies which you can place in configurable folders. This means you can search for suitable external vocabularies to use in your document quickly and easily.
- Better inline help & tutorials.

RDF Studio 0.9.9.5 Released

We are pleased to announce the release of RDF Studio 0.9.9.5, which contains some helpful bug fixes and enhancements, including:

- Some issues with new template RDF files fixed.

- Autocomplete now loads OWL properties and classes from referenced ontologies.

- Error handling for malformed URIs in Publisher now improved.

- Major All views now automatically update if no edits are made to model syntax after a few seconds. Any changes are merged in.

Announcing RDF Studio 0.9.7.0

Linked Data Tools are very pleased to announce the release of our long-awaited RDF design environment, RDF Studio. It is currently available free for a 21 day trial and with a number of flexible options for the fully licensed edition.

Stay up to date as we announce further features for the product roadmap over the next few weeks.

We’re excited, we hope you are too.

RDF Buddy being released this month

We are pleased to announce that our long-awaited RDF assistant software, RDF Buddy will be released shortly after final testing.

The software is run using the latest Apache Jena release, and features an ultra-modern Metro UI design. It also allows visualisation of an RDF model into a graph, and a quick-glance view of the ontological data within the model.

It will be released initially with a no-support and 6 month support package. We are looking forward to seeing the response to this new release.

Using Microsoft Synchronization Framework

We’re going to use Microsoft’s Sync Framework to synchronize our delay-loaded graphs with their destination graph stores, if they do not have native implementations in Ingenious Framework (e.g. Sesame, or Jena). This is because the implementation of change notification is inconsistent between traditional triple storage providers.

We’re also going offer our own, change-notifying persistence store for triple data, likely using a document database, which will offer the most efficient and high performance storage mechanism for triple data in our graphs. These can, however, be mirrored with another triple store, and so crucially, you will also be able to mirror or update your graph from triple stores already connected to other semantic web apps, and the delay-loaded model will update accordingly.

We were concerned that we were restricting the usage of our delay loaded semantic model to our own native providers. This offers two means by which triple data could be stored; either using our native providers, which may harness popular data stores such as Sesame, or alternatively by mirroring (or synchronizing) a native data store with an external storage provider.

Our native providers lend themselves to triple stores offering change notification, whereas our mirroring/synchronizing providers lend themselves more to platforms where the store does not offer change notification and storage of (for example) a revision number with a triple is not possible, but we still expect the stored model to be updated by another n connected semantic web applications.

We are heading for a release

We are heading for a release, but have decided to spend a little more time on designing LinqToOwl than we originally anticipated, and the use to its approach in our entity framework implementation.

This is important so that we are able to provide documentation immediately on first release, and we’re absolutely sure that this is the highest quality framework for handling semantic web data available.

We’ve set up our GitHub repository

We’ve set up a repository on GitHub, awaiting upload of the (alpha version 0.1) framework, we hope by the first half of next month.

We’ve chosen GitHub as it is very widely used and familiar, and there are a number of free tools to use Git repositories on your local PC. It also allows us of course to get cloud backup of the source code – just in case!

rdfs:Property is an instance of an rdfs:Class

rdf:Property, which we find in the Dublin Core Metadata Initiative ontology, is an instance of rdfs:Class.

In addition, any rdf:type specification (which is in itself an instance of rdf:Property) specifies that the object is an rdfs:Class and that the subject is an instance of that class.

Some subtleties of rdfs:type and RDF/XML

rdfs:type used in RDF/XML is quite a flexible indicator, as we’ve found out whilst developing LinqToOwl. For example, see below:

<owl:Class ID=”myclassname”>

</owl:Class>

is the same as

<rdf:Description rdf:about=”#myclassname”>

<rdfs:type rdf:resource=”http://www.w3.org/2002/07/owl#Class”/>

</rdf:Description>

In that owl:Class is, by asserted definition, to be interpreted to be an instance of type http://www.w3.org/2002/07/owl#Class. Not only this, but rdfs:Property is used  quite heavily in the Dublin Core Metadata Initiative’s core terms ontology, for example below:

<rdf:Description rdf:about=”http://purl.org/dc/terms/title”>
<rdfs:label xml:lang=”en”>Title</rdfs:label>
<rdfs:comment xml:lang=”en”>A name given to the resource.</rdfs:comment>
<rdfs:isDefinedBy rdf:resource=”http://purl.org/dc/terms/”/>
<dcterms:issued rdf:datatype=”http://www.w3.org/2001/XMLSchema#date”>2008-01-14</dcterms:issued>
<dcterms:modified rdf:datatype=”http://www.w3.org/2001/XMLSchema#date”>2010-10-11</dcterms:modified>
<rdf:type rdf:resource=”http://www.w3.org/1999/02/22-rdf-syntax-ns#Property”/>
<dcterms:hasVersion rdf:resource=”http://dublincore.org/usage/terms/history/#titleT-002″/>
<rdfs:range rdf:resource=”http://www.w3.org/2000/01/rdf-schema#Literal”/>
<rdfs:subPropertyOf rdf:resource=”http://purl.org/dc/elements/1.1/title”/>
</rdf:Description>
By the same token, we think we could express this in RDF/XML as the following equivalent:
<rdfs:Property rdf:about=”http://purl.org/dc/terms/title”>
<rdfs:label xml:lang=”en”>Title</rdfs:label>
<rdfs:comment xml:lang=”en”>A name given to the resource.</rdfs:comment>
<rdfs:isDefinedBy rdf:resource=”http://purl.org/dc/terms/”/>
<dcterms:issued rdf:datatype=”http://www.w3.org/2001/XMLSchema#date”>2008-01-14</dcterms:issued>
<dcterms:modified rdf:datatype=”http://www.w3.org/2001/XMLSchema#date”>2010-10-11</dcterms:modified>
<dcterms:hasVersion rdf:resource=”http://dublincore.org/usage/terms/history/#titleT-002″/>
<rdfs:range rdf:resource=”http://www.w3.org/2000/01/rdf-schema#Literal”/>
<rdfs:subPropertyOf rdf:resource=”http://purl.org/dc/elements/1.1/title”/>
</rdfs:Property>
We’ve removed the rdfs:type child node as it has been asserted by the rdfs:Property parent node instead of rdf:Description. They both mean the same. Indeed, RDF/XML is not the most human-friendly formats; which is why it potentially a good idea to embed its complexity into a framework.
An interesting note, however, is that you can define simply a list of triples without an origin type by simply stating an rdf:Description without stating an rdfs:type. Further, we could now define an instance of dcterms:title by the following:

<dcterms:title rdf:about=”http://www.semanticmatters.net/articletitles#myfirstarticle”>

</dcterms:title>

Which is the same as

<rdf:Description rdf:about=”http://www.semanticmatters.net/articletitles#myfirstarticle”>

<rdfs:type rdf:resource=”http://purl.org/dc/terms/title”/>

</rdf:Description>

Let’s give the namespace http://www.semanticmatters.net/articletitles the namespace prefix semarticles: for shorthand.

The very interesting thing now is that we could assert some further properties of semarticles:myfirstarticle and create a new instance of semarticles:myfirstarticle that would thus inherit the properties of both dcterms:title and semarticles:myfirstarticle.

But what are the implications of this for an attributing framework? An interesting problem…