Re: % character in mailto: URI

2019-08-31 Thread Kevin Dreßler
Possible origin of this weird percent character (for the curious): 
http://www.faqs.org/docs/linux_network/x-087-2-mail.address.html 
 (17.3.3).

In this case, you could also sanitize your dataset by removing the strings 
starting at the percent character up to the @ character from all mailto: URIs 
in your dataset.


> On 31. Aug 2019, at 13:50, Laura Morales  wrote:
> 
>> Is  not a legal mailto: URI? Or does it
>> need to be encoded somehow?
> 
> That is not a legal URI, strictly speaking. Look up 
> https://en.wikipedia.org/wiki/Percent-encoding
> I've never in my life seen an email address with a percent sign, but if you 
> *must* use it then you have to encode it, it becomes something like 
> 



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

2019-02-24 Thread 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 
> <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?]

2019-02-24 Thread 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

Re: Fuseki 2: Serving RDF/XML over HTTP

2019-01-15 Thread Kevin Dreßler
Thanks Andy, that helped a lot indeed!

Best,
Kevin

> On 14. Jan 2019, at 17:13, Andy Seaborne  wrote:
> 
> The problem is that you are asking the dataset for RDF/XML.
> 
> Datasets include the named graphs.  It needs TriG or N-Quads.
> 
> So you ask for RDF/XML, and content negotiation says "can't - here's nmy 
> default (which is N-Quads) and then the code ignores the Content-type and 
> forces RDF/XML. It then fails to parse.
> 
> 
> This works for me - ask for the default graph:
> 
> "http://localhost:"+PORT+"/birch?default;
> 
> Below is that done twice - using RDFConnection and as in the example.
> 
> Fuseki logging is turned on which can help debug conneg.
> 
>Andy
> 
> public static void main(String[] args) throws Exception {
> 
>FusekiLogging.setLogging();
>int PORT = WebLib.choosePort();
> 
>FusekiServer server = FusekiServer.create()
>.port(PORT)
>.verbose(true)
>.add("/birch", DatasetFactory.createTxnMem())
>.build();
>server.start();
>// Server startup.
>Lib.sleep(100);
> 
>// Version 1
>try (RDFConnection conn = RDFConnectionRemote
>.create()
>.destination("http://localhost:"+PORT+"/birch;)
>.acceptHeaderGraph("application/rdf+xml")
>.build()) {
>Model model = conn.fetch();
>RDFDataMgr.write(System.out,  model, Lang.RDFXML);
>}
> 
>// Version 2
>URL url = new URL("http://localhost:"+PORT+"/birch?default;);
> 
>URLConnection conn = url.openConnection();
>conn.setRequestProperty("Accept", "application/rdf+xml");
>Model model = ModelFactory.createDefaultModel();
>model.read(conn.getInputStream(), null);
> //RDFDataMgr.read(model, conn.getInputStream(), Lang.RDFXML);
>RDFDataMgr.write(System.out,  model, Lang.RDFXML);
>System.exit(0);
> }


Re: Fuseki 2: Serving RDF/XML over HTTP

2019-01-14 Thread Kevin Dreßler
Sorry for double posting but I might add that with this code I get the 
following Exception:

java.lang.RuntimeException: org.apache.jena.riot.RiotException: [line: 1, col: 
7 ] Element or attribute do not match QName production: 
QName::=(NCName':')?NCName. 
at 
org.aksw.deer.enrichments.DereferencingEnrichmentOperator.queryResourceModel(DereferencingEnrichmentOperator.java:231)

And when I change 

ModelFactory.createDefaultModel().read(conn.getInputStream(), null)

to

ModelFactory.createDefaultModel().read(conn.getInputStream(), null, 
"TURTLE")

but leave

conn.setRequestProperty("Accept", "application/rdf+xml")

unchanged, it works as expected.

Using curl I see that Fuseki indeed delivers TURTLE:

$ curl -H "Accept: application/rdf+xml" http://localhost:32537/birch
<http://localhost:32537/birch> <http://localhost:32537/brinellHardness> 
"27"^^<http://www.w3.org/2001/XMLSchema#int> .

I am on Jena 3.9.0.

Hope thats enough information.

Best,
Kevin

> On 14. Jan 2019, at 16:29, Kevin Dreßler  wrote:
> 
> This is the method where I do the request and which I effectively want to 
> test:
> 
>  private Model queryResourceModel(Resource o) {
>URL url;
>URLConnection conn;
>Model result = ModelFactory.createDefaultModel();   
>try {
>  url = new URL(o.getURI());
>} catch (MalformedURLException e) {
>  e.printStackTrace();
>  return result;
>}
>try {
>  conn = url.openConnection();
>  conn.setRequestProperty("Accept", "application/rdf+xml");
>  conn.setRequestProperty("Accept-Language", "en");
>  return ModelFactory.createDefaultModel()
>.read(conn.getInputStream(), null);
>} catch (ConnectException e) {
>  if (e.getMessage().contains("refused")) {
>throw new RuntimeException(e);
>  }
>} catch (Exception e) {
>  throw new RuntimeException(e);
>    }
>    return result;
>  }
> 
> 
>> On 14. Jan 2019, at 15:09, ajs6f  wrote:
>> 
>> Please show the code you are actually using to make requests.
>> 
>> ajs6f
>> 
>>> On Jan 14, 2019, at 9:06 AM, Kevin Dreßler  wrote:
>>> 
>>> Hello, 
>>> 
>>> for unit testing I need to mock up a HTTP server delivering RDF/XML per 
>>> content negotiation (Accept: application/rdf+xml). For a HTTP request on 
>>> http://myEndpoint:myPort/test with the "Accept" header set as above it 
>>> should output DESCRIBE(http://myEndpoint:myPort/test) as RDF/XML, so 
>>> basically I want to mimic DBpedia. Is there a way to do this with a minimal 
>>> amount of configuration inside my tests using FUSEKI 2?
>>> Right now I am using the following code but I get the output only as TURTLE.
>>> 
>>>  String EX = "http://localhost:32537/;;
>>> 
>>>  Model lookup = ModelFactory.createDefaultModel();
>>>  lookup.add(lookup.createResource(EX + "birch"),
>>>lookup.createProperty(EX + "brinellHardness"),
>>>lookup.createTypedLiteral(27));
>>> 
>>>  FusekiServer server = FusekiServer.create()
>>>.add("/birch", DatasetFactory.create(lookup))
>>>.port(32537)
>>>.build();
>>>  server.start();
>>> 
>>> Thanks in advance,
>>> Kevin
>> 
> 



Fuseki 2: Serving RDF/XML over HTTP

2019-01-14 Thread Kevin Dreßler
Hello, 

for unit testing I need to mock up a HTTP server delivering RDF/XML per content 
negotiation (Accept: application/rdf+xml). For a HTTP request on 
http://myEndpoint:myPort/test with the "Accept" header set as above it should 
output DESCRIBE(http://myEndpoint:myPort/test) as RDF/XML, so basically I want 
to mimic DBpedia. Is there a way to do this with a minimal amount of 
configuration inside my tests using FUSEKI 2?
Right now I am using the following code but I get the output only as TURTLE.

String EX = "http://localhost:32537/;;

Model lookup = ModelFactory.createDefaultModel();
lookup.add(lookup.createResource(EX + "birch"),
  lookup.createProperty(EX + "brinellHardness"),
  lookup.createTypedLiteral(27));

FusekiServer server = FusekiServer.create()
  .add("/birch", DatasetFactory.create(lookup))
  .port(32537)
  .build();
server.start();

Thanks in advance,
Kevin

Re: Persistent Model Implementation

2018-10-22 Thread Kevin Dreßler
Thanks for your quick reply!

> On 22. Oct 2018, at 12:19, ajs6f  wrote:
> 
> The TIM dataset implementation [1] is backed by persistent data structures 
> (for the confused, the term "persistent" here means in the sense of immutable 
> [2]-- it has nothing to do with disk storage). However, nothing there goes 
> beyond the Node/Triple/Graph/DatasetGraph SPI-- the underlying structures 
> aren't exposed and can't be reused by clients.

This looks interesting but I don't think it actually matches my use case. 
However, I think I would want a transactional commit in my implementation to 
improve performance so that I could collect a set of statements and only create 
a new immutable instance of the model when committing all of these together 
instead of after each single statement.

> This sounds like an interesting and powerful use case, although I'm not sure 
> how easily it could be accomplished within the current API. For one thing, we 
> don't have a good way of distinguishing mutable and immutable models in 
> Jena's type system right now.
> 
> Are the "k new Models" both adding and removing triples? If they're just 
> adding triples, perhaps a clever wrapper might work.

Both addition and deletion of triples is possible. But the wrapper idea is nice 
and might actually work for both addition and deletion, as I could try to cache 
a set of Statements that have been deleted as long as this caches size is under 
x% of the base models size.

> Otherwise, have you tried using an intermediating caching setup, wherein 
> statements that are copied are routed through a cache that prevents 
> duplication? I believe Andy deployed a similar technique for some of the TDB 
> loading code and saw great improvement therefrom.

I just started researching this so I haven't done anything in this direction. 
Do you believe the wrapper / caching approach would be feasible with the 
current API? I am not very familiar with Jenas implementations but from my 
experience with the API it seems that every RDFNode has a reference to the 
model from which it was retrieved (if any). So in order to not violate API 
contracts I think I would also need to wrap each resource upon retrieval to 
point to the wrapper model instead of the base model?

> ajs6f
> 
> [1] https://jena.apache.org/documentation/rdf/datasets.html
> [2] https://en.wikipedia.org/wiki/Persistent_data_structure
> 
>> On Oct 22, 2018, at 12:08 PM, Kevin Dreßler  wrote:
>> 
>> Hello everyone,
>> 
>> I have an application using Jena where I frequently have to create copies of 
>> Models in order to then process them individually, i.e. all triples of one 
>> source Model are added to k new Models which are then mutated.
>> 
>> For larger Models this obviously takes some time and, more relevant for me, 
>> creates a considerable amount of memory pressure.
>> However, with a Model implementation based on persistent data structures I 
>> could eliminate most of these issues as the amount of data changed is 
>> typically under 5% compared to the overall Model size.
>> 
>> Has anyone ever done something like this before, i.e. are there immutable 
>> Model implementations with structural sharing that someone is aware of? If 
>> not what would be your advice on how one would approach implementing this in 
>> their own code base?
>> 
>> Best regards,
>> Kevin



Persistent Model Implementation

2018-10-22 Thread Kevin Dreßler
Hello everyone,

I have an application using Jena where I frequently have to create copies of 
Models in order to then process them individually, i.e. all triples of one 
source Model are added to k new Models which are then mutated.

For larger Models this obviously takes some time and, more relevant for me, 
creates a considerable amount of memory pressure.
However, with a Model implementation based on persistent data structures I 
could eliminate most of these issues as the amount of data changed is typically 
under 5% compared to the overall Model size.

Has anyone ever done something like this before, i.e. are there immutable Model 
implementations with structural sharing that someone is aware of? If not what 
would be your advice on how one would approach implementing this in their own 
code base?

Best regards,
Kevin

Re: Example code

2018-03-19 Thread Kevin Dreßler
> 
> On 19. Mar 2018, at 08:31, David Moss  wrote:
> 
> [...]
>I see this kind of example as the missing link that prevents anyone other 
> than expert using Jena.
>So long as easy to follow examples of how to get from an rdf triplestore 
> to information displayed on a screen in a standard GUI way are missing, Jena 
> will remain a plaything for expert enthusiasts.

By that argumentation MySQL will also forever remain a plaything for expert 
enthusiasts, as I couldn't find any example in their documentation about how 
you set up GUI controls with values obtained from MySQL.
What you are after is probably a kind of end-to-end tutorial to a certain tech 
stack and I agree that there are probably far less of those for linked data 
tech stacks than for more traditional ways of doing things. But the Apache Jena 
documentation is certainly not the right place for such content just as you 
won't find complete AMP stack tutorials in the MySQL documentation.