Clarification of GF<->Ontology interoperability

The following three tasks can be based on this interoperability:

  1. Natural Language Generation from ontology
  2. Translation of natural language queries to SPARQL
  3. Information extraction
  1. Natural Language Generation from ontology
  2. We could follow the scheme:
    • Determine small ontology subgraphs.
    • For each ontology subgraph define natural language patterns that describe it.
    • Define GF grammars that can parse all natural language patterns. Ramona Enache has applied similar approach for SUMO using the patterns that go with this ontology.
  3. Translation of natural language queries to SPARQL
  4. It is possible to apply the pattern approach for translation of natural language queries to SPARQL, but the resulting natural language will be very restrictive. I developed in JAVA a demo example for such very restrictive natural language for PROTON. The small ontology subgraphs encode information about persons, locations, organizations and job titles. The table below shows some examples from the demo. The left column represents the natural language queries. The right column represents their SPARQL translation.
    NATURAL LANGUAGE SPARQL
    Give me all persons associated with the organization X.
    select distinct ?person where { ?s rdf:type prt:Organization . 
                                    ?s rdfs:label "X" . 
                                    ?j prt:withinOrganization ?s . 
                                    ?person prt:hasPosition ?j . }
    
    Give me all persons and related job titles associated with the organization X. select distinct ?person ?job_title where { ?s rdf:type prt:Organization . ?s rdfs:label "X" . ?j prt:withinOrganization ?s . ?j prt:holder ?person . ?j pru:hasTitle ?job_title . }
    Give me all organizations associated with the location North America. select distinct ?organization where { ?s rdf:type prt:Location . ?s rdfs:label "North America" . ?organization prt:locatedIn ?s . ?organization rdf:type prt:Organization . }
    Give me all organizations associated with the person X. select distinct ?organization where { ?s rdf:type prt:Person . ?s rdfs:label "X" . ?j prt:holder ?s . ?j prt:withinOrganization ?organization . }
    Give me all job titles associated with the person X. select distinct ?job_title where { ?s rdf:type prt:Person . ?s rdfs:label "X" . ?j prt:holder ?s . ?j pru:hasTitle ?job_title . }
    Give me all job titles and related organizations associated with the person X. select distinct ?job_title ?organization where { ?s rdf:type prt:Person . ?s rdfs:label "X" . ?j prt:holder ?s . ?j pru:hasTitle ?job_title . ?j prt:withinOrganization ?organization . }
    Give me all organizations and related job titles associated with the person X select distinct ?organization ?job_title where { ?s rdf:type prt:Person . ?s rdfs:label "X" . ?j prt:holder ?s . ?j pru:hasTitle ?job_title . ?j prt:withinOrganization ?organization . }
    The demo example I developed does not use GF, because the available GF resource API grammers are too restrictive and cannot parse the desired sentences. Of course, most robust solution is needed. For this aim we need suitable GF grammers. If we have them, it is possible to handle the correspondence between the ontology subgraphs and the trees that result from parsing the input queries with GF.
  5. Information extraction
  6. The same holds for information extraction. If we have suitable GF grammers, it is possible to handle the correspondence between the ontology subgraphs and the trees that result from parsing the input queries with GF.