Re: [Proposal] schema:NotApplicable

I think the essence of many of this any related problems is that currently, schema.org has only the level of the formal specification of what can be expressed, but little meta-data that guides implementers.

For instance, we often use "Thing" as the formal domain or range for a property, but the most frequently types are much more specific. 

When we want to advance the state of the art of schema.org and Web vocabularies, we should consider adding meta-data that complements the formal specification instead of simply deriving what humans see from the logical definition of the elements.

For instance, we could 

- vary the textual definition of a property depending on the schema.org type for which it is shown and
- classify properties as "mandatory", "recommended", "frequently used" and "possible but rare" (e.g. fax numbers are recommended for companies and possible yet rare for volcanoes).

Note that I am not suggesting to touch the formal integrity of the spec, but to make the human-readable documentation more adaptive to the context of usage of an element.

Best wishes / Mit freundlichen Grüßen

Martin Hepp

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

Check out GoodRelations for E-Commerce on the Web of Linked Data!
=================================================================
* Project Main Page: http://purl.org/goodrelations/




On 21 Sep 2014, at 22:40, ☮ elf Pavlik ☮ <perpetual-tripper@wwelves.org> wrote:

> On 09/21/2014 10:15 PM, Markus Lanthaler wrote:
>> On 20 Sep 2014 at 23:10, ☮ elf Pavlik ☮ wrote:
>>> On 09/20/2014 10:25 PM, Karen Coyle wrote:
>>>> "spouse": "notApplicable"
>>>> 
>>>> is incredibly vague. The person could be single, widowed, be secretly
>>>> married, be in a culture where marriage does not confer "spouse-ness" or
>>>> "spouse-ness" could simply be irrelevant to the context in question.
>>> I agree that it doesn't clarify a lot but at least signals N/A, which
>>> gives at least *some clue*.
>>> 
>>> BTW vcard:None, vcard:Other, vcard:Unknown exist as sub classes of
>>> vcard:Gender schema:gender http://schema.org/gender could at least
>>> recommend some external enumeration! 
>>> 
>>> Thank you for all the feedback Karen, if no one else finds types like
>>> schema:None and schema:NotApplicable useful, of course I will not argue
>>> about it any more :)
>> 
>> I'm quite sure that sooner or later we will need something like schema:None / schema:Null / schema:Nil to be able to explicitly state that there's no data for something but I agree with Karen that schema:NotApplicable is extremely vague and doesn't convey more information than simply omitting that field.
> Thanks Markus!
> 
> I proposed schema:NotApplicable since I just write by hand N/A every
> other day in various web forms that bug me for 'required' information
> which simply doesn't apply to me (nationality, address etc.)
> schema:None, schema:Null, schema:Nil or even schema:LOL all work fine
> for me as long as we could agree upon something and recommend it for
> such cases.
> 
> I also agree that I didn't make best choice coming up with Pope.spouse
> example. I would propose to freeze this thread until me or someone else
> writes down some more realistic use cases!
> 
> 
>

Received on Wednesday, 24 September 2014 15:57:29 UTC