User jerven - Semantic Overflow

OWL constaint on a set of datatypes.

2010-02-22T15:45:13Z

Hi All,

I want to record that some data was published on a specific data e.g.

a :published_in  "2009-01-01"^^date ;

However, sometimes I only have a period in which it was published not a specific date.

  :published_in  "P2009Y01M"^^duration .

Now in my OWL file I want to constrain :published_in to either one of these datatypes. So I want to give it a Range. The usual approach for one datatype is:

<owl:DatatypeProperty rdf:about="published_in">
  <rdfs:range rdf:resource="&xsd;date"/>
</owl:DatatypeProperty>

My first naive approach was:

<owl:DatatypeProperty rdf:about="published_in">
  <rdfs:range rdf:resource="&xsd;date"/>
  <rdfs:range rdf:resource="&xsd;duration"/>
</owl:DatatypeProperty>

This fails in pellet once data is introduced. (No literal can meet the restrictions of date and duration).

Two other approaches I tried were:

<owl:DatatypeProperty rdf:about="published_in">
<rdfs:range>
  <owl:Class>
    <rdf:Description>
      <owl:unionOf rdf:parseType="Collection">
        <rdf:type rdf:resource="&xsd;date"/>
        <rdf:type rdf:resource="&xsd;duration"/>
      </owl:unionOf>
    </rdf:Description>
  </owl:Class>
</rdfs:range>
</owl:DatatypeProperty>

This seems to work in Pellet but not in Protege (a random datatype is loaded as constraint in Protege instead of the unionOf).

The second approach I tried was

<owl:DatatypeProperty rdf:about="published_in">
<rdfs:range>
  <rdf:Description>
    <rdf:type rdf:resource="&owl;DataRange"/>
    <owl:oneOf>
      <rdf:Description>
        <rdf:type rdf:resource="&owl;List"/>
        <rdf:first rdf:datatype="&xsd;date"/>
        <rdf:rest>
          <rdf:Description>
            <rdf:type rdf:resource="&owl;List"/>
            <rdf:first rdf:datatype="&xsd;date"/>
            <rdf:rest rdf:resource="&rdf;nil">
           </rdf:Description>
         </rdf:rest>
      </rdf:Description>
    </owl:oneOf>
  </rdf:Description>
</rdfs:range>
</owl:DatatypeProperty>

This second approach does not work at all. It expects a <> empty element/literal with a datatype of either which is not at all that I want.

So in other words how do I correctly encode in OWL that :published_in is limit to the things that are a date or a duration?

Answer by Jerven for Generating unique ID's in triple-store, ala MySQL AUTO_INCREMENT

2010-02-03T08:22:47Z

When using virtuoso you can use the fact that it is also a rdbms to use its internal atomic sequences. With something like this.

SPARQL INSERT INTO GRAPH <http://mygraph.com> {  
        <:a>
        <:p>
        sql:sequence_next("GRAPH_IDENTIFIER") };

See http://docs.openlinksw.com/virtuoso/sequenceobjects.html and http://docs.openlinksw.com/virtuoso/rdfsparql.html#rdfsqlfromsparql

To be honest I have not tested it yet. I will try this tonight. In practice you might need to do a separate select for key and then insert later as you might need the key directly in your front-end application.

Simple CLI useable OWL Reasoner

2009-11-10T16:27:40Z

Hi All,

I am looking for a simple to use OWL reasoner. e.g: preferably reasoner -owl core.owl -rdf P05067.rdf which will tell me if the small P05067.rdf file contradicts any rules in the core.owl As well as show which triples are inferred. Preferably explaining which rules are the source of the contradiction and/or inference.

The use case is debugging and testing a owl or the rdf file for correctness. i.e. sometimes I want to check that the OWL file does not declare OWL legal inferences that are real world wrong. And at other times I want to check if an class instance in a RDF file does not contain contradiction.

Regards,

Jerven

e.g.

I want to check if http://purl.uniprot.org/taxonomy/9606 meets the requirements of ftp://ftp.uniprot.org/pub/databases/uniprot/current_release/rdf/core.owl without adapting either file if at all possible.

For example an owl:restriction? e.g. one of the things I think I can say in OWL is that the species in the following example must be one of the Rank instances defined in the core.owl. Using something like

