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

On Sun, Aug 21, 2011 at 7:52 AM, Richard Cyganiak <richard@cyganiak.de> wrote:
> 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.

The confusion is unlikely to go away as JSON-LD, RDFa and the RDF API
are likely to keep using prefixes which do allow punctuation.

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

There is likely to be at least some cleanup in that case.
>
>>> 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.

Don't buy the cannot argument. Should not, won't, might be a bit
complicated, not 100% compatible with existing implementations, etc.
Also I don't think that the end user should have to "figure out" what
they can and can't use by reading between the lines of an EBNF
grammar.

>
> 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.

Agree that is the current situation in Turtle and SPARQL, that is not
true in JSON-LD, RDFa, or the RDF API.

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

Sure it can, all of them ;)

"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. "

so what if there are more colons in it? Simple concatenation is still
simple. There may of course be some characters that for whatever
reason need to be escaped to type just as in XQuery, XPath, XML, HTML,
but that's okay.

>
>> 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 agree that this is the least that needs to be done, and may be
enough for the time being if we want to take the most conservative
route. Which I think we as a WG do.

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

Thanks!

Cheers,
Gavin

Received on Tuesday, 23 August 2011 21:13:05 UTC