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

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

From: Young,Jeff (OR) <jyoung@oclc.org>
Date: Thu, 18 Dec 2014 02:15:11 +0000
To: Holger Knublauch <holger@topquadrant.com>, W3C Web Schemas Task Force <public-vocabs@w3.org>
Message-ID: <DM2PR0601MB113553C1272FFB8600876D8CAD6A0@DM2PR0601MB1135.namprd06.prod.outlook.com>
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.

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 02:15:42 UTC

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