Re: Property Names, was Re: Automotive, EXIF, Property-Values

On 12/18/2014 12:15, Young,Jeff (OR) wrote:
> I'll give it a shot.
>
> Humans are great at intuition, but suck at probabilities. Conversely computers are great at probabilities, but suck at intuition.
>
> Schema.org is currently targeted at the middle. If I (as a human) use the term http://schema.org/publisher, the "inference" (by a machine) is that the object is a schema:Organization, but only probabilistically. Some creative works are "published" by people. It's a trivial example, but it help illustrate why schema:rangeIncludes is more useful and interesting than rdfs:range. It provides a open-world mechanism for the data consumer (aided by computers but summarily judged by humans) to learn about other possibilities.

I think we are talking about different things here. I am not comparing 
schema:rangeIncludes with rdfs:range, but with the class-centric 
definition that I suggested below. The class-centric approach is more 
flexible (for machines) than rangeIncludes, and can easily also be used 
to produce things like UML diagrams that are intuitive to understand by 
humans.

Holger


>
> This keynote presentation by Martin Hepp from 2012 might help illustrate the pragmatic limits of free-range vocabulary use: http://vimeo.com/51152934. In particular, starting at time 14:40 and again between 20:45 and 23:55.
>
> Jeff
>
>> -----Original Message-----
>> From: Holger Knublauch [mailto:holger@topquadrant.com]
>> Sent: Wednesday, December 17, 2014 8:03 PM
>> To: Young,Jeff (OR); W3C Web Schemas Task Force
>> Subject: Re: Property Names, was Re: Automotive, EXIF, Property-Values
>>
>> On 12/18/2014 10:56, Young,Jeff (OR) wrote:
>>> One of the things I love about Schema.org and
>>> schema:domainIncludes/rangeIncludes is that it trusts the
>>> intuitive/probabilistic meaning of terms. The OO-style is babel in
>>> comparison. OTOH it seems true that babel wouldn't have been such a
>>> problem the 1st time around if they had clusters of computers the way
>>> we do now. :-/
>> Apologies, I don't understand your point about babel. Could you rephrase this
>> a bit?
>>
>> And why should it be good to have "intuitve/probabilistic" meaning, given that
>> computers neither have intuition nor are good as probabilities. Such info is
>> more useful for humans than machines.
>>
>> Holger
>>
>>
>>>
>>>
>>>> On Dec 17, 2014, at 7:37 PM, "martin.hepp@ebusiness-unibw.org"
>> <martin.hepp@ebusiness-unibw.org> wrote:
>>>> Hi Holger,
>>>> Thanks for the pointer!
>>>>
>>>> For schema.org, it may be sufficient to work with a OO-style handling of
>> properties, where properties are bound to a type, are inherited along the type
>> hierachy and could change their exact behavior also based on the actual type
>> they are used with (in schema.org, this would mainly mean to be able to
>> override the default naming for a property).
>>>> The interesting question is IMO to find a solution that is
>>>>
>>>> a) easy for developers (ideally, they would not need to care about
>>>> potential name clashes between properties) and instead just look at
>>>> the current type and its properties
>>>> b) works in the non-RDF worlds of major search engines and
>>>> c) has a round-tripping translation to and from RDF worlds.
>>>>
>>>> Cheers
>>>>
>>>> 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
>>>>
>>>> Check out GoodRelations for E-Commerce on the Web of Linked Data!
>>>> =================================================================
>>>> * Project Main Page: http://purl.org/goodrelations/
>>>>
>>>>
>>>>
>>>>
>>>>> On 18 Dec 2014, at 01:21, Holger Knublauch <holger@topquadrant.com> wrote:
>>>>>
>>>>>> On 12/18/2014 0:13, mfhepp@gmail.com wrote:
>>>>>> Side-comment:
>>>>>>
>>>>>> Personally I think we will have to go to a "frame-based" approach in
>> schema.org sooner or later, i.e. defining properties locally for each type or
>> supertype, so that name clashes between independent branches of schema.org
>> will not be too much of a problem.
>>>>>> So "code" for http://schema.org/MedicalTherapy would no longer need to be
>> the same as "code" in any other context.
>>>>> +1
>>>>>
>>>>> FWIW there is an active W3C group on Data Shapes [1] where the topic
>>>>> of how to associate properties with classes is an important issue.
>>>>> One proposal (that I am supporting there) is using a (Turtle) syntax
>>>>> such as
>>>>>
>>>>> schema:MedicalEntity
>>>>>     a rdfs:Class ;
>>>>>     rdfs:subClassOf schema:Thing ;
>>>>>     :property [
>>>>>         :predicate schema:code ;
>>>>>         :valueType schema:MedicalCode ;
>>>>>         rdfs:label "code" ;
>>>>>         rdfs:comment "A medical code for the entity, taken from a
>> controlled vocabulary or ontology such as ICD-9, DiseasesDB, MeSH, SNOMED-CT,
>> RxNorm, etc." ;
>>>>>     ] ; ...
>>>>>
>>>>> which resolves some of the problems of only having global property
>> definitions like in RDF Schema. It avoids the problems of rdfs:domain/range
>> (and schema:domainIncludes/rangeIncludes), has the ability to have context-
>> specific comments and labels, as well as additional property characteristics,
>> all in a single consistent format. (Note that I used the default namespace for
>> the system properties because this proposed language does not have a name
>> yet).
>>>>> The JSON-LD would look similar and can hopefully be inferred.
>>>>>
>>>>> I'd appreciate feedback if such a syntax as above would be of interest to
>> the schema.org community and future versions of the RDF mapping.
>>>>> Disclaimer: although I am a member of that W3C group, I do not speak on
>> behalf of the group - no decisions have been made yet, and the above is my
>> personal proposal.
>>>>> Holger
>>>>>
>>>>> [1] http://www.w3.org/2014/data-shapes/wiki/Main_Page

Received on Thursday, 18 December 2014 03:09:55 UTC