W3C home > Mailing lists > Public > public-vocabs@w3.org > April 2014

Re: has, is, of

From: Martin Hepp <martin.hepp@unibw.de>
Date: Sun, 20 Apr 2014 21:27:15 +0200
Cc: Karen Coyle <kcoyle@kcoyle.net>, W3C Web Schemas Task Force <public-vocabs@w3.org>
Message-Id: <4FF311F7-CBF5-4246-8D73-D5BF29DB01FB@unibw.de>
To: Dan Scott <dan@coffeecode.net>
My two cents:

When we integrated GoodRelations, we changed all (most) property names from hasXYZ to xyz in order to match the schema.org naming pattern of trying to omit has-, is- and other prefixed and suffixes as much as possible (hasPOS is the exception from the rule).. In the original gr namespace, so far the old names are the official ones.

Back then, I liked this direction, because it saves a lot of typing and one CamelCase (and thus potential source of error) for each usage of the property, so I think the ergonomics of the schema.org approach is superior. In GoodRelations, I originally tried to use very precise names for properties and classes (which lead to unhandy elements like gr:LocationOfSalesOrService provisioning - which is conceptually a maybe more precise than the new gr:Location or schema:Place - but it really hurts the coder).

After having created ca. 300 examples in RDFa and Microdata in the old GoodRelations and the new schema.org namespace, I can tell that the risk of ambiguity is by far smaller than the gain in coding efficiency and number of errors, assumed that you can easily look up the definition of the element.

Let's keep in mind that schema.org is a relatively small vocabulary that will be used by millions of coders on billions of documents, so we should always keep both the coder's and the conceptual modeler's position in mind.

Martin
--------------------------------------------------------
martin hepp
e-business & web science research group
universitaet der bundeswehr muenchen

e-mail:  martin.hepp@unibw.de
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





On 20 Apr 2014, at 21:11, Dan Scott <dan@coffeecode.net> wrote:

> On Sun, Apr 20, 2014 at 11:27:36AM -0700, Karen Coyle wrote:
>> I hope this isn't another can of worms, but I would like a reality check on the use of "has, is, of" in property names. DanBri made a terse statement in a recent email [1]
> 
> Dan previously stated in reply to another property naming policy
> question of yours, around case-sensitivity being the only distinguisher
> between a property and a name (for example, "review" and "Review"):
> 
> """
> 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.
> """
> http://lists.w3.org/Archives/Public/public-vocabs/2013Dec/0037.html
> 
> We took this statement of direction into consideration when we proposed
> "hasPart" as part of the Periodical proposal. Formal guidance for future
> proposals would be welcome, of course, should the schema.org team come
> to such a decision!
> 
> In an effort to reduce the number of worms in the can for the other
> property name forms, the reality check for the current usage of "fooOf"
> properties in schema.org is as follows:
> 
> branchOf
> causeOf
> comprisedOf
> estimatesRiskOf
> increasesRiskOf
> isPartOf
> isVariantOf
> memberOf
> predecessorOf
> successorOf
> 
> And the currently used "isFoo" properties are:
> 
> isAvailableGenerically
> isBasedOnUrl
> isConsumableFor
> isFamilyFriendly
> isGift
> isPartOf
> isProprietary
> isRelatedTo
> isSimilarTo
> isVariantOf
> 
> (In passing and off topic and mostly for danbri, I note that "issuedBy"
> appears twice in schema.org/docs/schema_org_rdfa.html with different
> domainIncludes directives and descriptions, which is weird; some have
> "<span>Domain" and others have "<span>domain").
> 
Received on Sunday, 20 April 2014 19:28:04 UTC

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