W3C home > Mailing lists > Public > public-rdf-wg@w3.org > August 2011

Re: [Turtle] About slashes in prefixed refrences, not about escaping

From: Richard Cyganiak <richard@cyganiak.de>
Date: Sun, 21 Aug 2011 15:52:38 +0100
Cc: RDF-WG WG <public-rdf-wg@w3.org>
Message-Id: <D95354EB-C136-4A10-9014-951D5AB51D2E@cyganiak.de>
To: Gavin Carothers <gavin@topquadrant.com>
On 20 Aug 2011, at 05:18, Gavin Carothers wrote:
> Almost all the documentation around prefix
> names talks about simple concatenation including SPARQL and Turtle (by
> reference to SPARQL), but at the moment it's only simply concatenation
> so long as you avoid a list of characters that is only specified by
> their absence from a LONG list of unicode character escapes inside the
> EBNF grammar.

The list can be approximately paraphrased as “letters, numbers, underscores and dots.”

> I think then the argument is should @prefixes be designed to used for
> things other then property names?
> The examples also suggest that @base, @prefix and full <uris> can be
> used interchangeably.

The spec should absolutely allow prefixed names in any place where an IRI can appear.

Nevertheless, I consider it good practice to use them *only* for property and class names, because anywhere else they're likely to work inconsistently and cause more confusion than benefit.

I think examples or other documentation that are used for educational purposes should avoid using prefixed names for anything but class and property names.

>> It doesn't make it harder. It just removes one possibility for making it shorter. A possibility that HTML never had, and it seems to be doing just fine.
> But at the moment it doesn't remove the possibility, it says you can
> write some URIs shorter, and you need to figure out which you can't.

And this is impossible to change, because certain characters that can occur in URIs are already *taken* in Turtle and SPARQL, like the comma, semicolon, slash, plus, and question mark. You *cannot* extend prefixed names to cover *all* URIs. So you'll always need to figure out which you can or cannot use.

The current situation is that you basically can only abbreviated a reasonably well-defined subset of IRIs: those vocabulary terms that have been specifically designed for that purpose.

What you are attempting is to broaden this into a random subset of IRIs that cannot easily be characterised.

> If the specification shouldn't change it what it allows, then it
> should change in making it much clearer what @prefixes are good for

I agree to some extent. A specification isn't a best-practice document; but there certainly is an opportunity to avoid user confusion by inserting some appropriate wording.

How about:

“Note: Most punctuation characters are disallowed in the local part of prefixed names. Therefore, @prefix and prefixed names are most useful for abbreviating class and property IRIs, which by design usually avoid such punctuation. Other IRIs, such as web links, can often only be written using the angle bracket syntax, either as absolute IRIs, or relative to the base IRI.”

I'll send something along those lines to the SPARQL comments list.

Received on Sunday, 21 August 2011 14:53:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:08 UTC