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