Improve SKOS Concept parsing to allow use of intermediate SKOS Concept

[rioug]

This PR fixes the following issues :

• Product Type not allowing top concepts connector-ruby#13
• Allow intermediate SKOS concept to be used connector-ruby#9

Additional background : datafoodconsortium/connector-ruby#13 (comment)

It allows the ruby connector to use intermediate SKOS concept for Product Types and Facets ie:

• connector.FACETS.TERRITORIALORIGIN.EUROPE.FRANCE
• connector.PRODUCT_TYPES.DRINK.SOFT_DRINK

It didn't make sense to use intermediate for Measures so I kept the original behaviour (it can be easily fixed if needed)

I am not familiar with the design, but I don't think it makes sense for DataFoodConsortium::Connector::SKOSConcept to be a subclass of DataFoodConsortium::Connector::SKOSInstance, so I used a helper module to share method needed by both class.
This also populates narrowers and broaders for SKOSConcept so it's easier to navigate the tree. Ideally I would have like them to return a list of methods so could do something like below without additional steps :

types = connector.PRODUCT_TYPES.DRINK.SOFT_DRINK.narrowers 
# [:FRUIT_JUICE, :LEMONADE, :SMOOTHIE]

# Access connector.PRODUCT_TYPES.DRINK.SOFT_DRINK.FRUIT_JUICE
connector.PRODUCT_TYPES.DRINK.SOFT_DRINK.public_send(types.first)

I didn't want to alter the existing behaviour of DataFoodConsortium::Connector::SKOSConcept#narrowers, that said the original values would still be available via skos:narrower semantic property. Any thought ?

This also populates prefLabels for DataFoodConsortium::Connector::SKOSConcept, I used an hash with locale has keys for ease of use ie :

{
  en: "drink",
  fr: "boisson" 
}

[mkllnk]

Great! This solves so many scenario.

My suggestions below are just cosmetic, really.

[mkllnk]

Would this work?

Suggested change

	if element["http://www.w3.org/2004/02/skos/core#narrower"]
	element["http://www.w3.org/2004/02/skos/core#narrower"].each do |narrower|
	@narrower.push(narrower["@id"])
	end
	end
	element["http://www.w3.org/2004/02/skos/core#narrower"]&.each do |narrower|
	@narrower.push(narrower["@id"])
	end

[rioug]

It does, but I find it harder to read.

[mkllnk]

Excellent! I'm looking forward to the merge.

[lecoqlibre]

Thank you @rioug.

I've made some recommendations, could you handle them?

Could you also update the general changelog (at the root of the project)?

I think one day the ruby connector should use a JSON-LD parser instead of our custom made one. The Ruby-RDF project seems to provide some great libs like json-ld. We should consider to use this some day. @mkllnk There is also a lib for LDP, it may be useful.

Like you said @rioug it would be nice to be able to navigate the tree like narrowers and broaders. It was the plan but I was not sure it would be used and at the beginning the connector was not supposed to provide a SKOS parser. But I think it is useful for everyone to have it.

@rioug I don't think narrowers was used in the existing behaviour of SKOSConcept. I think it is not populated by the parser.

[rioug]

@lecoqlibre all done!

Like you said @rioug it would be nice to be able to navigate the tree like narrowers and broaders. It was the plan but I was not sure it would be used and at the beginning the connector was not supposed to provide a SKOS parser. But I think it is useful for everyone to have it.

I am curious of what you are doing in the other language, looks like you are just querying the parse JSON for php, is that right ?

[lecoqlibre]

Thanks @rioug!

@lecoqlibre all done!

Like you said @rioug it would be nice to be able to navigate the tree like narrowers and broaders. It was the plan but I was not sure it would be used and at the beginning the connector was not supposed to provide a SKOS parser. But I think it is useful for everyone to have it.

I am curious of what you are doing in the other language, looks like you are just querying the parse JSON for php, is that right ?

The PHP version has an import method that save all the loaded RDF subjects (objects) into a store. We can then get them using a retrieve method (fetch). The intermediate SKOS concepts should be available in the store.

On the client side, in JavaScript/TypeScript we can use LDFlex which allows to access linked data using standard JavaScript dot property syntax. I use it in my different Solid projects, it's very nice and it's based on the incredible Comunica library (make SPARQL queries overs HTTP).