Re: strange identifiers in schema.org

I would like to add to this that in GoodRelations, we took the opposite route, going from the initially used, conceptually clean and less ambiguous names like

    gr:LocationOfSalesOrServiceProvisioning

to shorter names, like

    gr:Location

because we found that in real mark-up, long names are a real burden - typing effort, risk of spelling mistakes, etc.

In the end, there is a trade-off between catchy names that are easy to use (but quickly turn into polysemes) vs. more precise ones, which are burdensome and error-prone at markup time.

I personally think that for the types (classes) of schema.org, we will be able to find good names that strike such a balance.

At the property level, we will likely have to give up a global namespace and bind all property names to the type they are used with.


Martin




On Nov 7, 2013, at 7:40 PM, Bernard Vatant wrote:

> Hello Peter
> 
> I think you are rightly pointing to the implicit initial (and naive) assumption of schema.org, which is that the whole world can be represented under a single flat namespace at arbitrary level of granularity, with natural language words as identifiers. Obviously, this does not scale and hits quickly the wall of polysemy, as the Abdomen example perfectly illustrates, and we are bound to have more of the same with the schema growth (which is, remind you, potentially unbound, as evasive answers to questions on limit of this growth have shown some months).
> Keeping a single flat namespace needs CamelCase constructions, such as http://schema.org/HomeAndConstructionBusiness, and the Abdomen example could be disambiguated the same way e.g., http://schema.org/MedicalPhysicalExamAbdomen, leaving room to further http://schema.org/PartOfBodyAbdomen etc.
> This is an alternative to different namespaces such as your proposition, but this solution seems proposed for extensions only. 
> 
> Whatever the choice, I agree that it should 
> 1. Avoid restricted definitions of potentially polysemic terms
> 2. Be based on a clear policy for namespace hierarchy of CamelCasing (so to speak) 
> 
> That said, and knowing enough of you to figure how you feel when looking into them, other problems you point at (lack of documentation, semantic glitches etc) will always be present in this scruffy-work-in-progress called "Web semantics" (read : fuzzy, plural, inconsistent etc). I'm sure you will ever ever fight it with all your will and strength given where you come from, but I'm afraid this battle has been lost for quite a while now. As Pat Hayes told me a while ago "My ivory tower has been seriously shaken those days, waters of real world are slowly rising around us." Time to learn swimming in troubled waters ... 
> 
> Best regards
> 
> 
> 
> 2013/11/7 Peter F. Patel-Schneider <pfpschneider@gmail.com>
> Hmm.
> 
> Aaron might be able to answer why http://schema.org/Abdomen was chosen as the identifier for a medical physical examination of the abdomen.
> 
> However, my question is really about how the identifiers in schema.org are supposed to be formed.  Right now, it appears that there is little or no guidance beyond camelcase with types and enumerated values starting with a capital letter and properties not.
> 
> Different parts of schema.org appear to be using different conventions (e.g., under Actions vs under MedicalEntity).   Some parts of schema.org appear to be using several different conventions (e.g., CollectionPage vs ImageGallery under CreativeWork).
> 
> I feel that the lack of guidance will only lead to confusion on the part of content generators, particularly when identifiers that do not match the intended meaning of their item are chosen (e.g., Abdomen).
> 
> Peter F. Patel-Schneider
> 
> 
> 
> 
> On 11/07/2013 07:22 AM, Guha wrote:
> Peter,
> 
>  Thank you for the feedback. Adding Aaron Brown, who worked on the medical vocabulary to the thread.
> 
> Guha
> 
> 
> On Thu, Nov 7, 2013 at 4:24 AM, Peter F. Patel-Schneider <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote:
> 
>     Well, my immediate goal here is to understand a part of schema.org
>     <http://schema.org>.   Without such understanding any suggestions I make
> 
>     aren't going to be particularly worthwhile.
> 
>     Consider, for example, a suggestion that the way to proceed here is to
>     use identifiers like http://schema.org/Medical/PhysicalExam/Abdominal.      Is this a reasonable identifier to use in schema.org <http://schema.org>
> 
>     instead of Abdomen?  I don't know.   Is this even an acceptable
>     identifier to use in schema.org <http://schema.org> at all?  I don't
> 
>     know that either.  (Well, it does appear that this might be an
>     acceptable identifier because it sort of fits the extension mechanism
>     described in http://schema.org/docs/extension.html but it doesn't fit
>     precisely.)
> 
>     So I asked a question, and backed it up with an example that I think
>     shows that an answer is needed.
> 
>     Peter F. Patel-Schneider
> 
> 
>     On 11/06/2013 08:51 PM, Dan Scott wrote:
> 
> 
> 
>         On Nov 6, 2013 10:36 PM, "Peter F. Patel-Schneider"
>         <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>
>         <mailto:pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>>> wrote:
>         >
>         > Are there any guidelines for the construction of identifiers in
>         schema.org <http://schema.org> <http://schema.org>?
> 
> 
>         >
>         > The reason that I ask is that there are some rather strange
>         identifers, or at least some rather strange uses of identifiers.
>         >
>         >
>         > Consider, for example, the identifier Abdomen
>         (http://schema.org/Abdomen).  One might think that this refers to a
>         part of the bodies of some animals.   However, Abdomen is instead an
>         instance of PhysicalExam, along with Appearance, CardiovascularExam,
>         Eye, Neuro, and VitalSign.
>         >
>         > It seems to me that this is very bad design, particularly if
>         schema.org <http://schema.org> <http://schema.org> identifiers are
> 
>         supposed to be used by people who might not have a background in the
>         representation of knowledge.
> 
>         If your goal is to help improve schema.org <http://schema.org>
>         <http://schema.org>, constructive criticism would be much better
>         than just a stream of criticism. As one of my colleagues was fond of
>         saying, "You found the problem, so you get to solve the problem".
> 
> 
>         So please lend your intellect towards helping solve the problem.
>         Given a vocabulary with high rates of adoption, and the realization
>         that some less than optimal design decisions have been made, what
>         action can you take or recommend to address these problems?
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> Bernard Vatant
> Vocabularies & Data Engineering
> Tel :  + 33 (0)9 71 48 84 59
> Skype : bernard.vatant
> http://google.com/+BernardVatant
> --------------------------------------------------------
> Mondeca                             
> 3 cité Nollez 75018 Paris, France
> www.mondeca.com
> Follow us on Twitter : @mondecanews
> ----------------------------------------------------------

--------------------------------------------------------
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 Thursday, 7 November 2013 21:00:44 UTC