Ontology URI assumption in TopBraid

[Simon Cox]

TopBraid appears to enforce an assumption that the Ontology URI is the same BaseURI. 

This is not strictly required by the relevant standards, and may not followed by some published vocabularies, which  

(a) don't define a baseURI (in which case I think it defaults to the source URL or filename)

(b) set the ontology URI to a different value to the Base URI. 

Today I encountered this with the newly announced W3C Location vocabulary http://www.w3.org/ns/locn . 

After a lot of preliminary work, they have now moved the vocabulary into what is expected to be the permanent namespace http://www.w3.org/ns/locn# . So even though the vocabulary has not yet been finalized, it is now available for testing, and the intention is that this is the URI that it will be published at. 

I have tested the W3C deployment in TopBraid by creating a stub ontology that merely owl:imports from the web location. That goes fine. However, TopBraid does not allow me to open it directly. I retrieved the vocabulary and saved it as a file to a location from where I can access it within TB. When I attempt to open it I get the following error: 

"Can not open file locn.ttl. 

Reason: The file does not contain a valid base URI and cannot be opened. ..."

Here are the relevant snippets from this vocabulary in TTL and RDF/XML formats: 

Turtle: 

@prefix locn: <http://www.w3.org/ns/locn#> .

@prefix owl: <http://www.w3.org/2002/07/owl#> .

@prefix vann: <http://purl.org/vocab/vann/> .

@prefix voaf: <http://labs.mondeca.com/vocab/voaf#> .

locn: a voaf:Vocabulary,

        owl:Ontology ;

    vann:preferredNamespacePrefix "locn"^^xsd:string ;

    vann:preferredNamespaceUri "http://www.w3.org/ns/locn#"^^xsd:anyURI .

Right - no baseURI, so the base would default to the filename. But the Ontology URI is different, in fact the ontology URI is the same as the locn: namespace - i.e. it has a trailing #. 

Getting the RDF/XML version we find 

RDF/XML: 

<rdf:RDF xml:base="http://www.w3.org/ns/locn">

    <owl:Ontology rdf:about="http://www.w3.org/ns/locn#">

        <rdf:type rdf:resource="http://labs.mondeca.com/vocab/voaf#Vocabulary" />

        <vann:preferredNamespaceUri rdf:datatype="http://www.w3.org/2001/XMLSchema#anyURI">http://www.w3.org/ns/locn#</vann:preferredNamespaceUri>

        <vann:preferredNamespacePrefix rdf:datatype="http://www.w3.org/2001/XMLSchema#string">locn</vann:preferredNamespacePrefix>

    </owl:Ontology>

</rdf:RDF>

So in this case the baseURI is declared, but this is different to the Ontology URI. 

When I attempt to open this directly I get no error, but also no content visible in TBCME. 

Running experiment creating a new ontology via TBCME's File->New->RDF/OWL File dialogue, while it is possible to make the baseURI different to the filename, TB does not seem to allow the BaseURI and the Ontology URI to be different. 

Until now I had gone along with the TB assumption, but now we seem to have hit a wall. If I were to be engaging with a community that was not following the TB assumption, then I would not be able to use TBCME for ontology development. W3C is not just any community, so if this is the direction they are heading, then this could be a problem for TopBraid. And in this case I know the editors of this spec, and was invited to take part in the ontology development. I was unable to at this time, but would expect to engage more in the future. 

Simon

[Holger Knublauch]

Hello Simon,

the # at the end of this particular namespace is indeed unusual, and the
authors may want to change this before publishing the final version -
most other ontologies use the graph URI without # for the owl:Ontology.

Anyway, TopBraid can handle those without problems. I have created a
file that imports http://www.w3.org/ns/locn# and then used the Download
button in the Imports view to get a local copy as a .ttl file. I can
then open the Turtle file without problems. Note that the classes of
this ontology show up under rdfs:Resource, so that is probably why you
are not seeing any contents if owl:Thing is the root of your class tree?

HTH
Holger

> --
> -- You received this message because you are subscribed to the Google
> Group "TopBraid Suite Users", the topics of which include Enterprise
> Vocabulary Network (EVN), TopBraid Composer, TopBraid Live, TopBraid
> Insight, SPARQLMotion, SPARQL Web Pages and SPIN.
> To post to this group, send email to
> topbrai...@googlegroups.com
> To unsubscribe from this group, send email to
> topbraid-user...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/topbraid-users?hl=en
> ---
> You received this message because you are subscribed to the Google
> Groups "TopBraid Suite Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to topbraid-user...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Simon Cox]

