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

On Wed, Jun 1, 2016 at 8:25 AM, Richard Wallis <
richard.wallis@dataliberate.com> wrote:

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

The difficulty isn't technical, it's authoritative group, commitment to
create, commitment to maintain 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.
>

AND, *what do we need to do to get this into the next build of schema.org
<http://schema.org>*!  Probably a matter for over on issue #894 or the main
schema.org list. But there are some of us that *want it* / *need it* and
would like to *see it* / *help it* progress.

Stuart


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