You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Dick Murray <da...@googlemail.com> on 2012/02/06 16:02:29 UTC
InvalidPropertyURIException thrown
This line of code;
ResourceFactory.createProperty("http://id.example.org/column#99");
or;
ResourceFactory.createProperty("http://id.example.org/column/99");
throws the following error.
Exception in thread "main"
com.hp.hpl.jena.shared.InvalidPropertyURIException:
http://id.example.org/column#99
at
com.hp.hpl.jena.rdf.model.impl.PropertyImpl.checkLocalName(PropertyImpl.java:83)
at
com.hp.hpl.jena.rdf.model.impl.PropertyImpl.<init>(PropertyImpl.java:72)
at
com.hp.hpl.jena.rdf.model.ResourceFactory$Impl.createProperty(ResourceFactory.java:241)
at
com.hp.hpl.jena.rdf.model.ResourceFactory.createProperty(ResourceFactory.java:109)
at com.unit4.scratch.Scratch2.main(Scratch2.java:11)
The PropertyImpl( String uri ) contructor makes a call to
checkLocalName() which throws the exception if (localName == null ||
localName.equals( "" )).
How come the property URI isn't valid please?
Re: InvalidPropertyURIException thrown
Posted by Ian Dickinson <ia...@epimorphics.com>.
On 06/02/12 22:57, Dick Murray wrote:
> Hi Andy and thanks for the added confusion! :-)
>
> So Jena will actively generate namespaces (xmlns:j.x) where it can?
Unless the namespace is already allocated in the model
> It
> works backwards through the property until it hits a non valid NCName
> char and that's the namespace/localname split. The writer must keep
> track of the j.n entries for RDF/XML...
>
> i.e. your example gives;
>
> <rdf:RDF
> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
> xmlns:j.0="http://example/property/12" >
> <rdf:Description rdf:about="http://id.example.org/fred">
> <j.0:a813>bob</j.0:a813>
> </rdf:Description>
> </rdf:RDF>
>
> and adding;
>
> "http://example/property/12b813"
> "http://example/d/property/12b813"
>
> gives;
>
> <rdf:RDF
> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
> xmlns:j.0="http://example/d/property/12"
> xmlns:j.1="http://example/property/12" >
> <rdf:Description rdf:about="http://id.example.org/fred">
> <j.0:b813>bob</j.0:b813>
> <j.1:b813>bob</j.1:b813>
> <j.1:a813>bob</j.1:a813>
> </rdf:Description>
> </rdf:RDF>
>
> As an aside is this to reduce the RDF/XML file sizes or a XML
> "normalisation" standard?
No, it's to generate legal XML. The full URI would not make a legal XML
Name token [1]
E.g:
<http://example/property/12b813>bob</http://example/property/12b813>
is not legal XML. And it's even uglier than RDF-XML :)
Ian
[1] http://www.w3.org/TR/REC-xml/#NT-Name
Re: InvalidPropertyURIException thrown
Posted by Dick Murray <da...@googlemail.com>.
On 06/02/12 21:55, Andy Seaborne wrote:
> On 06/02/12 18:05, Dick Murray wrote:
>> On 06/02/12 17:31, Dave Reynolds wrote:
>>> Hi Dick,
>>>
>>> On 06/02/12 16:49, Dick Murray wrote:
>>>
>>>> Why's the checkLocalName() called in some constructors but not
>>>> others..?
>>>
>>> I can't authoritatively answer that, it does seem inconsistent and may
>>> be just historic anomaly.
>>>
>>> Though the fundamental lesson here is to stick to Property URIs which
>>> are legal within the normative RDF syntax (RDF/XML) otherwise
>>> something will bite you eventually :)
>>>
>>>> Also the Util.splitNamespace starts at the end goes back to the last /
>>>> (i.e. before the 99) then winds forwards to the end and returns 31.
>>>> Hence the localName is "".
>>>
>>> Correct.
>>>
>>> The notion of localName here is precisely that of XML QNames, i.e. it
>>> must be a trailing NCName (which can't start with a digit), which
>>> means that your URIs have an empty local name, which is why they can't
>>> be used for properties in RDF/XML syntax, which is why they are best
>>> avoided.
>>>
>>> Dave
>> Hi Dave.
>>
>> Thanks for the reply and after I bit of digging I found the following;
>>
>> Practical restrictions of an NCName
>>
>> The practical restrictions of NCName are that it cannot contain several
>> symbol characters like |:|, |@|, |$|, |%|, |&|, |/|, |+|, |,|, |;|,
>> whitespace characters or different parenthesis. Furthermore an NCName
>> cannot begin with a number, dot or minus character although they can
>> appear later in an NCName.
>>
>> And even a RegEx to check for NCName validity;
>>
>> |[\i-[:]][\c-[:]]*|
>>
>> Specifically for me it's the "cannot begin with a number" as I was
>> aiming to create predicates based on a column index.
>>
>> Though the fundamental lesson here is to stick to Property URIs
>> which are legal within the normative RDF syntax (RDF/XML) otherwise
>> something will bite you eventually :)
>>
>> It's definitely the RDF/XML which isn't happy! If you create a statement
>> with the #99 property from the model it can output in Turtle but throws
>> an exception for RDF/XML.
>>
>> Thanks again.
> It can get more confusing ... :-)
>
> http://example/property/12a813
>
> can be used in RDF/XML as a property with a namespace of
> "http://example/property/123" leaving "a813" as the local part. Jena
> will choose a namespace if it can - it split the final segment of the
> URI to do that.
>
> Andy
Hi Andy and thanks for the added confusion! :-)
So Jena will actively generate namespaces (xmlns:j.x) where it can? It
works backwards through the property until it hits a non valid NCName
char and that's the namespace/localname split. The writer must keep
track of the j.n entries for RDF/XML...
i.e. your example gives;
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:j.0="http://example/property/12" >
<rdf:Description rdf:about="http://id.example.org/fred">
<j.0:a813>bob</j.0:a813>
</rdf:Description>
</rdf:RDF>
and adding;
"http://example/property/12b813"
"http://example/d/property/12b813"
gives;
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:j.0="http://example/d/property/12"
xmlns:j.1="http://example/property/12" >
<rdf:Description rdf:about="http://id.example.org/fred">
<j.0:b813>bob</j.0:b813>
<j.1:b813>bob</j.1:b813>
<j.1:a813>bob</j.1:a813>
</rdf:Description>
</rdf:RDF>
As an aside is this to reduce the RDF/XML file sizes or a XML
"normalisation" standard?
Re: InvalidPropertyURIException thrown
Posted by Andy Seaborne <an...@apache.org>.
On 06/02/12 18:05, Dick Murray wrote:
> On 06/02/12 17:31, Dave Reynolds wrote:
>> Hi Dick,
>>
>> On 06/02/12 16:49, Dick Murray wrote:
>>
>>> Why's the checkLocalName() called in some constructors but not others..?
>>
>> I can't authoritatively answer that, it does seem inconsistent and may
>> be just historic anomaly.
>>
>> Though the fundamental lesson here is to stick to Property URIs which
>> are legal within the normative RDF syntax (RDF/XML) otherwise
>> something will bite you eventually :)
>>
>>> Also the Util.splitNamespace starts at the end goes back to the last /
>>> (i.e. before the 99) then winds forwards to the end and returns 31.
>>> Hence the localName is "".
>>
>> Correct.
>>
>> The notion of localName here is precisely that of XML QNames, i.e. it
>> must be a trailing NCName (which can't start with a digit), which
>> means that your URIs have an empty local name, which is why they can't
>> be used for properties in RDF/XML syntax, which is why they are best
>> avoided.
>>
>> Dave
> Hi Dave.
>
> Thanks for the reply and after I bit of digging I found the following;
>
> Practical restrictions of an NCName
>
> The practical restrictions of NCName are that it cannot contain several
> symbol characters like |:|, |@|, |$|, |%|, |&|, |/|, |+|, |,|, |;|,
> whitespace characters or different parenthesis. Furthermore an NCName
> cannot begin with a number, dot or minus character although they can
> appear later in an NCName.
>
> And even a RegEx to check for NCName validity;
>
> |[\i-[:]][\c-[:]]*|
>
> Specifically for me it's the "cannot begin with a number" as I was
> aiming to create predicates based on a column index.
>
> Though the fundamental lesson here is to stick to Property URIs
> which are legal within the normative RDF syntax (RDF/XML) otherwise
> something will bite you eventually :)
>
> It's definitely the RDF/XML which isn't happy! If you create a statement
> with the #99 property from the model it can output in Turtle but throws
> an exception for RDF/XML.
>
> Thanks again.
It can get more confusing ... :-)
http://example/property/12a813
can be used in RDF/XML as a property with a namespace of
"http://example/property/123" leaving "a813" as the local part. Jena
will choose a namespace if it can - it split the final segment of the
URI to do that.
Andy
Re: InvalidPropertyURIException thrown
Posted by Dick Murray <da...@googlemail.com>.
On 06/02/12 17:31, Dave Reynolds wrote:
> Hi Dick,
>
> On 06/02/12 16:49, Dick Murray wrote:
>
>> Why's the checkLocalName() called in some constructors but not others..?
>
> I can't authoritatively answer that, it does seem inconsistent and may
> be just historic anomaly.
>
> Though the fundamental lesson here is to stick to Property URIs which
> are legal within the normative RDF syntax (RDF/XML) otherwise
> something will bite you eventually :)
>
>> Also the Util.splitNamespace starts at the end goes back to the last /
>> (i.e. before the 99) then winds forwards to the end and returns 31.
>> Hence the localName is "".
>
> Correct.
>
> The notion of localName here is precisely that of XML QNames, i.e. it
> must be a trailing NCName (which can't start with a digit), which
> means that your URIs have an empty local name, which is why they can't
> be used for properties in RDF/XML syntax, which is why they are best
> avoided.
>
> Dave
Hi Dave.
Thanks for the reply and after I bit of digging I found the following;
Practical restrictions of an NCName
The practical restrictions of NCName are that it cannot contain several
symbol characters like |:|, |@|, |$|, |%|, |&|, |/|, |+|, |,|, |;|,
whitespace characters or different parenthesis. Furthermore an NCName
cannot begin with a number, dot or minus character although they can
appear later in an NCName.
And even a RegEx to check for NCName validity;
|[\i-[:]][\c-[:]]*|
Specifically for me it's the "cannot begin with a number" as I was
aiming to create predicates based on a column index.
Though the fundamental lesson here is to stick to Property URIs
which are legal within the normative RDF syntax (RDF/XML) otherwise
something will bite you eventually :)
It's definitely the RDF/XML which isn't happy! If you create a statement
with the #99 property from the model it can output in Turtle but throws
an exception for RDF/XML.
Thanks again.
Re: InvalidPropertyURIException thrown
Posted by Ian Dickinson <ia...@epimorphics.com>.
On 07/02/12 08:06, Dave Reynolds wrote:
> Yes, I was originally going to say something of the sort. However, in
> Dick's case he doesn't himself creates a Node, he passes a string to
> ModelCom.createProperty and it creates the Node and then converts it to
> a Property. So it is the ModelCom implementation that should have done
> the checking before it created the Node in the first place - at least if
> it was to be consistent with ResourceFactory.createProperty.
So, in other words: an anomalous historical anomaly? :)
Ian
Re: InvalidPropertyURIException thrown
Posted by Dave Reynolds <da...@gmail.com>.
On 06/02/12 23:16, Ian Dickinson wrote:
> On 06/02/12 17:31, Dave Reynolds wrote:
>> Hi Dick,
>>
>> On 06/02/12 16:49, Dick Murray wrote:
>>
>>> Why's the checkLocalName() called in some constructors but not others..?
>>
>> I can't authoritatively answer that, it does seem inconsistent and may
>> be just historic anomaly.
> I believe that the original RDF spec states that a property has to be
> decomposable into a namespace and name, because otherwise you can't have
> an XML element representing the predicate in the striped XML syntax. To
> within the limits of judicious post-hoc rationalisation and my failing
> memory, Jena Properties which are constructed from strings therefore
> check this constraint, while properties which are constructed from
> existing nodes are assumed to be compliant.
Yes, I was originally going to say something of the sort. However, in
Dick's case he doesn't himself creates a Node, he passes a string to
ModelCom.createProperty and it creates the Node and then converts it to
a Property. So it is the ModelCom implementation that should have done
the checking before it created the Node in the first place - at least if
it was to be consistent with ResourceFactory.createProperty.
Dave
Re: InvalidPropertyURIException thrown
Posted by Ian Dickinson <ia...@epimorphics.com>.
On 06/02/12 17:31, Dave Reynolds wrote:
> Hi Dick,
>
> On 06/02/12 16:49, Dick Murray wrote:
>
>> Why's the checkLocalName() called in some constructors but not others..?
>
> I can't authoritatively answer that, it does seem inconsistent and may
> be just historic anomaly.
I believe that the original RDF spec states that a property has to be
decomposable into a namespace and name, because otherwise you can't have
an XML element representing the predicate in the striped XML syntax. To
within the limits of judicious post-hoc rationalisation and my failing
memory, Jena Properties which are constructed from strings therefore
check this constraint, while properties which are constructed from
existing nodes are assumed to be compliant.
So yes, it's an historical anomaly :)
Ian
Re: InvalidPropertyURIException thrown
Posted by Dave Reynolds <da...@gmail.com>.
Hi Dick,
On 06/02/12 16:49, Dick Murray wrote:
> Why's the checkLocalName() called in some constructors but not others..?
I can't authoritatively answer that, it does seem inconsistent and may
be just historic anomaly.
Though the fundamental lesson here is to stick to Property URIs which
are legal within the normative RDF syntax (RDF/XML) otherwise something
will bite you eventually :)
> Also the Util.splitNamespace starts at the end goes back to the last /
> (i.e. before the 99) then winds forwards to the end and returns 31.
> Hence the localName is "".
Correct.
The notion of localName here is precisely that of XML QNames, i.e. it
must be a trailing NCName (which can't start with a digit), which means
that your URIs have an empty local name, which is why they can't be used
for properties in RDF/XML syntax, which is why they are best avoided.
Dave
Re: InvalidPropertyURIException thrown
Posted by Dick Murray <da...@googlemail.com>.
On 06/02/12 15:19, Chris Dollin wrote:
> Dick Murray said:
>
> (re http://id.example.org/column/99)
>
>> How come the property URI isn't valid please?
> I believe it can't be represented as a predicate in RDF/XML. (Because it
> has an empty localName.) Jena has RDF/XML history in its bones.
>
> [Aside: it looks in your example that the URIs have a leading space,
> which, if true, makes them illegal in a not-detected-by-jena kind of way.]
>
> Chris
>
Further investigation...
Stack trace for ResourceFactory is;
Scratch2 [Java Application]
com.unit4.scratch.Scratch2 at localhost:54723
Thread [main] (Suspended)
Util.splitNamespace(String) line: 73
Node_URI.getLocalName() line: 64
PropertyImpl(ResourceImpl).getLocalName() line: 133
PropertyImpl.checkLocalName() line: 81
PropertyImpl.<init>(String) line: 72
ResourceFactory$Impl.createProperty(String) line: 241
ResourceFactory.createProperty(String) line: 109
Scratch2.main(String[]) line: 15
/usr/lib/jvm/java-6-openjdk/bin/java (6 Feb 2012 16:29:51)
which calls;
public PropertyImpl( String nameSpace, String localName )
{
super( nameSpace, localName );
checkLocalName();
checkOrdinal();
}
Stack trace for ModelFactory is;
Scratch2 [Java Application]
com.unit4.scratch.Scratch2 at localhost:54723
Thread [main] (Suspended)
PropertyImpl.<init>(Node, EnhGraph) line: 108
PropertyImpl$1.wrap(Node, EnhGraph) line: 61
Personality<T>.newInstance(Class<X>, Node, EnhGraph) line: 84
ModelCom(EnhGraph).getNodeAs(Node, Class<X>) line: 130
IteratorFactory.asResource(Node, Class<X>, ModelCom) line: 69
IteratorFactory.asProperty(Node, ModelCom) line: 63
ModelCom.getProperty(String) line: 702
ModelCom.createProperty(String) line: 1107
Scratch2.main(String[]) line: 22
/usr/lib/jvm/java-6-openjdk/bin/java (6 Feb 2012 16:29:51)
which calls;
public PropertyImpl( Node n, EnhGraph m )
{
super( n, m );
checkOrdinal();
}
So the checkLocalName() isn't called...
Why's the checkLocalName() called in some constructors but not others..?
Also the Util.splitNamespace starts at the end goes back to the last /
(i.e. before the 99) then winds forwards to the end and returns 31.
Hence the localName is "".
Re: InvalidPropertyURIException thrown
Posted by Dick Murray <da...@googlemail.com>.
On 06/02/12 15:19, Chris Dollin wrote:
> Dick Murray said:
>
> (re http://id.example.org/column/99)
>
>> How come the property URI isn't valid please?
> I believe it can't be represented as a predicate in RDF/XML. (Because it
> has an empty localName.) Jena has RDF/XML history in its bones.
>
> [Aside: it looks in your example that the URIs have a leading space,
> which, if true, makes them illegal in a not-detected-by-jena kind of way.]
>
> Chris
>
I'm getting different results based on the createProperty(uri) called...
package com.unit4.scratch;
import com.hp.hpl.jena.rdf.model.ModelFactory;
import com.hp.hpl.jena.rdf.model.ResourceFactory;
import com.hp.hpl.jena.shared.InvalidPropertyURIException;
The following code;
public class Scratch2 {
/**
* @param args
*/
public static void main(String[] args) {
try {
ResourceFactory.createProperty("http://id.example.org/column/99");
} catch (InvalidPropertyURIException e) {
System.out.println("fred " + e);
}
System.out.println(ModelFactory.createDefaultModel().createProperty("http://id.example.org/column/99"));
}
}
gives.
fred com.hp.hpl.jena.shared.InvalidPropertyURIException:
http://id.example.org/column/99
http://id.example.org/column/99
Which implies the ResourceFactory has an issue but the ModelFactory doesn't.
Re: InvalidPropertyURIException thrown
Posted by Chris Dollin <ch...@epimorphics.com>.
Dick Murray said:
(re http://id.example.org/column/99)
> How come the property URI isn't valid please?
I believe it can't be represented as a predicate in RDF/XML. (Because it
has an empty localName.) Jena has RDF/XML history in its bones.
[Aside: it looks in your example that the URIs have a leading space,
which, if true, makes them illegal in a not-detected-by-jena kind of way.]
Chris
--
"You're down as expendable. You don't get a weapon." /Dark Lord of Derkholm/
Epimorphics Ltd, http://www.epimorphics.com
Registered address: Court Lodge, 105 High Street, Portishead, Bristol BS20 6PT
Epimorphics Ltd. is a limited company registered in England (number 7016688)