Thanks Holger - 

OK - I saved the imported ontology like you said. 

Inspecting the contents, I find the only difference from what I got by downloading the TTL file directly from W3C was the insertion of 

# baseURI: http://www.w3.org/ns/locn

This is a comment! http://www.w3.org/TR/turtle/#sec-grammar-comments 

But I guess it is important to TopBraid. 

I've previously noticed similar comments used to indicate imports as well. 

Hmmm. Now we are getting into (black) magic? 

Furthermore, when I put a copy of this saved file in a place where I could open it, then TopBraid automatically created a second Ontology resource whose URI is the baseURI, in addition to the explicit one already in the file. 

So clearly TopBraid insists on having an Ontology present whose URI is the baseURI declared in the file (graph). 

If you make any changes to the file and then save it, you end up with two ontologies in the file, which in turn confuses some other tools. 

One of my colleagues has pointed out that this may be coming from OWLAPI 

"the automatic ontology IRI mapping tools in OWLAPI assume that the base URI is the ontology IRI.  As far as I know this should be just a convention."

Is this the source of the problem in TB? 

[Holger Knublauch]

I really don't think there is a problem in TBC. If the physical file (imported from somewhere else) does not contain baseURI information then how could TopBraid possibly make sense of it. That's why we add the # baseURI comment: it makes managing the files in the workspace much more efficient than having to pre-load them all.

I remain of the position that the ontology authors should follow the convention used almost everywhere else - that the owl:Ontology does not end with a #.

Holger

[Simon Cox]

The baseURI is only required it there are partial URIs. 

If every URI in a document is either a either fully qualified URI, or a namespace-abbreviated URI, including the Ontology declaration, then any definition of or assumptions about the baseURI is superfluous. Everything is explicit. That should be enough for any application. So I guess I don't understand the question 

"how could TopBraid possibly make sense of it"

My other point is that if TB is relying on extra information being smuggled in comments, then we are well out on a limb here. 

You received this message because you are subscribed to a topic in the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/topbraid-users/975Tv5ukhog/unsubscribe.
To unsubscribe from this group and all its topics, send an email to topbraid-user...@googlegroups.com.

[Irene Polikoff]

Simon,

 

TopBraid workspace implements graphs as specified by the relevant W3C specifications. A TopBraid workspace defines a dataset consisting of multiple named graphs. Each file in the workspace that either directly contains RDF triples (such as a .TTL file) or is a connector to an external data source (such as SPARQL Endpoint, RDFa site or external database) is a named graph.

 

Each graph needs an identity and TopBraid uses baseURI as graphs’ identity. Without having a way to identify graphs, it would not be possible to act on owl:import statements as there would be no way to identify what is being imported. Nor would it be possible to say which graph is being queried in a SPARQL query.

 

For more information, please refer to Help -> TopBraid Composer > RDF and TopBraid >Named Graphs and Base URIs in TopBraid

 

Regards,

 

Irene

[Simon Cox]

Thanks a lot Irene. That clarifies things for me. I'll re-state it in my words to check I've got it right: 

1. the set of graphs in the workspace is determined by the <import> statements in the ontologies

2. the baseURI is used as the graph name for each import. 

AFAICT the issue that I raised comes about because 

      owl:import rdfs:range owl:Ontology .

rather than _graph_ . So even though the specs do not require any specific correspondence between ontology name and baseURI, because it makes sense to interpret an import as operating on a _graph_ we end up in the situation that works best if the ontology name is a graph name, which is easiest if it is the context or baseURI. 

The issue is really that range of owl:import is not really right. 

[Holger Knublauch]

On 12/21/2013 20:45, Simon Cox wrote:
> Thanks a lot Irene. That clarifies things for me. I'll re-state it in
> my words to check I've got it right:
> 1. the set of graphs in the workspace is determined by the <import>
> statements in the ontologies
> 2. the baseURI is used as the graph name for each import.
>
> AFAICT the issue that I raised comes about because
> owl:import rdfs:range owl:Ontology .
> rather than _graph_ . So even though the specs do not require any
> specific correspondence between ontology name and baseURI, because it
> makes sense to interpret an import as operating on a _graph_ we end up
> in the situation that works best if the ontology name is a graph name,
> which is easiest if it is the context or baseURI.
> The issue is really that range of owl:import is not really right.

The range of owl:import can be owl:Ontology, and OWL reasoners can then
infer that the graph must be an owl:Ontology even if it is not
explicitly declared as such.

Holger