Re: github repository for the personalisation

hmmm…
My response to this is a bit of a worry!

I think that it is clear how to do the metadata and what can, therefore, be done for coga. I think that a lot of what we ended up with in the past was not good….and I would not recommend it.

The Benetech effort was great - quickly we got a set of terms that make a lot of sense, hit the low-hanging fruit, and show the ideas work.

I think that by now we should have released a detailed version of this from ISO that would make it easy for everyone. We have failed in that although we are still working on it.

I recommend making metadata that complies with the Metadata for Learning Resources standard (ISO N19788) which means terms that are expressed in the most interoperable way - choose your term but express it in a ‘best practice’ form, and then let the set of terms grow as people find them useful. BTW, the MLR Framework is available free at http://standards.iso.org/ittf/PubliclyAvailableStandards/c050772_ISO_IEC_19788-1_2011.zip and I think that reading that would help. (For the metadata buffs, the MLR is just DC metadata but a bit tighter and in some places more focussed on specific types of resources - it’s clean RDF metadata!)

The problem with the IMS stuff is that the model is different - and not so interoperable, and the schema.org stuff put together by Benetech and pals was done in a very ‘light’ form - not so easy for some detailed systems but good for the big search engines.

I would be willing to propose to ISO that alongside the basic set of terms I have proposed and worked on, we might want a specific set for coga? That would make sense to me.

I think the big plus ISO offers is internationalisation - so it is well worth doing work there.

Liddy
> On 20 Jul 2015, at 6:39 pm, EA Draffan <ead@ecs.soton.ac.uk> wrote:
> 
> We certainly do not want to reinvent the wheel and I agree with Liddy and Lisa that we need to look at all that has been created so we do not make more work for ourselves.  
>  
> Here is a link for more on the subject. https://wiki.benetech.org/display/a11ymetadata/Access+For+All+and+ISO+24751+Overview
>  
> Best wishes
> E.A.
>  
> Mrs E.A. Draffan
> WAIS, ECS , University of Southampton
> Mobile +44 (0)7976 289103
> http://access.ecs.soton.ac.uk
> UK AAATE rep http://www.aaate.net/
> http://www.emptech.info
>  
> From: lisa.seeman [mailto:lisa.seeman@zoho.com] 
> Sent: 19 July 2015 14:23
> To: Liddy Nevile <liddy@sunriseresearch.org>
> Cc: public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>
> Subject: Re: github repository for the personalisation
>  
> Hi Liddy
> Firstly I think we all completely agree that the personalisation should be useful for everyone. We also agree resolved that final terms for personalisation   should be about functional requirements , not disability. However we also need to know what we are talking about at this stage. So a mapping is in order.
>  
> As you know I am a huge fan of RDF. However there are also barriers to entry that does not happen with JSON. 
> Anyway, my 2 cents is we  should review  accessforall, but we need to do it quickly. (Review of existing approaches was last years work)
>  
> Is there a relationship between  AccessForAll and GPII or is this independent? Our resolution with GPII was that we should be independent but compatible.  Also, worth noting that the meta data proposal is separate from the in page personalisation proposal in github.
>  
>  
> All the best
> 
> Lisa Seeman
> 
> Athena ICT Accessibility Projects 
> LinkedIn, Twitter
> 
> 
>  
> 
> ---- On Sat, 18 Jul 2015 22:52:25 +0300 Liddy Nevile<liddy@sunriseresearch.org> wrote ----
> Hello Everyone. 
> 
> I am nervously asking myself why the personalisation for coga would be any different from the personalisation for anything else? 
> 
> Working with ISO and others, we have been developing metadata to describe the components of resources (services, interfaces, etc) so that a person can specify their particular functional requirements for resources and these can be matched to mirrored descriptions of resources. 
> 
> Here is an example: I want a resource using a limited vocabulary so I add metadata such as text=vocab1000 to my request. Someone publishing a resource has described the resource as having limited text ie text=vocab1000. A search engine can then decide that this resource will be suitable for me. 
> 
> In the ‘AccessForAll’ approach we call the functional requirements ‘needs and preferences’ and we say that the needs are essential but the preferences are also good, if possible. 
> 
> This is the approach being taken by schema.org for things like large font etc so I cannot see why it would not work for coga. Of course, there are other things one might want to say about a resource, especially the subject or the author or something like that. So accessibility metadata can be mixed with other metadata that specifies the subject etc. For this reason, the metadata needs to be interoperable. For many of us, that means it should be RDF triples. The work to make this possible has been done and can be re-used in the coga context. 
> 
> The exciting thing, for me, is that Google and Yahoo and Bing and Yandex are already indexing a huge number of resources with this sort of metadata. 
> 
> The other exciting thing for me is that if a resource is not in the required form, say not limited vocab, someone or a robot can make a limited vocab version and that can be connected with the original resource by metadata. Similarly, if the original resource provider does not provide metadata, someone else can. 
> 
> If I am in the wrong ball-park, please feel free to tell me! 
> 
> If you want to look at more of this…I hope I can help. 
> 
> Liddy 
> 
> > 
> > Hi all, 
> > We opened a github repository for the personalisation at: 
> > https://github.com/ayelet-seeman/coga.personalisation/ 
> > 
> > If you have any students who would like to contribute, upcoming hackathons, or just anyone interested in contributing, they are more than welcome! 
> > 
> > regards, 
> > Ayelet Seeman 
>

Received on Monday, 20 July 2015 23:16:41 UTC