W3C home > Mailing lists > Public > public-vocabs@w3.org > December 2013

Re: Why are classes and URIs case sensitivity?

From: Jarno van Driel <jarno@quantumspork.nl>
Date: Wed, 4 Dec 2013 19:05:29 +0100
Message-ID: <CAFQgrbY3sRWoVLx9TNvt7PaA0-MB+vDxw_9TFkX13cnG7n8x0g@mail.gmail.com>
To: Martin Hepp <martin.hepp@unibw.de>
Cc: Dan Scott <dan@coffeecode.net>, kcoyle@kcoyle.net, SchemaDot Org <public-vocabs@w3.org>
The origin of my question lies with parsing the same piece of code with
both Yandex's and Google's SDTT. Yandex's actually warns for capitalization
errors while Google's converts everything to lowercase and that's how I got
confused.

Now I'm happy that Yandex's SDTT warns for capitalization issues but I'm
not aware of any other markup check tool that does. And especially since
Google's SDTT is probable the most use tool in the world for markup
feedback, I wouldn't be surprised that this type of error will slowly
become more likely to happen as semantics become more popular.

Now should we, in an attempt to try to help to prevent this type of errors:
a. Have a W3 SDTT which is independent of search engines and checks markup
according to specs
b. Modify schema.org so to prevent this type of ambiguity
c. Do something completely different


On Wed, Dec 4, 2013 at 6:54 PM, Martin Hepp <martin.hepp@unibw.de> wrote:

> I partly agree, but I think it would be better to specify more precisely
> that property identifiers start with a lower caps character and type
> identifiers start with uppercase.
>
> Then it would be easy to write tools that warn you if a property or type
> ID is wrong.
>
> By the way, I suspect that the actual tool chain in search engines that
> consumes respective markup is, to a certain degree, tolerant to
> capitalization issues.
>
> Martin
>
>
>
> On Dec 4, 2013, at 6:48 PM, Jarno van Driel wrote:
>
> > Examples like Dan Scott gave (review/Review is another) is exactly what
> started up my discussion with Aaron Bradley. Even though it's not difficult
> to implement it is prone to typo's, which has happened to myself as well
> and I consider myself pretty knowledgeable and aware. It's something that
> happens to all of us at one time or another and I wonder if it isn't better
> that classes and properties don't have the same 'value/name' no matter what
> the casing is. Because making a typo with something like 'review/Review'
> can definitely can ruin your (overall) markup.
> >
> > Now if classes and properties never would share the same 'value/name'
> that would resolve typo's messing with the overall schema and
> canonicalisation/redirects and such could then resolve the rest.
> >
> >
> > On Wed, Dec 4, 2013 at 6:26 PM, Dan Scott <dan@coffeecode.net> wrote:
> > On Wed, Dec 4, 2013 at 11:57 AM, Karen Coyle <kcoyle@kcoyle.net> wrote:
> > > A question that I have had about this is whether there is any "policy"
> (to
> > > the extent that schema.org has such things) about having a class and a
> > > property with the same term, the only difference being the case of the
> first
> > > letter. It strikes me that such a situation could be error prone....
> but I
> > > don't know if examples already exist in schema.
> >
> > It's a relatively common pattern; as a sample of what already exists:
> >
> > * action / Action
> > * AggregateRating / aggregateRating
> > * Audience / audience
> >
> > ... just to hit the "A/a" section.
> >
> >
>
> --------------------------------------------------------
> martin hepp
> e-business & web science research group
> universitaet der bundeswehr muenchen
>
> e-mail:  hepp@ebusiness-unibw.org
> phone:   +49-(0)89-6004-4217
> fax:     +49-(0)89-6004-4620
> www:     http://www.unibw.de/ebusiness/ (group)
>          http://www.heppnetz.de/ (personal)
> skype:   mfhepp
> twitter: mfhepp
>
> Check out GoodRelations for E-Commerce on the Web of Linked Data!
> =================================================================
> * Project Main Page: http://purl.org/goodrelations/
>
>
Received on Wednesday, 4 December 2013 18:05:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:36 UTC