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

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

From: Gavin Carothers <gavin@topquadrant.com>
Date: Thu, 18 Aug 2011 20:50:20 -0700
Message-ID: <CAPqY83yn2BF-kEhZ=d6-Kxg4-vCD2P5wYAoRxifyvVw3_73OEA@mail.gmail.com>
To: RDF-WG WG <public-rdf-wg@w3.org>
Some background on prefixed names:

Wikipedia, QName:
Since URI references can be long and may contain prohibited characters
for element/attribute naming, QNames are used to create a mapping
between the URI and a namespace prefix. The mapping enables the
abbreviation of URIs, therefore it achieves a more convenient way to
write XML documents.

>From SPARQL 1.0:

The PREFIX keyword associates a prefix label with an IRI. A prefixed
name is a prefix label and a local part, separated by a colon ":". A
prefixed name is mapped to an IRI by concatenating the IRI associated
with the prefix and the local part. The prefix label or the local part
may be empty. Note that SPARQL local names allow leading digits while
XML local names do not.

same in SPARQL 1.1

>From RDFa Core:

The key component of RDF is the URI, but these are usually long and
unwieldy. RDFa therefore supports a mechanism by which URIs can be
abbreviated, called 'compact URI expressions' or simply, CURIEs.

>From JSON-LD:
A CURIE is a compact way of describing an IRI. The term actually comes
from Compact URI. Generally, a CURIE is composed of a prefix and a
suffix separated by a ':'.

...

A specific example of the problem this causes comes from attempting to
define the name collection for books. In a QName, the part after the
colon must be a valid element name, making an example such as the
following invalid: isbn:0321154991

>From Turtle Team Submission:

URIs may also be abbreviated by using Turtle's @prefix directive that
allows declaring a short prefix name for a long prefix of repeated
URIs. This is useful for many RDF vocabularies that are all defined in
nearby namespace URIs, possibly using XML's namespace mechanism that
works in a similar fashion.

>From Turtle FPWD:

IRIs may also be abbreviated by using Turtle's @prefix directive that
allows declaring a short prefix name for a long prefix of repeated
IRIs. This is useful for many RDF vocabularies that are all defined
with a common namespace like IRI.

While @prefix works somewhat like XML namespaces the restrictions from
XML QNames do NOT apply. leg:3032571 is a perfectly fine prefixed
name.

-----

It is a generally held belief that Prefixed Names are not QNames. They
allow for a wider range of characters after the : and that the reason
they exist is to allow a document author to shorten writing down a
long IRI. We must therefor forgive Pat Hays making a horrible mistake.
The same mistake I've made a number of times now.

rdf:LangString/en

I don't think there is any confusion about what Pat meant by typing
that. However in Turtle Team Submission that is invalid, and in SPARQL
is uh, might mean to follow the en property path? In RDFa and JSON-LD
it expresses what we all know Pat meant.

<http://www.w3.org/1999/02/22-rdf-syntax-ns#LangString/en>

The design goal for prefixed names clearly has been to make it more
convenient to write down long URIs. For example lets say you wanted to
write down some triples about the W3C website, say the standards
section.

You might start by writing down:

@prefix standards: <http://www.w3.org/standards/>

You'd be a bit annoyed when you got to each section, xml, webarch,
semanticweb, etc, and discovered that you needed to create a new
prefix for EVERY path segment. With everyone trying to use URIs with
rest principles to build websites and APIs it seems odd that we should
be standardizing Turtle in such a way that it makes it hard to use
well designed URIs.

The obvious reason not to change Turtle's design here is that Turtle
is a well settled format. The same goes for SPARQL as well, (also not
our WG). So is it worth changing Turtle and possibly being less in
agreement with SPARQL? I'm not sure, that's why we have a public
working group.

Cheers,
Gavin
Received on Friday, 19 August 2011 03:50:55 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:44 GMT