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

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