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

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
>>>>
>>>>
>>>>
>>