atextor / owl-cli Goto Github PK

test.ttl:

@prefix ex: 	<http://example.com/> .
@prefix ex1: 	<http://example.com/level1/> .

<http://example.com/level1/Hello> a <http://example.com/Test> .

owl write test.ttl generates:

@prefix ex: <http://example.com/> .
@prefix ex1: <http://example.com/level1/> .

ex:level1\/Hello a ex:Test .

(changing the order of the prefix declarations in test.ttl doesn’t help)

I think this output would be preferable:

ex1:Hello a ex:Test .

owl-cli currently uses the RDF parser from Apache Jena's jena-core, which happens to handle escape sequences in URIs differently (wrongly?) than jena-arq's RIOT system. Parsing the following document (note the backslash in the URI) should not fail, but leads to a parser error:

@prefix dc:      <http://purl.org/spar/datacite/> .
@prefix doi:     <https://doi.org/> .
@prefix : <http://example.org#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

:something a :publication ;
    rdfs:label "Paper title" ;
    dc:hasIdentifier doi:10.1137\/1.9781611970937 .

Basically, this can be fixed by adding jena-arq as a dependency. Due to the override of Jena's Subsystem Registry for the GraalVM build, this is not enough here. Everything that jena-arq provides via META-INF/services needs to be hardwired into the StaticJenaSubsystemRegistry.

Originally reported at atextor/turtle-formatter#3

It would be really helpful if the project had a Dockerfile. ASFAI, currently, there isn't one, which makes it difficult to use owl-cli on some environments. Having a Dockerfile would allow users to easil run the project in a container, making it much easier to manage dependencies (e.g. Graphviz) and isolate the project from the host environment.

It would be great if a maintainer could add a Dockerfile to the project. And I'm willing to contribute a Dockerfile to the project, if needed.

Thanks ❤️

Hello, there!

As part of the university research we are currently doing regarding the security of Github Actions, we noticed that one or many of the workflows that are part of this repository are referencing vulnerable versions of the third-party actions. As part of a disclosure process, we decided to open issues to notify GitHub Community.

Please note that there are could be some false positives in our methodology, thus not all of the open issues could be valid. If that is the case, please let us know, so that we can improve on our approach. You can contact me directly using an email: ikoishy [at] ncsu.edu

Thanks in advance

1. The workflow build.yml is referencing action ilammy/msvc-dev-cmd using references v1.5.0. However this reference is missing the commit 74a501b which may contain fix to the vulnerability.

The vulnerability fix that is missing by actions' versions could be related to:
(1) CVE fix
(2) upgrade of vulnerable dependency
(3) fix to secret leak and others.
Please consider updating the reference to the action.

If you end up updating the reference, please let us know. We need the stats for the paper :-)

owl write doesn’t seem to handle a prefixed name’s local part correctly if it starts with : (which seems to be an allowed start character).

Test 1

test_1.ttl:

@prefix ex: <https://example.org/> .

ex::Hello a ex:Test .

owl write test_1.ttl generates:

@prefix ex: <https://example.org/> .

ex: a ex:Test .

Test 2

test_2.ttl:

@prefix ex: <https://example.org/> .

<https://example.org/:Hello> a <https://example.org/Test> .

owl write test_2.ttl generates:

@prefix ex: <https://example.org/> .

ex: a ex:Test .

Nice job on owl write! A very useful tool to have around.

I was, however, surprised to see some unexpected quoting of hyphens in the result:

Test case

 $ echo '@prefix foo-bar: <http://foo.com/bar>  foo-bar:s foo-bar:p 42' | owl write -

Expected result

@prefix foo-bar: <http://foo.com/bar> .

foo-bar:s foo-bar:p 42 .

Actual result

@prefix foo-bar: <http://foo.com/bar> .

foo\-bar:s foo\-bar:p 42 .

As far as I know, foo-bar is a legal prefix name in Turtle, without needing the hyphen to be protected. Is this a writer bug, or
is there an option I should be setting to prevent this escaping?

Version info

$ owl --version ; java --version ; lsb_release -a
owl-cli version: snapshot build date: 2022-01-25 06:17:26
openjdk 11.0.16 2022-07-19
OpenJDK Runtime Environment (build 11.0.16+8-post-Ubuntu-0ubuntu122.04)
OpenJDK 64-Bit Server VM (build 11.0.16+8-post-Ubuntu-0ubuntu122.04, mixed mode, sharing)
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 22.04.1 LTS
Release:	22.04
Codename:	jammy

Take this file with escaped double quotes (\"") at the end of a string:
quote_issue_org.txt
run:

owl-x86_64-linux-1.2.3 write quote_issue_org.txt  quote_issue_orgi_2.txt

All goes well, compare the files quote_issue_org.txt and quote_issue_org_2.txt and note the differences.

Next run:

owl-x86_64-linux-1.2.3 write quote_issue_org_2.txt quote_issue_org_3.txt

The result is:

2023-07-10 19:20:11,930 ERROR o.a.j.riot: [line: 10, col: 1 ] Broken token (newline): @nl .
Error: [line: 10, col: 1 ] Broken token (newline): @nl .

Note that changing the """" in quote_issue_org_2.txt into " """ makes owl-cli work again