@base http://purl.uniprot.org/core/ . t a :Taxon [ a owl:Restriction; owl:onProperty t:rank owl:allValuesFrom :Rank ]

@base http://purl.uniprot.org/core/ . @prefix rdf:http://www.w3.org/1999/02/22-rdf-syntax-ns# . @prefix rdfs:http://www.w3.org/2000/01/rdf-schema# . @prefix owl:http://www.w3.org/2002/07/owl# . http://purl.uniprot.org/taxonomy/9606> rdf:type :Taxon ; :rank :Species ;

As well as cardinality restricitions etc...

Answer by Jerven for Isn't the "Semantic Web" overrated?

2009-10-27T16:03:27Z

First of all the semantic web is much bigger than the social web as captured in facebook and twitter etc... which are by the way technical solutions ;)

Taking the XING and Linkedin examples. Both use custom API's to provide limited views of their data to developers. They deal with similar data although in different markets. Both have an interest in limiting the link out of capability of their users. i.e. I can't add a XING user as a linkedin connection without forcing the XING user to create an all new linkedin profile.

The semantic web is about removing such barriers and enabling linking at convenience of the user not the provider. So in that sense it is as much a social innovation as a technical one. Meaning more freedom to apply those social filters that you define in ways that are more interesting to you.

The nice thing is in application where there is no real social reason to put barriers we can reduce the cost of the technical ones by sharing our data in the semantic web. e.g. in the life sciences a common workflow is download data -> parse -> load in to database -> query -> answer. In the semantic web that is reduced to download data -> load in to 3store -> query -> answer or in the idealistic semantic web query -> federate as required over data providers -> answer. Lowering, these technical barriers using semantic web techniques means that users can spend more time on asking questions instead of enabling themselves to ask questions.

Therefore, while the concept is grandiose and does suffer from unneeded complexity in its implementation, the semantic web concept is underrated ;)

Comment by Jerven

2010-03-03T07:59:30Z

The answer that worked well is int the second suggestion. In the end I used the class that uses the property to have the restriction.

Comment by Jerven

2010-02-24T10:26:52Z

The restriction concept as defined here is correct. I want to say that if a literal is of the type date or duration then it could be a :published_in. And more importantly if the literal is not date or duration then it can not be a :published_in Thing. Meaning that if I write bla :published_in "123"^^int an OWL reasoner will tell me that the declared type of bla :published_in "123"^^int does not conform to the OWL definition of :published_in

Comment by Jerven

2010-02-24T10:16:41Z

I do find it useful. The question here is not how to test/reason on the restriction but on how to encode it.

Comment by Jerven

2010-02-22T15:25:24Z

Pellet 2.0.1 does this. And has found quite a few errors in the owl file as well as the RDF files. that we produce. ./pellet.sh consistency "uri of owl" "uri of rdf"

Comment by Jerven

2009-12-04T08:55:48Z

You can select all date items in Xpath using /*[. instance of xsd:date] (from memory). And should thus be able to transform them with XSLT

Comment by Jerven

2009-11-30T09:08:36Z

@kwijibo I remember a court case in the Netherlands about a second provider of the Dutch telephone book (early 90's). Here a second party had send a bunch of phone-books to china to get a typed copy. They then used the copy to print more copies (or CD's for call-centers) The number of typos was cause for the Judge to declare that it was likely that all data was typed (with other evidence such as contracts with the chinese party work slips etc...)

Comment by Jerven

2009-11-23T08:22:53Z

The command line options do not quite do what I want but with the owl-api (owlapi.sourceforge.net/documentation.html) I think it will not be a lot of work to get what I want exactly.

Comment by Jerven

2009-11-11T09:11:31Z

I will try to explain why I would prefer to have the instance data separate from owl definitions. I am trying to write a simple QA tool. In the UniProt release cycle there is limited time and hardware resources to do this. So I want to select a number of random entries and validate each of these separately. Preferably with as much debug information as possible when an instance conflicts with the OWL. If I can avoid merging the owl file with the rdf containing the instance data. I would strongly prefer so. However, I won't mind it if there is no other way.

Comment by Jerven

2009-11-10T17:20:20Z

Pellet certainly seems interesting. However, I am still looking at how to make it reason using owl rules in one file and rdf data in the second.