Re: missing xml:base

[Andy Seaborne]

On 23/02/2019 23:43, Chris Tomlinson wrote:

Hi Andy,


On Feb 23, 2019, at 3:14 PM, Andy Seaborne  wrote:

I thought xml:base has to be enabled in the RDF/XML writer, it's no on by 
default.

https://jena.apache.org/documentation/io/rdfxml_howto.html#advanced-rdfxml-output 



Ah! Thanks very much for pointing to docs on org.apache.jena.rdf.model.RDFWriter . 
Indeed setting the “xmlbase” property causes an xml:base to be included in the 
 header as desired:


 org.apache.jena.rdf.model.RDFWriter rdfw = m.getWriter("RDF/XML");
 rdfw.setProperty("xmlbase", "http://purl.bdrc.io/ontology/ext/auth/";);
 rdfw.write(m, System.out, "http://purl.bdrc.io/ontology/ext/auth/";);


Are there any particular issues to be aware of when using 
org.apache.jena.rdf.model.RDFWriter vs org.apache.jena.riot.RDFWriter which 
underlies {Model, OntModel}.write?


Not really - they use the same code underneath.


The latter doesn’t support a property to include xml:base in the output.


There is an example of how to set properties for RDFWriter -- pass in a 
context.


https://github.com/apache/jena/blob/master/jena-arq/src-examples/arq/examples/riot/ExRIOT_RDFXML_WriteProperties.java

which shows "showXmlDeclaration" in use. Add/change to "xmlbase"

Andy







However, we are wanting to ensure that there is an explicit baseURI present in 
the resulting serialization.


Out of curiosity, why do you want that?

Using ":" instead of a "base" seems quite common.


There are third party tools, such as TopBraid Composer FE, SE and ME, that require 
an explicit xml:base when resolving an owl:imports via the web - i.e., there is no 
matching local file - rather than using the URI in the owl:imports as the baseURI 
for the document. As I read the RDF/XML syntax spec the client is supposed to use 
the document URL for the baseURI when no xml:base is present. The TBC uses an 
"Accept: application/rdf+xml, text/turtle” and with such a list RDF/XML is 
selected (the service can provide both serializations).

A solution, when serializing as RDF/XML, might be to use Model.write(OutputStream, 
“RDF/XML", null) or Model.write(OutputStream, “RDF/XML”), which forces absolute 
paths to be used in the output; however, without the (unnecessary) xml:base, TBC 
fails silently to load the imports. By comparison, Protégé has no problem correctly 
following owl:imports.

We’re just trying to provide proper content negotiation and accommodate the 
dictum that the client makes it right.

Based on the javadoc for Model.write parameter, base:


base The base uri to use when writing relative URI's. null means use only 
absolute URI's. This is used for relative URIs that would be resolved against 
the document retrieval URL. For some values of lang, this value may be included 
in the output.


It is unclear of what use a non-null value for XML/RDF is since the resulting 
output has no xml:base, the URL of the doc can not be necessarily relied on, 
and the output is rendered ambiguous since relative URIs can’t be resolved 
unless perhaps the default namespace, denoted by “:”, is used..

The write w/ an explicit baseURI could output an explicit xml:base (as an @base 
is written for Turtle) or as also suggested by the javadoc simply use the 
supplied baseURI to construct the proper URIs for values of rdf:about etc on 
output.




Andy


Thank you,
Chris












On 23/02/2019 00:42, Martynas Jusevičius wrote:

Sorry, can't run the test case right now.
No I'm thinking RDF/XML :) But the prefixes are only used for
properties, not subject (@rdf:about) or object (@rdf:resource) values.
What would you gain by adding an xml:base? You could shorten
prfx:lcl-name to just lcl-name by setting xml:base to prfx: namespace
URI, but that would only work for a single namespace.
And not sure how much sense it makes to compare RDF/XML with Turtle
because the former builds on XML which has its own namespace
mechanism. But maybe I'm completely misunderstanding what you are
trying to do :)
On Sat, Feb 23, 2019 at 12:18 AM Chris Tomlinson
 wrote:


No.

If you run the test case you see that RDF/XML writes out xmlns defns of 
prefixes and uses the prefixes in the serialization. Perhaps you are thinking 
of n-triples.

Thanks,
Chris


On Feb 22, 2019, at 16:52, Martynas Jusevičius  wrote:

Isn't it so that RDF/XML writer always writes absolute URIs, so
xml:base is unnecessary because it would have no effect anyway?

On Fri, Feb 22, 2019 at 11:20 PM Chris Tomlinson
 wrote:


Hello,

We are trying to serve various ontology files in a variety of serializations, 
principally RDF/XML and Turtle.

The specs indicate that if the baseURI for an ontology is the URL by which the 
ontology is retrieved then it is not required that the producer include an 
explicit xml:base or @base or similar in the serialization.

However, we are wanting to ensure that there is an explicit baseURI present

Re: Inverse SPARQL Property Path won't match non-distinct [bug?]

[Kevin Dreßler]

Apologies for double posting, but I just tried to delete the "?" modifier as I 
only needed it in my original query and not in the example provided here.
After that, it works as expected. So it's not simply tied to inverse property 
paths but to this combination of inverse property path with optional property 
path.

Can anyone make sense of this?

> On 24. Feb 2019, at 16:43, Kevin Dreßler  wrote:
> 
> Hello ,
> 
> I have come across an unexpected behaviour with inverse property paths, but 
> maybe I am just missing something basic here.
> I wrote a query to get from the entries in an RDF list to the resource which 
> has the list as predicate value using inverse property paths.
> As I had duplicate entries in the list I expected to get duplicate 
> QuerySolutions as I would when using the normal direction.
> However, using inverse property paths seem to result in a behaviour as if I 
> had specified DISTINCT in my query.
> Please see the example gist here: 
> https://gist.github.com/kdrsslr/c8711f962a7b793dc48222944fd3ed89 
> 
> 
> Is there an explanation for this kind of behaviour?
> 
> Thanks in advance,
> Kevin

Inverse SPARQL Property Path won't match non-distinct [bug?]

[Kevin Dreßler]

Hello ,

I have come across an unexpected behaviour with inverse property paths, but 
maybe I am just missing something basic here.
I wrote a query to get from the entries in an RDF list to the resource which 
has the list as predicate value using inverse property paths.
As I had duplicate entries in the list I expected to get duplicate 
QuerySolutions as I would when using the normal direction.
However, using inverse property paths seem to result in a behaviour as if I had 
specified DISTINCT in my query.
Please see the example gist here: 
https://gist.github.com/kdrsslr/c8711f962a7b793dc48222944fd3ed89 


Is there an explanation for this kind of behaviour?

Thanks in advance,
Kevin