Forum

Forum Navigation
You need to log in to create posts and topics.

Proposed Schema.org enhancements/changes

Having read through the Mark Up For Terms Of Services and Privacy Notices document I have a few comments to make.  These are from the point of view of someone working often with the Schema.org vocabulary and have over the years been part of several successful enhancement proposal submissions.

  1. General Approach
    • Schema.org is a generic vocabulary of over 2,000 terms that is applicable to all spheres of interest including, news, the media, commerce, ecommerce, bibliographic, medical, education, automotive, legislation, tourism, archives, etc., etc. To that end care has to be taken for each area not to claim use of terms and term names too specifically that would prevent their use, or reuse by others.
    • In addressing real world situations, use is often made of what is known as multi typing.  This is where an entity is described as being of more than one type.   This approach can often greatly simplify proposed extensions to the vocabulary.

      A good example of this being for tourism situations. An initial proposal contained many new types (TouristHotel, TouristBeach, etc.). It was soon realised that this list could be significant.  The resultant proposal consisted of a catchall Type of TouristAttraction which could be added to other types to make any entity type also a tourist attraction.  Check out this example and others on the page to see what I mean. (this is relevant to my comment on LegalDocument below)

  2. LegalDocument, PrivacyNotice.
    Although these proposals are focused on online documents, it is clear that not all legal documents are web pages.  Therefore it would be too restrictive to other domains if LegalDocument became a subtype of WebPage.

    If it became a direct subtype of CreativeWork it could be used on its own to describe individual [legal] documents or in combination with DigitalDocument or WebPage to describe a digital [legal] document or an online legal document.

  3. WebpageSection
    Would not the current type WebPageElement serve this purpose?  Or are you proposing this to enable you reference Section xy.z as per other types of legal documents and legislation.  If that is the case, it should be addressed in the domain of legal documents not web pages.
  4. Readability
    Again this is a feature of more broad applicability than for just web pages.  It is relevant to all forms of text and their accessibility concerns.
  5. Contacts
    The author/publisher/accountablePerson properties of CreativeWork and its subtypes are probably sufficient to define such relationships as you describe.  They are not really attributes of a Person, other than possibly their job title being coincidentally appropriate, as you describe.
  6. Personal Data
    This is an area of significant complexity I would suggest handling separately with reference to other initiatives in this area.

Hopefully these comments will be helpful as your proposals evolved and are refined.

 

~Richard.