Re: Enumerations: courseMode <CourseMode>, courseDigitalFormat <CourseDigitalFormat>, accessibilityPhysicalFeature <AccessibilityPhysicalFeature>

As I think is clear from this and similar threads in other areas, the
chances of consensus across overlapping and partially overlapping groups,
areas of expertise and interest resulting in a workable *One Enumeration
Set to Rule Them All* is probably unachievable.  Such a set becoming part
of Schema.org or an extension vocabulary being even less likely.

Ideally URIs/Values from authoritative industry or academic groups should
play a significant part here.  Some already exist (Library of Congress
Subject Headings being a classic example).

As Wes points out, the technical barriers are not too large in publishing
such a set of enumeration values - an authoritative group of people
committing to create and maintain them at a persistent location.
Alternatively identifying a good existing authoritative source and helping
them publish their values as a persistent URIs.

On the Markup side of things, as Phil pointed out, there is a proposal <
https://github.com/schemaorg/schemaorg/issues/894> focused on marking up
enumerations on external [to Schema.org] sites.

~Richard

Richard Wallis
Founder, Data Liberate
http://dataliberate.com
Linkedin: http://www.linkedin.com/in/richardwallis
Twitter: @rjw

On 1 June 2016 at 15:49, Wes Turner <wes.turner@gmail.com> wrote:

