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

On 12/19/14, 12:33 AM, Kingsley Idehen wrote:
> On 12/17/14 10:06 PM, Holger Knublauch wrote:
>> 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 
>
> Will the following syntax:
>
> 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." ;
>     ] ; ...

Let me try to rephrase what this means in prose: The property 
schema:code is potentially relevant for all instances of 
schema:MedicalEntity (and its subclasses). When used for such instances, 
all values of the property schema:code are expected to have type 
schema:MedicalCode (or a subclass of it). User interfaces displaying 
instances of MedicalEntity should use the provided label and comment 
when talking about schema:code. The comment also doubles as a 
description for API documentation etc. The constraint does not narrow 
down the expected number of values (cardinality) - that would be done 
via :minCount and :maxCount. Instances of the class may have many other 
properties, and there is no limit on using other properties that are not 
explicitly enumerated via :property.

>
> Equate to the following, semantically (represented using "is  of" 
> syntax sugar)?
>
> schema:MedicalEntity
> a rdfs:Class ;
> rdfs:subClassOf schema:Thing ;
> is schema:domainincludes of
>                                             schema:code,
>                                             schema:MedicalCode,
>                                             rdfs:label "code",
>                                             rdfs:comment .

Something feels missing above (did some characters disappear?), but yes 
:property is comparable to the inverse of schema:domainIncludes, only 
that it uses a (blank) node to collect various characteristics of the 
property and thus carries more information than domainIncludes. In fact 
it also includes rangeIncludes and many other things.

>
> I am hoping the shapes related syntax sugar is distinct from actual 
> underlying semantics.
>
The proposed syntax above has formal semantics, backed by SPARQL queries 
(e.g. using COUNT for the cardinality checks). (In terms of SPIN, 
:property is just a sub-property of spin:constraint, and the bnode is a 
SPIN template call.)

HTH
Holger

Received on Thursday, 18 December 2014 23:34:55 UTC