W3C home > Mailing lists > Public > public-most-important-priorities@w3.org > February 2015

RE: Proposed W3C priorities for education

From: Marcos Caceres <marcos@marcosc.com>
Date: Wed, 18 Feb 2015 16:45:13 +1000
To: crispin.weston@saltis.org
Cc: "public-most-important-priorities@w3.org" <public-most-important-priorities@w3.org>, "Michael Champion (MS OPEN TECH)" <michael.champion@microsoft.com>
Message-ID: <etPan.54e43572.12200854.dabe@Zero-privacy.local>
Hi Crispin,

I'd like to echo what Michael said. There doesn't appear to be any need for new foundational work to be done as part of what you described below: that is, nothing that can't be done with HTML5/CSS/Web APIs, RDFa, XML, etc. already. The challenges you outline below are very (education) domain-specific, which is fine, but not anything the web platform can really help with (apart from providing the formats and protocols onto which you can standardize something that helps solve the problems you outline).  

As such, I would also strongly urge you to  form a community group (CG) and begin the work you propose there (for the IPR reasons Michael mentioned) and so you can find limitations in practice. If, as part of that work, the CG discovers they can't do something with HTML5/CSS/Web APIs, RDFa,  XML, etc., then we can look at addressing that as part of a larger standardization process. 

My concern with doing this work as part of the W3C "priorities" banner is that it might distract us from finding more immediate limitations in the Web Platform. So far, nothing has been presented that would require amendments to HTML5/CSS/Web APIs, RDFa,  XML, etc. within the context of education. Hence, it would be best for you to begin standardization of the things you describe below within the W3C's Community Groups framework, together with members of the education community, and see how far you get before you all hit limitations (if any!). If you don't hit any, then we are golden :) Otherwise, please do bring them back to the priorities list for evaluation so we have a better idea what we need to add/fix. 

Kind regards,

On February 18, 2015 at 10:25:54 AM, Crispin Weston (crispin.weston@saltis.org) wrote:
> > Hi Michael,
> Thanks for the questions. I would answer them as follows.
> 1. The specifications that I am proposing would be layered on  
> top of foundational W3C standards and not replace them. TinCan  
> provides a standard Web API. The IMS Content Packaging standard  
> was expressed as an XSD.
> What is missing from the base standards is a level of semantic  
> interoperability that will allow me to develop e.g. a common  
> mark book that can harvest meaningful information from any instructional  
> software, without having to modify my code to create a bespoke  
> integration. I don't see how this can be done without standard  
> data models.
> There has been much talk about big data in education - but most  
> commentators agree that data in education will be small compared  
> to the sort of data that search engines get to work on. That means  
> that if anyone is to make any sense of it, it has to be structured.  
> It is those education-specific semantics and structures that  
> need to be shared.
> You suggest a lack of skill/tools in the education community.  
> It may be relevant that ed-tech, at least at present, does not  
> have a huge amount of money. Creating bespoke integrations with  
> third-party services on a bilateral basis (which is how this  
> often works in business) is expensive. So there was a great benefit  
> in giving everyone very clear and somewhat prescriptive instructions  
> on how to ensure that their software could achieve plug-and-play  
> interoperability with other services. It also has to be said  
> that in the early 2000s, ADL was well funded and was able to create  
> a pretty good and free test harness for people to ensure that they  
> were compliant with the specification.
> It is also worth noting that the idea that most non-digital educational  
> metrics are infamously subject to misinterpretation, as teachers  
> try to do the best for their students. The labelling of education  
> objectives (often called criterion referencing) is widely  
> recognised to have been problematic, owing to everyone interpreting  
> the criteria in different ways. This is another reason why clear  
> semantics are required.
> 1a. There have been plenty of attempts to create consensual solutions  
> in education, which is what I think a community group would aim  
> to do. The trouble with consensual approaches is that they tend  
> to entrench orthodox positions and are not a good basis for innovation,  
> which is what ed-tech requires at present. It is for that reason  
> that I propose (1) description languages that would enable new  
> data models to be created by self-selecting, innovative partnerships,  
> and (2) partnerships with public sector Ministries of Education,  
> which ultimately hold the purse strings in education markets  
> and who are interested in encouraging this sort of innovation.  
> You might then ask how my proposed "data model description language"  
> would differ from e.g. XSD. I would prefer to defer answering  
> that question, which would get into technical detail, until  
> we had discussed the general approach and in particular my other  
> points, where the requirement is, I believe, more straightforward.  
> 2. With respect to IP, TinCan/xAPI is ultimately owned by the  
> US DoD and I would be very surprised if they created any problems  
> over IP. Everything else I propose is new work with no incumbent  
> IP holders. Of the specifications that caused problems in the  
> past, Simple Sequencing never worked well and needs to be completely  
> replaced and Content Packaging has been rendered obsolete by  
> the web. This is pretty virgin territory.
> Crispin
> On February 17, 2015(http://airmail.calendar/2015-02-17%2012:00:00%20GMT+10),  
> Michael Champion (MS OPEN TECH)  
> wrote:
> ...(bloop://bloop_expand)
Received on Wednesday, 18 February 2015 06:47:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:30:59 UTC