Re: Some interesting things that show up when using a reasoner to classify schema.org

Ah! Yes, that is also a viable way, much better than my proposal! The key advantage over my proposal is that the Python code for generating the documentation does not need to change - rangeIncludes effectively becomes rangeHint and domainIncludes domainHint, and the integrity constraint axioms will be modeled using rdfs:domain and rdfs:range with complex class definitions, as in this example (from GoodRelations):

gr:condition a owl:DatatypeProperty;
 rdfs:comment "A textual description of the condition of the product or service, or the products or services included in the offer (when attached to a gr:Offering)"@en;
 rdfs:domain  [ a owl:Class; 
       owl:unionOf (gr:Offering gr:ProductOrService) ];
 rdfs:isDefinedBy <http://purl.org/goodrelations/v1>;
 rdfs:label "condition (0..1)"@en;
 rdfs:range rdfs:Literal.

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





On 22 Jan 2015, at 12:21, ☮ elf Pavlik ☮ <perpetual-tripper@wwelves.org> wrote:

> On 01/22/2015 11:36 AM, Martin Hepp wrote:
>> Hi elf:
>> 
>> On 22 Jan 2015, at 11:26, ☮ elf Pavlik ☮ <perpetual-tripper@wwelves.org> wrote:
>> 
>>> On 01/21/2015 05:21 PM, Martin Hepp wrote:
>>>> Hi Dan,
>>>> A hands-on solution would be to add two internal "annotation" properties "rangeHint" and "domainHint" that allow explicitly triggering the display of certain schema.org types in the documentation.
>>>> 
>>>> 
>>>>   <div typeof="rdf:Property" resource="http://schema.org/purpose">
>>>> ...
>>>>     <span>Range: <a property="http://schema.org/rangeHint" href="http://schema.org/MedicalDevicePurpose">MedicalDevicePurpose</a></span>
>>>>     <span>Range: <a property="http://schema.org/rangeIncludes" href="http://schema.org/Thing">Thing</a></span>
>>>>   </div>
>>>> 
>>>> 
>>>> The documentation could then list the formal range (Thing) and popular types for the range (e.g. MedicalDevicePurpose)
>>> 
>>> http://schema.org/rangeIncludes
>>> Relates a property to a class that constitutes (one of) the expected
>>> type(s) for values of the property.
>>> 
>>> http://schema.org/domainIncludes
>>> Relates a property to a class that is (one of) the type(s) the property
>>> is expected to be used on.
>>> 
>>> AFAIK both of those don't cause any inferences so in a way they already
>>> act in a similar way to rangeHint and domainHint which you propose.
>>> 
>>> If rangeIncludes and domainIncludes have some *formal* consequences I
>>> think they could use bit more of documenting.
>>> http://schema.org/docs/datamodel.html
>> 
>> You are right that the documentation does not say so, but I assume the Google Structured Data Testing Tool and production systems inside Google/Bing/Yahoo/Yandex use rangeIncludes and domainIncludes to assess the validity of data.
>> 
>> The beginning of the discussion was that Simon reported a range of e.g. "Place OR Restaurant" as an inconsistency, and I replied that such patterns are in use in order to trigger more specific type hints.
>> 
>> If rangeIncludes and domainIncludes were just for type hints, we would not need to fix such domain or range specifications.
>> 
>> In my understand, rangeIncludes and domainIncludes were introduced in order to avoid the unintuitive semantics of domain and range in RDFS and OWL, and to be able to list alternative classes without defining a complex class that is the union thereof. 
>>> 
>>> BTW James M Snell in Activity Streams 2.0 uses owl:unionOf to specify
>>> multiple types for domain and range. Maybe (domain/range)Includes could
>>> act just as hints and schema.org could use something similar for
>>> expressing *formal* consequences?
>> 
>> GoodRelations has been using this pattern since ca 2008, too - as a means to stay within OWL without triggering unintended additional type inferences.
>> 
>> But still this pattern does not allow giving hints to users on popular specializations of the formally defined type or types.
> 
> I wanted to suggest that - instead of adding yet another informal way of
> specifying domain and range using *Hint. We could acknowledge current
> *Includes properties as informal hints intended for broad community of
> people, who develop various tools for publishing data on the web. Then
> we can add proper, formal definitions only relevant for much smaller
> group of developers who work on validators etc. This way we could use
> more complex constructs from OWL and improve alignment with broader
> Linked Data ecosystem :)
> 
>

Received on Thursday, 22 January 2015 11:48:51 UTC