Re: Why are classes and URIs case sensitivity?

On 4 December 2013 16:57, 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.

Is "regret" a policy? I think it's fair to say we regret the current
situation. But there are a substantive number of property/type pairs.
Most of them are at least related pairs, but in a few cases they come
from different domains (e.g. code/Code). The schema.org team haven't
yet decided on what to do, but a possibility is to introduce new
hasXyz property names, and mark the original form as deprecated in
favour of the has-based version. Deploying this would affect all
existing consumption code, so its not a decision to be taken casually.

The basic ruling that these names are case sensitive we inherit from
surrounding standards (RDFa, URIs, JSON-LD etc., probably Microdata
too, though I'd have to check that). The decision to use almost
identical strings to mean different things was a schema.org
mis-judgement.

See http://dydra.com/danbri/schema-org/sparql#terms-differing-only-by-case
for a SPARQL query listing the cases where type and property differ
only by case/capitalization. Details below.

The exceptional cases here are

1. for 'URL' and 'url', which are special. URL is very rarely used as
an explicit type in public data, and 'url' would look awful as
'hasUrl'. Let's leave those.
2. Action / action are a bit different, since 'action' is medical,
i.e. http://schema.org/action "The movement the muscle generates.". I
propose we rename that concept muscleAction instead. I can't find much
evidence of the medical concept being used, but will investigate
whether we can remove it.
3. Code/code.

The main argument against the status quo, already made here, is the
risk of easy error. It should be possible to speak unambiguously about
schema.org terms e.g. by telephone or in face to face conversation,
without stopping to say "Review-with-a-capital-R".

In general, the pattern of having initial lowercase letters reserved
for properties, and types named with Initial Caps, is one of the best
kept secrets of RDF syntax. If you know this and use schemas that
follow this (most do), then reading Turtle/SPARQL, JSON-LD, RDF/XML,
N-Triples and Microdata becomes easier. When you see a Capital, the
data is talking about a thing of that type, when you see a lowercased
name, the data is talking about a property of something.

cheers,

Dan


http://schema.org/URL http://schema.org/url
http://schema.org/Duration http://schema.org/duration
http://schema.org/AggregateRating http://schema.org/aggregateRating
http://schema.org/Brand http://schema.org/brand
http://schema.org/Comment http://schema.org/comment
http://schema.org/Action http://schema.org/action
http://schema.org/Audience http://schema.org/audience
http://schema.org/ContactPoint http://schema.org/contactPoint
http://schema.org/DoseSchedule http://schema.org/doseSchedule
http://schema.org/Drug http://schema.org/drug
http://schema.org/DrugClass http://schema.org/drugClass
http://schema.org/Event http://schema.org/event
http://schema.org/InfectiousAgentClass http://schema.org/infectiousAgentClass
http://schema.org/Map http://schema.org/map
http://schema.org/MedicalSpecialty http://schema.org/medicalSpecialty
http://schema.org/MedicineSystem http://schema.org/medicineSystem
http://schema.org/Nerve http://schema.org/nerve
http://schema.org/Review http://schema.org/review
http://schema.org/Specialty http://schema.org/specialty
http://schema.org/Text http://schema.org/text
http://schema.org/BusinessFunction http://schema.org/businessFunction
http://schema.org/DayOfWeek http://schema.org/dayOfWeek
http://schema.org/Code http://schema.org/code
http://schema.org/OpeningHoursSpecification
http://schema.org/openingHoursSpecification
http://schema.org/PriceSpecification http://schema.org/priceSpecification
http://schema.org/WarrantyScope http://schema.org/warrantyScope
http://schema.org/Dataset http://schema.org/dataset
http://schema.org/DeliveryMethod http://schema.org/deliveryMethod
http://schema.org/Diet http://schema.org/diet
http://schema.org/Distance http://schema.org/distance
http://schema.org/EntertainmentBusiness http://schema.org/entertainmentBusiness
http://schema.org/ExercisePlan http://schema.org/exercisePlan
http://schema.org/FoodEstablishment http://schema.org/foodEstablishment
http://schema.org/FoodEvent http://schema.org/foodEvent
http://schema.org/Language http://schema.org/language
http://schema.org/RealEstateAgent http://schema.org/realEstateAgent
http://schema.org/Recipe http://schema.org/recipe
http://schema.org/SportsActivityLocation
http://schema.org/sportsActivityLocation
http://schema.org/SportsEvent http://schema.org/sportsEvent
http://schema.org/SportsTeam http://schema.org/sportsTeam
http://schema.org/WarrantyPromise http://schema.org/warrantyPromise

SPARQL via Python script:

#!/usr/bin/env python

import sparql # sudo pip install sparql-client

q = """SELECT ?class ?property WHERE {
GRAPH ?g
 {
  ?property a rdf:Property .
  ?class a rdfs:Class .
}
FILTER ( LCASE(STR(?property)) = LCASE(STR(?class)) ) .
}
LIMIT 5000"""
result = sparql.query('http://dydra.com/danbri/schema-org/sparql', q)
for row in result:
     # print 'row:', row
     values = sparql.unpack_row(row)
     print values[0], "\t\t\t", values[1]

Received on Wednesday, 4 December 2013 18:05:59 UTC