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

On Fri, Aug 19, 2011 at 6:53 AM, Richard Cyganiak <richard@cyganiak.de> wrote:
> On 19 Aug 2011, at 04:50, Gavin Carothers wrote:
>> 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.
>
> There's nothing wrong with writing out full absolute URIs. It's what everyone has been doing for 20 years when creating hyperlinks in HTML.
>
> Your argument is that this is too long:
>
>    <http://www.w3.org/standards/semanticweb/data>
>
> And it would be so much nicer if you could write:
>
>    w3c_standards:semanticweb/data
>
> But tell me, when exactly would you choose one option over the other? Would you never write the former? Or only if there's more than one use for the w3c: prefix in the document? More than two? Is it really that much harder to just write out the full URI?
>
> I feel that you're proposing to introduce a new syntactic feature (CURIEs) that overlaps very much with an existing syntax (bracketed URIs), to the point where it becomes unclear when to use which. It adds syntactic variation with very little benefit.
>
> That's exactly the path of featuritis that doomed RDF/XML. Remember how in RDF/XML, ID="foo" is syntactic sugar for about="#foo". The result is tons of newbie questions and bug reports where they say, “I want it to output ID="foo" but instead it writes about="#foo", I don't understand what I'm doing wrong, my code looks like it should work fine, how can I make it write the right thing?”

I rather feels the reverse. 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.

>
> I expect the same kind of stuff to happen for Turtle if you get your way with this feature.

I think then the argument is should @prefixes be designed to used for
things other then property names?

SPARQL 1.0 which coined the name provides an example of doing so in
the section defining prefix names:

PREFIX book: <http://example.org/book/>
book:book1

The examples also suggest that @base, @prefix and full <uris> can be
used interchangeably.

"The following fragments are some of the different ways to write the same IRI:"

It seems odd then to being saying that @prefix names and <uris> should
not be used interchangeably. People (ourselves included) have believed
that.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13090

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

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

If the specification shouldn't change it what it allows, then it
should change in making it much clearer what @prefixes are good for
and should NOT continue to claim that you can use <uris>, and prefixed
names interchangeably.

>
> Best,
> Richard

Received on Saturday, 20 August 2011 04:18:47 UTC