W3C home > Mailing lists > Public > public-schemaorg@w3.org > October 2019

Re: .NET, Ruby and PHP libraries for schema.org: classes vs enumerations

From: Richard Wallis <richard.wallis@dataliberate.com>
Date: Tue, 29 Oct 2019 11:39:26 +0000
Message-ID: <CAD47Kz6vfV2fCTbUH7RYEEedu8PwnXyi0+gyECSE_51E_VoUhw@mail.gmail.com>
To: Nick Evans <nick.evans@theodi.org>
Cc: "schema.org Mailing List" <public-schemaorg@w3.org>, Tim Hill <tim.hill@theodi.org>
Hi Nick,

This is an area that, as you quite rightly identify, has become a little
confused as the vocabulary has evolved.

In simple cases, BookFormatType <https://schema.org/BookFormatType> for
example, there are Enumerations (defined as a rdfs:class and as a subclass
of schema:Enumeration) then there are enumeration members, or values.
These are not defined as a rdfs:Class but as of type of the parent
enumeration (eg. EBook <https://schema.org/EBook> is defined as being of
type schema:BookFormatType).

Unfortunately this simple approach has in some cases been complicated in a
couple of ways.

   - Some enumeration values (eg. DrugClass <https://schema.org/DrugClass>),
   are defined both as a rdfs:Class and as a subclass of the enumeration.
   - Some enumerations values (eg. CreditCard
   <https://schema.org/CreditCard>) have been defined as both subclass of
   an enumeration and subclassof a [non-enumeration] class (eg.
   PaymentCard, LoanOrCredit)

There are some other variations if you dig a bit deeper.

This, as you also identify, causes difficulties when developing code to
deal with enumerations & enumeration values differently. This is even true
in theSchema.org codebase, where an enumeration value is displayed with a
separating '::' in its inheritance path (eg. Thing > Intangible >
Enumeration > BookFormatType :: EBook)

There has been some work on this in the Schema.org repository that has yet
to make it into the production code.  It is subject of Pull Request #2250
<https://github.com/schemaorg/schemaorg/pull/2250>.  The principle being
that an enumeration must be defined as a rdfs:class and as a subclass of
schema:Enumeration,  an enumeration value not being defined as a
rdfs:class, but of type of an enumeration.  Also a type that is in an
unbroken chain of subclass from an enumeration value, can also be
considered an enumeration value.

This Pull Request has not yet been merged into the code as the
ramifications spread across several areas of the vocabulary, especially
medical and finance, and it is difficult to assess impacts.  Also it does
not address the issue where a type is defined as being both a subclass of
an enumeration and a normal class in its own right, complete with its own
unique properties.

Fortunately, these anomalies seem to cause few difficulties in the use of
the terms in markup, or as far as I am aware in their interpretation.  The
challenges appear when writing software tools to aid the description or use
of the vocabulary.

I believe applying the Pull Request I referenced will make things a little
more consistent in the vocabulary definition files.  However the challenge
of what to do with a type that is both an enumeration value and a normal
class with useful properties, still remains.

Sorry I couldn't provide an answer to your question.  Hopefully this has
clarified the problem smewhat.


Richard Wallis
Founder, Data Liberate
Linkedin: http://www.linkedin.com/in/richardwallis
Twitter: @rjw

On Tue, 29 Oct 2019 at 10:42, Nick Evans <nick.evans@theodi.org> wrote:

> Hi all,
> We're currently working on creating PHP and Ruby libraries that port the
> great work that @RehanSaeed <https://github.com/RehanSaeed/> has done
> over at https://github.com/RehanSaeed/Schema.NET/, as part of the
> OpenActive.io <https://www.openactive.io/> project.
> We've come across an interesting problem in how we map schema.org
> enumerations to equivalent language constructs in .NET, Ruby and PHP.
> There are quite a few classes
> <https://github.com/RehanSaeed/Schema.NET/issues/92#issuecomment-546991622> that
> appear to be *both* a class and an enumeration:
>    - https://schema.org/PaymentCard inherits from *both* Enumeration and
>    Service:
>       - Thing > Intangible > Enumeration > PaymentMethod > PaymentCard
>       - Thing > Intangible > Service > FinancialProduct > PaymentCard
>    - https://schema.org/DrugClass inherits from *just* Enumeration, but
>    has a property ("drug"), so appears to be treated like a class
>    - http://schema.org/BedType and other subclasses of QualitativeValue
>    <https://schema.org/QualitativeValue> and MedicalEnumeration
>    <https://schema.org/MedicalEnumeration> display properties in the
>    schema.org GUI, so appear to be available as a class?
> Discussing <https://github.com/RehanSaeed/Schema.NET/issues/92> with
> @RehanSaeed, we're unsure what logic should be applied for determining
> whether an rdfs:Class from the JSON-LD
> <https://schema.org/version/4.0/schema.jsonld> representation should
> appear in the library as an enum vs as a class with properties.
> Our current assumption is that anything that subclasses
> https://schema.org/Enumeration should be strictly an enum (which is how
> Schema.NET works at present).
> <https://github.com/RehanSaeed/Schema.NET/issues/92>See further details
> here: https://github.com/RehanSaeed/Schema.NET/issues/92
> Any hints greatly appreciated?
> Many thanks,
> Nick
Received on Tuesday, 29 October 2019 11:39:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:12:49 UTC