Re: Schema.org and OWL

Thanks for the links guys.

I'm definitely not trying to make Schema into "one true logical model of
the world", I do always think it's worthy to strive for simplicity and
consistency though, something maybe similar in intention to code refactoring
<https://en.wikipedia.org/wiki/Code_refactoring>.

Here is a problem that exists now though because of overly specific domains
- if I want to describe the height of the Eiffel Tower, a Place, I'd want
to use the "height" property, but the only types "height" can be used on
are MediaObject, Person, Product, and VisualArtwork. I completely get the
volcano-with-fax-number approach, and I'm actually a big fan of it, that's
why I propose moving properties such as "height" to Thing. A guideline that
Schema might be able to apply here could take inspiration from the rule of
three <https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming)> -
 *whenever a property is used on more than two types move it to the parent
type*. Using this guideline "height" would be on Thing, and could then be
used to describe the Eiffel Tower.

I'll end now with one final suggestion, I realize it probably has no chance
of going anywhere, but I'll put it out there for consideration anyway.
After moving those properties to Thing I realized that because
CreativeWork, Product, and Intangible don't have clear definitions all they
do is add complexity (how many times is it asked whether products are also
creative works and vice versa). It would arguably be simpler to have all
their properties on Thing and ThingType. This is in line with the
volcano-with-fax-number approach, and would give great flexibility.

Thanks for all the discussion!

Anthony

On Thu, Jun 14, 2018 at 4:09 PM Dan Brickley <danbri@google.com> wrote:

> On Thu, 14 Jun 2018 at 15:19, Anthony Moretti <anthony.moretti@gmail.com>
> wrote:
>
>> I think Martin's point about passing information from product types to
>> product instances can be addressed higher in the hierarchy than Product
>> actually. I sense people are opposed to shifting properties from more
>> specific types to Thing though (maybe I don't understand something, can
>> someone please explain that to me?) My view is that using overly specific
>> domains for properties causes strange entailment, e.g. in its current form
>> the "height" property entails the subject is either a MediaObject, Person,
>> Product, or VisualArtwork, which doesn't seem right.
>>
>
> On this point - "e.g. in its current form the "height" property entails
> the subject is either a MediaObject, Person, Product, or VisualArtwork,
> which doesn't seem right." -- we don't really say that anywhere, and in
> fact we created looser variants of rdfs domain/range for documentation, to
> avoid saying more than we wanted to. On the contrary, in
> http://schema.org/docs/datamodel.html  -
>
> "When we list the expected types associated with a property (or
> vice-versa) we aim to indicate the main ways in which these terms will be
> combined in practice. This aspect of schema.org is naturally imperfect.
> For example the schemas for Volcano <http://schema.org/Volcano> suggest
> that since volcanoes are places, they may have fax numbers. Similarly, we
> list the unlikely (but not infeasible) possibility of a Country
> <http://schema.org/Country> having "opening hours". We do not attempt to
> perfect this aspect of schema.org's structure, and instead rely heavily
> on an extensive collection of illustrative examples that capture common and
> useful combinations of schema.org terms. The type/properties associations
> of schema.org are closer to "guidelines" than to formal rules, and
> improvements to the guidelines are always welcome
> <https://www.w3.org/community/schemaorg/>."
>
> In this regard, you might view this aspect of Schema.org as being closer
> to the "The Code is more what you call guidelines, than actual rules
> <https://www.youtube.com/watch?v=jl0hMfqNQ-g>" tradition of the Pirates
> of the Caribbean than the expectations you might bring from the OWL world,
> even if we target much the same underlying data model.
>
> If this might seem less thank helpful, I'd suggest a possible
> middle-ground would be to explore the RDF validation languages - SHACL and
> ShEx - which suggest ways of layering certain kinds of discipline over
> messy RDF data. It doesn't address all the modeling concerns raised here,
> but does offer another layer of expressivity which needn't happen in the
> core project.  You could look at
> https://www.topquadrant.com/technology/shacl/tutorial/ or
> http://book.validatingrdf.com/ -- e.g. http://datashapes.org/schema
> attempts to capture some of schema.org itself in SHACL, whereas
> https://github.com/SEMICeu/dcat-ap_shacl/ (in SHACL) and
> https://github.com/SEMICeu/dcat-ap_shacl/issues/32 (in ShEx) try to
> capture specific useful community-specific patterns for describing
> datasets. These languages let people say things about Schema.org data
> structures, beyond what the project itself chooses to say. For example by
> constructing and documenting more tidy-minded subsets/profiles, or mixing
> it with longer tail vocabularies (like Wikidata's e.g. see Thad and
> friends' mappings <https://github.com/schemaorg/schemaorg/issues/280>) or
> richer domain models e.g. from the sciences, and explaining sensible
> patterns for these combinations. You could look at what the Blue Brain
> project are doing there, for example -
> https://github.com/BlueBrain/nexus-kg/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+shacl
> or the ShEx efforts around HL7/FHIR,
> https://www.hl7.org/fhir/medication.shex.html
>
> That kind of perspective I think makes two points. One is that
> Schema.org's modeling style and hierarchical structure is not the only
> place where discipline can be exercised usefully; and the second is that
> more "knowledge graphy" usecases (beyond simple Web markup) are likely to
> engage with other vocabularies and systems (e.g. scientific domains or
> general like Wikidata), in which case we're unlikely to see a unified
> modeling style across it all, and will likely end up focussing - again - on
> documenting usefully re-usable patterns that address particular situations.
>
> Dan
>
>
>