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

If it's any inspiration, here's how I restructured schema-dts to do this
recently <https://github.com/google/schema-dts/pull/43>. I'm mostly looking
at how structural typing helps make well-formed JSON-LD. Duck-typing in
Ruby might give you something similar, but I don't know how much it would
apply to PHP (if you're heavily using its type system).

I wrote an article on the different examples Schema.org has for enums here
<https://blog.eyas.sh/2019/05/schema-org-enumerations-in-typescript/> and
how it informs what kind of representation might make sense. I.e. an enum
isn't closed set, and has some sub-classing logic that is interesting.
Here's an example from 'Audience' that shows this mixing well:


[image: image.png]

Best,
Eyas


On Sun, Nov 3, 2019 at 2:37 AM Nick Evans <nick.evans@theodi.org> wrote:

> Great thanks Richard, we’ll see what we can do to accommodate this.
>
> Many thanks,
>
> Nick
>
> On Tue, 29 Oct 2019 at 15:19, Richard Wallis <
> richard.wallis@dataliberate.com> wrote:
>
>> 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
>>>>>
>>>>>
>>>>>
>>>