- From: Simon Spero <sesuncedu@gmail.com>
- Date: Thu, 22 Jan 2015 09:23:51 -0500
- To: Martin Hepp <martin.hepp@unibw.de>
- Cc: ☮ elf Pavlik ☮ <perpetual-tripper@wwelves.org>, Gregg Kellogg <gregg@greggkellogg.net>, W3C Web Schemas Task Force <public-vocabs@w3.org>
- Message-ID: <CADE8KM5AKru+_dGz8sc1quGq4uQQYsdsUBA+czDQZOG=3jszNw@mail.gmail.com>
If only some devilishly handsome Englishman were to somehow write a tool for mapping from sdo into owl axioms and post some remarks on his immediately obvious discoveries to a mailing list.... On Jan 22, 2015 6:51 AM, "Martin Hepp" <martin.hepp@unibw.de> wrote: > 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 14:24:22 UTC