>
>
> On Wednesday, June 1, 2016, Phil Barker <phil.barker@hw.ac.uk> wrote:
>
>> Hello Wes, everyone.
>> Yes, enumerations are good when you can reach consensus on what they
>> should be. The problem is agreeing on them across the scope of all people
>> who might use schema.org. External enumerations [1] would help by
>> reducing the scope of the required agreement. In general, I think the
>> enumerations can be added later. I think we can propose a property and
>> then, when we see how it is used, add in enumerations as required.
>>
>> Taking the properties that you suggest would benefit from an enumeration
>> in turn:
>>
>> AccessibilityPhysicalFeature
>> - I think this is beyond our competence. Physical accessibility for
>> events / locations needs to be considered in a much wider context than
>> Courses and by people who understand the issues involved. I would rather
>> leave it to a different working group. (This incidentally is what LRMI did
>> for accessibility of creative works, and it worked out quite well.)
>>
>
> So it was in scope for LRMI.
> It's a property (accessibilityPhysicalFeature) and like 10+ Enumerations
> (braille, largePrint, wheelchairAccessible,).
>
>
>>
>>
>> CourseMode
>> - Agreed. The option set for the CEDS Course Section Instructional
>> Delivery Mode https://ceds.ed.gov/element/001161 seems like a good
>> starting point. I know Jim Goodell is interested in whatever it takes to
>> make the CEDS vocabularies more usable in the wider RDF world.
>>
>>
>
> CEDS: CourseSectionInstructionalDeliveryMode
>
> schema.org: courseDeliveryMode ?
>
> [external] enumerations (name, URL) would hopefully reduce the number of
> misspelled schema.org/Text properties (so that faceting by this attribute
> is reasonably feasible without extensive de-duplication)
>
> we could include Text in the range for courseDeliveryMode but expect URLs
> of Enumeration Things with names (because those are translatable)
>
>
> > In general, I think the enumerations can be added later. I think we can
> propose a property and then, when we see how it is used, add in
> enumerations as required.
>
> -1 on "everyone will realize they need to go back and re-work to upgrade
> from Text to URL later"
>
> * "IDK, the person who did it last semester must've done it wrong and it's
> too late to change now"
>
> Here's how those go (folksonomy -> structured vocabulary):
>
>
>    - "Interactive Audio/Video"
>    - "Audio/Video"
>    - "AV"
>    - "Audio-Video"
>    - "Audio"
>    - "Video"
>    - https://ceds.ed.gov/element/001161#AudioVideo
>
>
> With just Text, there's not enough information.
>
> * RDF requires URLs (IRIs) as subjects (not Text)
>   * <#AudioVideo> a Enumeration
>   * <#AudioVideo> schema:name "Audio/Video"@en
>   * <#AudioVideo> schema:name "ljud video"@sv
>   * <#AudioVideo> schema:description "Course is taught via remote
> interactive receiver or via streaming media technologies."  # CEDS
>
> * When you want to GROUP BY courseDeliveryMode, if they're not all
> consistent URLs, it's very noisy/lossy/insufficient (and then faceted
> interfaces don't work without deduplication)
>
>
>
>
>>
>>
>> CourseDigitalFormat
>> - I am not convinced we even need this as a property. Can we start a
>> separate thread to discuss it?
>>
>
> CourseDigitalFormat is necessary in order to identify courses which offer
> digital formats (such as complex XML schema).
>
> There's no need for a separate thread; or a separate mailing list; or a
> separate issue ticket.
>
> - [ ] Add the property (courseDigitalFormat)
> - [ ] Add the External Enumeration class (CourseDigitalFormat) # see
> above/below
> - [ ] Create a wiki page to host said Enumerations
>   - [ ] REQ: @vendors: pick a camelCase URL for a SMWiki page
>
>
>
>
>>
>>
>> W3C support for Semantic MediaWiki
>> - What level of support? The community group wikis are Semantic MediaWiki
>> (at least according the badge on the bottom right of the
>> schema-course-extend and web-schemas wikipages). Do you mean support in how
>> to use it? I tried using SMW for a different task last summer and found it
>> a difficult combination of RDF thinking and some of the more esoteric
>> features of MediaWiki.
>>
>
> We should now be able to define Enumerations in a [SMWiki] table of
> structured data
> (such that, when we parse an [Enumerations] wiki page for {RDFa,
> Microdata, JSON-LD, Turtle} with e.g. OSDS
> https://github.com/openlink/structured-data-sniffer ,
> we can generate what we need (e.g. labels, description) in our
> applications from RDF without copy-and-pasting); IDK who would be helpful
> with that.
>
> [*] Inline links are much more accessible than (not linked) footnote
> citations.
>
>
>> Phil
>>
>> 1. https://github.com/schemaorg/schemaorg/issues/894
>>
>> On 21/05/16 16:22, Wes Turner wrote:
>>
> In reading the examples that Phil added here:
>> <https://github.com/westurner/schemaorg/pull/3#issuecomment-220782903>
>> https://github.com/westurner/schemaorg/pull/3#issuecomment-220782903
>>
>> I wonder whether, for faceted interface support, we should have
>> courseMode Enumerations?
>>
>> We could define said Enumerations just like these:
>> https://www.w3.org/wiki/WebSchemas/Accessibility
>>
>>
>> AccessibilityPhysicalFeature (for Place, Event, CreativeWork, )
>> https://www.w3.org/wiki/WebSchemas/Accessibility PhysicalFeature
>> - name
>> - description
>> - url
>> - image / logo / photo (Creative Commons {SVGs,} would be great here)
>> - https://github.com/schemaorg/schemaorg/pull/972#issuecomment-173698449
>>
>>
>> CourseMode
>> https://www.w3.org/wiki/WebSchemas/CourseMode
>> - name
>> - description
>> - url
>>
>>
>> CourseDigitalFormat
>> https://www.w3.org/wiki/WebSchemas/CourseDigitalFormat
>> - name
>> - version
>> - description
>> - url
>>
>>
>> Suggestions:
>> - These Enumeration URLs should/could be copy-paste-able
>> - Semantic MediaWiki supports RDFa
>>   - IDK how feasible it would be to get W3C support for Semantic
>> MediaWiki (or really who to contact for such a request)
>>
>>
>>
>> --
>> --
>> Phil Barker           @philbarker
>> LRMI, Cetis, ICBL     http://people.pjjk.net/phil
>> Heriot-Watt University
>>
>> Ubuntu: http://xkcd.com/456/
>>   not so much an operating system as a learning opportunity.
>>
>>