Closed atextor closed 9 years ago
Yes, currently Xturtle cannot find a corresponding subject and hence shows a linking error. The simplest solution would be suppressing any linking errors for rdf:_<number>
and rdf:li
.
Could you (and possibly @seebi) comment on the following issues. Is the proposed trivial solution sufficient?
How about list properties outside collections?
<x> rdf:_3 rdf:li .
...
I guess nobody would write that, but would you expect Xturtle to complain? What about incorrect numbering?
[ a rdf:Seq ;
rdf:_2 "foo" ;
rdf:_5 "bar"
] .
I assume list properties should never be linked, i.e. it should never be used as a subject which would cause successful linking.
Proposed first implementation:
Note that you can already use <http://www.w3.org/1999/02/22-rdf-syntax-ns#_1>
instead of rdf:_1
und disable linking validation for unknown URIs.
Another option is to add rdf:_1 to rdf:_100 to the core vocabulary :-)
maybe the best way is to introduce a new config option "not-resolved-namespaces" where the URI prefixes are listed where the linking errors are suppressed.
beside that, a user maybe has other namespaces ...
Having a configurable list is indeed the most flexible solution. I'd do that as step 2 (the two prefixes you give would be hard coded first and would then be shipped as default. What about suppressing (error or warning?) list properties as subjects in order to prevent unintended linking? Using URI-prefixes for the configuration has a drawback: rdf:li could be the prefix of a subject for which linking errors should be raised.
I think the most sane path would be suppressing linking errors for rdf:_<number>
and rdf:li
specifically, and introducing a configurable list (for dbpedia and the likes) with rdf
not in it by default. Here's why: Although container membership properties outside collections don't make a whole lot of sense, there's nohing I see in the spec that prohibits this. rdf:_<number>
are standard RDF properties and therefore should be usable as one sees fit. Jena processes them without complaint (as it should, IMHO):
$ cat test.ttl
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
rdf:_2 a rdf:Resource .
$ riot --syntax=turtle --formatted=rdfxml test.ttl
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Resource rdf:about="http://www.w3.org/1999/02/22-rdf-syntax-ns#_2"/>
</rdf:RDF>
The same holds for incorrect numbering, arguably:
$ cat test2.ttl
@prefix : <http://example.com/foo#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
[ a rdf:Seq;
rdf:_2 "foo";
rdf:_5 "bar"
].
$ riot --syntax=turtle --formatted=rdfxml test2.ttl
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns="http://example.com/foo#">
<rdf:Seq>
<rdf:_5>bar</rdf:_5>
<rdf:_2>foo</rdf:_2>
</rdf:Seq>
</rdf:RDF>
A warning would be nice here, though.
I would not want to put rdf
in the linking error suppression list, because of common typos (e.g., rdf:label
).
The actual suggestion was to put rdf followed by underscore in the error suppression list.
I still have a problem with allowing rdf:_1 as subject for the following reason. If Xturtle allows it and I enable refactoring, e.g. renaming subject rdf:_1 to rdf:one, because of successful linking, all rdf:_1 will be affected.
I guess, I will end up with another validation config element - how to treat rdf list properties as subject...
I see, that makes sense. I think disallowing rdf:_n as subject won't pose any problems in real life.
As indicated, linking errors will be suppressed for list properties which are also not allowed as subjects. If an unlinked URL starts with one of the prefixes configured via the validation preference page, no linking error is raised.
These changes are available on the snapshot update site.
works like a charm.
but I do not find the preference page ???
At the bottom of Preferences->Xturtle->Validation; it is not a separate preference page.
I do not have a Validation under Xturtle ...
It seems, you have opened the properties of the project, not the Eclipse Preference page (Menu Eclipse->Preferences or command +,).
correct ... found it :satisfied:
RDF container membership properties give a syntax error. The following minimal example should work: