W3C home > Mailing lists > Public > www-rdf-interest@w3.org > August 2003

Re: RDF validator error

From: Eric Prud'hommeaux <eric@w3.org>
Date: Wed, 27 Aug 2003 11:54:51 -0400
To: Jeremy Carroll <jjc@hplb.hpl.hp.com>
Cc: Charlie Abela <abcharl@keyworld.net>, www-rdf-interest@w3.org
Message-ID: <20030827155451.GA8761@w3.org>

On Wed, Aug 27, 2003 at 03:08:51PM +0100, Jeremy Carroll wrote:
> 
> 
> (Would value comment from other WG members)
> 
> 
> Charlie Abela wrote:
> 
> 
> >I am trying to parse some DAML with the validator. The parsing of this 
> >file used to give no complaint except that lately I am being faced with 
> >this error: Error: {W130} Base URI is "", relative URIs left as relative 
> >and I can?t figure out why?
> 
> 
> Also this example from Art Barstow:
> 
> <rdf:Description rdf:ID="Profile">
> <dc:title>World Wide Web Consortium</dc:title>
> </rdf:Description>
> 
> generating the same error.
> 
> At some point I upgraded ARP to correctly identify the use of relative URIs 
> in documents given with relative URIs as a problem.
> The RDF graph uses absolute URI refs, and if no absolute URI can be 
> established then there is an issue. Whether this is a warning or an error 
> depends on the use case, and ARP supports either. The validator I believe 
> runs in strict mode, and so most problems are treated as errors.
> 
> Recently the validator has had the ARP engine upgraded. At which point this 
> behaviour was introduced.
> 
> I agree that it is a bug in the validator, since while no base URI can be 
> determined for text pasted into a web form, it is unhelpful to complain 
> about this. It is however not a bug in a compliant parser.
> 
> I suggest one of the following fixes in the validator code:
> a) specify an arbitrary base URI instead of ""

I just did this on a test server. I used http://example.org/# for my
experiment. I could also use the validator page. The validator form is
an HTTP POST and rfc2616 has this to say about POST:

[[ http://www.w3.org/Protocols/rfc2616/rfc2616.txt
The POST method is used to request that the origin server accept the
entity enclosed in the request as a new subordinate of the resource
identified by the Request-URI in the Request-Line.
...
The posted entity is subordinate to that URI in the same way that a
file is subordinate to a directory containing it, a news article is
subordinate to a newsgroup to which it is posted, or a record is
subordinate to a database.
]]

It also talks about return codes for created objects, but we're not
creating anything that is resolvable later so that's not germain...

The base URI could also have a unix time in it to prevent
inappropriate graph merging of output from multiple calls to the
validator. This would allow us to scope the names used in a particular
POST to that POST. Otherwise, #n1 in one POST would identify the same
node as #n1 in antother POST (as opposed to having all POST through
all time be in the same lexical space). Plus bNodes would be nicely
distinct...

> or
> b) tell ARP to ignore this condition
>   setErrorMode(
>      ARPErrorNumbers.WARN_RESOLVING_URI_AGAINST_EMPTY_BASE,
>      ARPErrorNumbers.EM_IGNORE );
> 
> Personally I think option (b) is better.

Any particular reason? I have no great preference for A, but it does
seem like the triples generated by allowing unanchored relative URIs
might cause someone trouble down the line. For instance, if the output
were in n3 or some other language using URIs for nodes, a consumer of
the data might whine where jena had been instructed not to whine.

> A workaround until the validator is updated is to have the file to be 
> tested as web accessible and use the validate URL option.

It's a simple matter of copying a file at this point so unless the
workaround is prefferable to A or B, you shouldn't need to use it.
-- 
-eric

office: +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell:   +1.857.222.5741

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.
Received on Wednesday, 27 August 2003 11:54:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:52:01 GMT