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

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

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Thu, 18 Dec 2014 20:32:22 -0500
Message-ID: <54938026.8050208@openlinksw.com>
To: public-vocabs@w3.org
On 12/18/14 8:16 PM, Kingsley Idehen wrote:
> On 12/18/14 6:34 PM, Holger Knublauch wrote:
>>
>> 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 
>
> Holger,
>
> Sorry! I should have taken it as RDF rather than thinking (for 
> whatever reasons) it was syntax sugar :)
>
> Anyway, how about, this little tweak:
>
> @prefix spin <http://spinrdf.org/spin#> .
>
> <#property>
> rdfs:label "Property";
> rdfs:comment "An Attribute of a Class, where each Attribute is a 
> Name=Value pairing.";
> rdfs:subPropertyOf spin:constraint .
>
> 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."
>     ] .

Minor aesthetic tweak:

@prefix spin: <http://spinrdf.org/spin#> .
@prefix schema: <http://schema.org/> .

<#property>
rdfs:subPropertyOf spin:constraint ;
# rdfs:label "Property";
rdfs:label "property";
rdfs:comment "An Attribute of a Class. An Attribute being a Name=Value 
pairing.";
rdfs:subPropertyOf spin:constraint .

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."""
     ] .



-- 
Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog 1: http://kidehen.blogspot.com
Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this




Received on Friday, 19 December 2014 01:32:44 UTC

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