- From: Phil Barker <phil.barker@hw.ac.uk>
- Date: Thu, 25 Feb 2016 17:47:32 +0000
- To: "public-schema-course-extend@w3.org" <public-schema-course-extend@w3.org>
Well, that got complicated & confusing. Richard and I had a chat this afternoon, he suggested we try something different. Briefly, it is to try a new starting point (and I hope I have interpreted correctly): Do not have separate types for Course and CourseOffering. Define Course as a subtype of both Creative Work and Event, which can be used for both the abstract description and the concrete instances. Define a coursePresentation property of Course to relate the concrete instances to the abstract description when necessary. (I guess and inverse property might useful). When describing a concrete instance of a course, declare it to be both a Course and an Offer. This allows the use of price, offeredBy, ApplyAction and so on. There is an mock-up of this at http://course.schema-course-extend-rjwprop.appspot.com/Course If you scroll right down to the bottom there are a couple of examples as Google testing tool output (more or less human readable) and RDFa. Any comments on this as a general approach? Does it make enough of a distinction between a Course and its Sections/Presentations/Offerings for it to be clear to people who care about such a distinction? Don't worry too much about details of the properties that are currently in the mock-up, that could lead more rabbit holes prematurely. Phil -- -- 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.
Received on Thursday, 25 February 2016 17:48:17 UTC