If you apply owl-cli write on this ontology:

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix myont: <https://myontology/> .
@prefix sh: <http://www.w3.org/ns/shacl#> .

myont:MyClass-type rdf:type sh:PropertyShape ;
  sh:path rdf:type .

the results is:

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix myont: <https://myontology/> .
@prefix sh: <http://www.w3.org/ns/shacl#> .

myont:MyClass-type a sh:PropertyShape ;
  sh:path a .

The resulting last line sh:path a . looks weird (maybe even incorrect, I'm not sure, but some software fails on it).

I would expect that rdf:type in the last line was not replaced by a. So the line should stay as it was: sh:path rdf:type ..

When trying to use owl write with a Turtle file that gets a prefixed name’s local part that starts with $, an error is thrown.

The expected behaviour, I think, would be to escape it (as it’s not allowed to be a start character):

ex:\$10 a ex:Test .

test.ttl:

@prefix ex: <https://example.org/> .

<https://example.org/$10> a <https://example.org/Test> . # valid

owl write test.ttl output:

@prefix ex: <https://example.org/> .

Error: Illegal group reference: group index is missing

Issue:

I encounter an issue when using the owl-cli tool to pretty print RDF/Turtle documents. It appears that the generation of the formatted documents is not stable when the input document contains several blank nodes, resulting in different output each time the owl-cli write command is run. This is unexpected behavior makes it difficult to use owl-cli for standardizing the Turtle documents in a continuous integration (CI) environment, as I would have liked.

To reproduce:

Given the following turtle document as input:

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix : <http://example.com/relations#> .

:Foo a owl:Class ;
  rdfs:subClassOf [
    a owl:Restriction ;
    owl:minQualifiedCardinality "0"^^xsd:nonNegativeInteger ;
    owl:onDataRange xsd:dateTime ;
    owl:onProperty :a ;
  ] ;
  rdfs:subClassOf [
    a owl:Restriction ;
    owl:allValuesFrom xsd:dateTime ;
    owl:onProperty :b ;
  ] .

When invoking the following command line:

owl-cli test.ttl test-formatted.ttl

It gives either:

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix : <http://example.com/relations#> .

:Foo a owl:Class ;
  rdfs:subClassOf [
    a owl:Restriction ;
    owl:minQualifiedCardinality "0"^^xsd:nonNegativeInteger ;
    owl:onDataRange xsd:dateTime ;
    owl:onProperty :a ;
  ] ;
  rdfs:subClassOf [
    a owl:Restriction ;
    owl:allValuesFrom xsd:dateTime ;
    owl:onProperty :b ;
  ] .

or:

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix : <http://example.com/relations#> .

:Foo a owl:Class ;
  rdfs:subClassOf [
    a owl:Restriction ;
    owl:allValuesFrom xsd:dateTime ;
    owl:onProperty :b ;
  ] ;
  rdfs:subClassOf [
    a owl:Restriction ;
    owl:minQualifiedCardinality "0"^^xsd:nonNegativeInteger ;
    owl:onDataRange xsd:dateTime ;
    owl:onProperty :a ;
  ] .

See diff:

9,11c9,10
<     owl:minQualifiedCardinality "0"^^xsd:nonNegativeInteger ;
<     owl:onDataRange xsd:dateTime ;
<     owl:onProperty :a ;
---
>     owl:allValuesFrom xsd:dateTime ;
>     owl:onProperty :b ;
15,16c14,16
<     owl:allValuesFrom xsd:dateTime ;
<     owl:onProperty :b ;
---
>     owl:minQualifiedCardinality "0"^^xsd:nonNegativeInteger ;
>     owl:onDataRange xsd:dateTime ;
>     owl:onProperty :a ;

I suspect that blank nodes are assigned a random identifier that changes the lexicographic order of objects. Maybe there are additional options to gain control over the order?

Context:

• version: owl-x86_64-linux-1.2.2

test.ttl:

@prefix ex: <https://example.org/> .

<https://example.org/-10> a <https://example.org/Test> .

owl write test.ttl generates:

@prefix ex: <https://example.org/> .

ex:-10 a ex:Test .

If I’m not mistaken, the generated Turtle is invalid, because the local part of a prefixed name must not start with -.

(The same issue exists for ., and maybe also other characters.)

Allowed first character in the local part of a prefixed name

If I read it correctly, the local part may start with (PN_CHARS_U | ':' | [0-9] | PLX). Following the references, this seems to be the list of allowed start characters:

• _
• :
• % (followed by HEX HEX)
• \ (followed by one of: _ ~ . - ! $ & ' ( ) * + , ; = / ? # @ %)
• [0-9]
• [A-Z]
• [a-z]
• [#x00C0-#x00D6]
• [#x00D8-#x00F6]
• [#x00F8-#x02FF]
• [#x0370-#x037D]
• [#x037F-#x1FFF]
• [#x200C-#x200D]
• [#x2070-#x218F]
• [#x2C00-#x2FEF]
• [#x3001-#xD7FF]
• [#xF900-#xFDCF]
• [#xFDF0-#xFFFD]
• [#x10000-#xEFFFF]