Created attachment 275477 [details] [review]
ontology: Make nie:language property multi-valued

Remove cardinality of 1 from 'nie:language' property so that each
resource can have multiple languages assigned to it. The only example we
currently have is of Microsoft Windows installer media, where each media
could support installation in multiple languages.

Created attachment 275478 [details] [review]
extract-iso: Extract language info

Make use of libosinfo API to extract list of supported languages.
Application (e.g Boxes) can then use this list to determine the most
suitable language to start express installation in.

Created attachment 275479 [details] [review]
extract-iso: Update copyright/author list

*** Bug 729121 has been marked as a duplicate of this bug. ***

Ontology wise, nie:language is not the place to put the *supported* languages.

A multi-valued property for osinfo:Installer looks more appropriate.

(In reply to comment #5)
> Ontology wise, nie:language is not the place to put the *supported* languages.
> 
> A multi-valued property for osinfo:Installer looks more appropriate.

Just so you know, we had some discussion about this on IRC and felt while we could have separate resources per nie:language property, it makes query and insert work much more work. Incidentally, nie:language is completely unused right now, other than in the functional-tests. Given the use cases, it seems much easier to have a multi-valued approach for nie:language. Though it doesn't play well with other "Information Element" properties, like nie:title, which isn't multi-valued either.

Ivan, I can see your point too. For example, perhaps you have nie:title and nie:language which are related somehow, for example, nie:title could be "hola mundo" and nie:language "es", and then you may want nie:title "hello world" and nie:language "en", for the same resource (or file). Looking at the specification, they suggest the title and language should be for an "Information Element", so why not just have another Information Element?

Another basic example I can think of is desktop files and application titles or content where they support multiple languages.

According to the spec nie:language is:
"""
Language the InformationElement is expressed in. This property applies to the data object in its entirety. If the data object is divisible into parts expressed in multiple languages - more specific properties should be used. Users are encouraged to use the two-letter code specified in the RFC 3066.
"""

I see 2 things wrong with this.

1. There is no provision for data objects divisible into parts expressed in multiple languages.

2. RFC 3066 seems quite inadequate, i.e. "en" vs "en_GB". The later is more useful.

Specification is covered here:

  http://www.semanticdesktop.org/ontologies/2007/01/19/nie/#language

Zeeshan, simply put, if we are to avoid diversifying from the spec, we should not make nie:language multi-valued.

(In reply to comment #6)
> (In reply to comment #5)
> > Ontology wise, nie:language is not the place to put the *supported* languages.
>  http://www.semanticdesktop.org/ontologies/2007/01/19/nie/#language
> 
> Zeeshan, simply put, if we are to avoid diversifying from the spec, we should
> not make nie:language multi-valued.

Thanks for the research! I'll submit alternate patches that add 'osinfo:language' property.

Created attachment 276106 [details] [review]
extract-iso: Extract language info

Make use of libosinfo API to extract list of supported languages.
Application (e.g Boxes) can then use this list to determine the most
suitable language to start express installation in.

Comment on attachment 276106 [details] [review]
extract-iso: Extract language info

Hello Zeeshan, the patch looks fine except that 'languages' is not freed and it looks like it should be according to the documentation.

I've not tested this yet, but feel free to push to master once the memory leak is fixed.

Comment on attachment 276106 [details] [review]
extract-iso: Extract language info

Committed with leak fixed