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

I believe that the situation described has been arrived at with little
design perspective controlling influence. Just arrived at through the
differing understandings of contributors to the vocabulary.

However, with well established terms exhibiting the enumeration/normal
class pattern, it would be difficult to back out of the situation without
potentially significant ramifications.  In which case I believe the current
approach will probably have to become the default.  A feature then!

I agree progressing PR #2250
<https://github.com/schemaorg/schemaorg/pull/2250> could simplify things a
little, plus some addition to the Data Model
<https://schema.org/docs/datamodel.html>documentation may at least alert
those that follow us.

~Richard.


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



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

> Thanks Richard, that's very helpful.
>
> It sounds like from a schema.org design perspective you plan to preserve
> the ability for a term to be both an enumeration/value and a normal class
> with useful properties? So this is a feature rather than a bug?
>
> Therefore any solution in the libraries needs to allow for both of these
> to co-exist, e.g. by namespacing the enums separate from the classes.
>
> The PR you've put together should simplify code generation for tooling
> overall, but the design of the libraries we're discussing will still need
> to handle both cases?
>
> Would this make sense as an "official schema.org" view from your
> perspective?
>
> Many thanks,
>
> Nick
>
>
>
> On Tue, 29 Oct 2019 at 11:39, Richard Wallis <
> richard.wallis@dataliberate.com> wrote:
>
>> 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.
>>
>> Richard Wallis
>> Founder, Data Liberate
>> http://dataliberate.com
>> 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
>>>
>>>
>>>
>
> --
>
> Nick Evans
>
> Associate & Sector Specialist
>
> Open Data Institute <http://theodi.org/> | +447813318661
>