Re: Replacement for CSVInput and TSVInput?

[Andy Seaborne]

ResultsSetMgr which uses ResultsReader


On 12/12/2022 15:45, Martynas Jusevičius wrote:

Hi,

I'm upgrading Jena 4.5.0 to 4.6.1.

I can see that org.apache.jena.sparql.resultset.CSVInput is gone and
org.apache.jena.sparql.resultset.TSVInput is deprecated.

What are the replacements for them?

My code was the following:

 if 
(mediaType.isCompatible(com.atomgraph.core.MediaType.APPLICATION_SPARQL_RESULTS_XML_TYPE))
 return
ResultSetFactory.makeRewindable(ResultSetFactory.fromXML(in));
 if 
(mediaType.isCompatible(com.atomgraph.core.MediaType.APPLICATION_SPARQL_RESULTS_JSON_TYPE))
 return
ResultSetFactory.makeRewindable(ResultSetFactory.fromJSON(in));
 if 
(mediaType.isCompatible(com.atomgraph.core.MediaType.APPLICATION_SPARQL_RESULTS_CSV_TYPE))
 return ResultSetFactory.makeRewindable(CSVInput.fromCSV(in));
 if 
(mediaType.isCompatible(com.atomgraph.core.MediaType.APPLICATION_SPARQL_RESULTS_CSV_TYPE))
 return ResultSetFactory.makeRewindable(TSVInput.fromTSV(in));

Thanks.

Martynas
atomgraph.com

Replacement for CSVInput and TSVInput?

[Martynas Jusevičius]

Hi,

I'm upgrading Jena 4.5.0 to 4.6.1.

I can see that org.apache.jena.sparql.resultset.CSVInput is gone and
org.apache.jena.sparql.resultset.TSVInput is deprecated.

What are the replacements for them?

My code was the following:

if 
(mediaType.isCompatible(com.atomgraph.core.MediaType.APPLICATION_SPARQL_RESULTS_XML_TYPE))
return
ResultSetFactory.makeRewindable(ResultSetFactory.fromXML(in));
if 
(mediaType.isCompatible(com.atomgraph.core.MediaType.APPLICATION_SPARQL_RESULTS_JSON_TYPE))
return
ResultSetFactory.makeRewindable(ResultSetFactory.fromJSON(in));
if 
(mediaType.isCompatible(com.atomgraph.core.MediaType.APPLICATION_SPARQL_RESULTS_CSV_TYPE))
return ResultSetFactory.makeRewindable(CSVInput.fromCSV(in));
if 
(mediaType.isCompatible(com.atomgraph.core.MediaType.APPLICATION_SPARQL_RESULTS_CSV_TYPE))
return ResultSetFactory.makeRewindable(TSVInput.fromTSV(in));

Thanks.

Martynas
atomgraph.com

Re: How to handle optional lists in SPARQL

[Lorenz Buehmann]

I don't know your full query restrictions, but without given properties 
it would be a "simple" property path, no? Something like


owl:someValuesFrom/((owl:intersectionOf|owl:unionOf)/list:member)?

where the list closure is optional and if you want to make it nestested

(owl:someValuesFrom/((owl:intersectionOf|owl:unionOf)/list:member)?)*

So a query like

prefix rdfs: 
prefix owl: 
prefix list: 

select * {
?subclass rdfs:subClassOf|owl:equivalentClass 
[(owl:intersectionOf|owl:unionOf)/list:member/(owl:someValuesFrom/((owl:intersectionOf|owl:unionOf)/list:member)?)* 
?m]

FILTER(isIRI(?m))
}

could work. You could even try to make it more generic.


But maybe you have different requirements, in that case it would be 
easier to help with sample data. My sample data now was


@prefix : 
 
.

@prefix owl:  .
@prefix rdf:  .
@prefix xml:  .
@prefix xsd:  .
@prefix rdfs:  .

:Foo rdf:type owl:Class ;
 owl:equivalentClass [ rdf:type owl:Class ;
   owl:unionOf ( :A
 [ rdf:type owl:Restriction ;
   owl:onProperty :p ;
   owl:someValuesFrom [ 
rdf:type owl:Class ;

owl:unionOf ( :B
[ rdf:type owl:Restriction ;
owl:onProperty :q ;
owl:someValuesFrom :C
]
)
  ]
 ]
   )
 ] .


Cheers,

Lorenz

On 12.12.22 13:49, Mikael Pesonen wrote:


Is there a shortcut for making queries where a data value can be 
single item or list of items?


For example this is how I do a query now using UNION. Both parts are 
identical except for the single/list section in owl:someValuesFrom []. 
This is still somewhat readable but if there are multiple occurences, 
query lenght and complexity grows exponentially.


{
    ?finding owl:equivalentClass|rdfs:subClassOf [
        owl:intersectionOf [
            list:member [
                rdf:type owl:Restriction ;
                owl:onProperty id:609096000 ;
                owl:someValuesFrom [
                    rdf:type owl:Restriction ;
                    owl:onProperty id:363698007 ;
                    owl:someValuesFrom ?site
                ]
            ]
        ]
    ]
    }
    UNION
    {
    ?finding owl:equivalentClass|rdfs:subClassOf [
        owl:intersectionOf [
            list:member [
                rdf:type owl:Restriction ;
                owl:onProperty id:609096000 ;
                owl:someValuesFrom [
                    owl:intersectionOf [
                        list:member [
                            rdf:type owl:Restriction ;
                            owl:onProperty id:363698007 ;
                            owl:someValuesFrom ?site
                        ]
                    ]
                ]
            ]
        ]
    ]
    }

The data is not ours so we can't make everything lists.

How to handle optional lists in SPARQL

[Mikael Pesonen]

Is there a shortcut for making queries where a data value can be single 
item or list of items?


For example this is how I do a query now using UNION. Both parts are 
identical except for the single/list section in owl:someValuesFrom []. 
This is still somewhat readable but if there are multiple occurences, 
query lenght and complexity grows exponentially.


{
    ?finding owl:equivalentClass|rdfs:subClassOf [
        owl:intersectionOf [
            list:member [
                rdf:type owl:Restriction ;
                owl:onProperty id:609096000 ;
                owl:someValuesFrom [
                    rdf:type owl:Restriction ;
                    owl:onProperty id:363698007 ;
                    owl:someValuesFrom ?site
                ]
            ]
        ]
    ]
    }
    UNION
    {
    ?finding owl:equivalentClass|rdfs:subClassOf [
        owl:intersectionOf [
            list:member [
                rdf:type owl:Restriction ;
                owl:onProperty id:609096000 ;
                owl:someValuesFrom [
                    owl:intersectionOf [
                        list:member [
                            rdf:type owl:Restriction ;
                            owl:onProperty id:363698007 ;
                            owl:someValuesFrom ?site
                        ]
                    ]
                ]
            ]
        ]
    ]
    }

The data is not ours so we can't make everything lists.