RE: Metashare as used by LingHub

 

 

On Tue, Jan 27, 2015 at 10:03 PM, Penny Labropoulou <penny@ilsp.gr <mailto:penny@ilsp.gr> > wrote:

Hi John and all.

Thanx for the quick work!

Below are a few comments/replies in between the lines.

 

1) Some names have been shortened, e.g., 'ConformanceToBestStandardsAndPractices' -> 
'StandardsBestPractices', should we accept such names or stay true to MetaShare?
I think we should decide this on a case-by-case basis; although some names are long, they are self-explanatory. In general, at ld4lt we have changed some names (e.g. resource to language resource) when it was agreed that the new label is better.

Hmm... change for the sake of change is difficult, particularly when it is only a small part of the vocabulary, that creates gotchas. 

There are some typos that we have spotted and also comments raised by various.


2) A lot of MetaShare names have (unnecessarily) the words 'Info', 'Type' or 'InfoType', we could eliminate these.
All “info” elements are in fact component names: in accordance to the CMDI principles, elements (and other components) are grouped into semantically coherent components. For instance, the identificationInfo groups together elements that are used for the identification of a resource, such as the resourceId, a url used as landing page, the resourceName and shortName, the description etc. If I have understood well, this structure is not needed/not a good practice for RDF and this is why they have been eliminated already at the IULA/UPF mapping.

“type” elements are used in MetaShare for components that can be re-used: e.g. persons can be licensors, contact points, resource creators etc., but in all cases they are encoded using the personInfoType, which groups together given name, surname, communication information etc. Again, I think this is not mapped in RDF as such, if I understand well.

Yeah that is my feeling too, I would like to shorten the names, however it seems hard to do this consistently as it would create clashes, e.g., ActualUse/ActualUseInfo, DocumentType/DocumentInfo


3) IULA have split the AnnotationType class into 5 subclasses (DiscourseAnnotation, etc.)

That’s an improvement from the original model and I suggest we stick to it.

4) There are many properties suggested by IULA or in the 'DISTRIBUTION' model that have no correspondence in the MetaShare data... we should discuss these on a case-by-case basis, right?

We have already discussed with Victor the distribution and licensing module and have come up with a proposal re-introducing some of the original MetaShare elements that were not mapped in the IULA/UPF version and using the odrl (mainly) and cc vocabularies ; the general ideas are to be found at https://www.w3.org/community/ld4lt/wiki/Metashare_vocabulary_for_licenses and https://www.w3.org/community/ld4lt/wiki/Examples and the mappings were documented in the previous googlesheet. I will add these to the new googlesheet by next week.

I incorporated all the functional (non-documentary) information from the distribution model already... or at least I tried, let me know if I missed anything.

Ok; to be checked

5) The Prev. Google Doc proposed mapping to both SWRC and BIBO, do we need to do BIBO as well (SWRC seems sufficient)?

6) I added the license modelling that LingHub does in ODRL, could one of our ODRL experts look at it and fix the last one?

Please, see also the two wikis on licensing, especially the examples. And as discussed, together with Victor we will provide a file with the RDF representations in odrl of the licenses used in MetaShare (of course, only of those that have not already been RDFized). 

This refers to "R4 To neatly represent conditions of use"... but I couldn't find the structured definitions of conditions of use so I wrote my own in the sheet titled "License Modelling"

To be checked and finalized by Monday.

7) Some property values, especially resource types, such as ontology or corpus were created as classes in the Google Doc, shall we confirm this usage pattern?

This needs some more thinking, checking the various cases. Is there a list of these?

This seems to be individuals of the classes 'ResourceType' and 'LexicalConceptualResourceType', approximately, here are the lists for reference:

In Prev. Google Doc: BabelNet*, ComputationalLexicon, Corpus, CorpusAudio*, CorpusCollection*, CorpusImage*, CorpusText*, CorpusTextNgram*, CorpusTextNumerical*, CorpusVideo*, Framenet, LexicalConceptualResource, Lexicon, MachineReadableDictionary, Ontology, TerminologicalResource, Thesaurus, ToolService*, WordList, WordNet

>From Metashare: computationalLexicon, framenet, lexicon, machineReadableDictionary, ontology, other*, terminologicalResource, thesaurus, wordList, wordnet, corpus, languageDescription*, lexicalConcepturalResource

*Unique elements

We might need a telco discussion for this, but first let me check the current mappings.

 

8) See attached diagram. There is a big difference in granularity between the XSD and IULA-UPF's ontology. For example, there are 4 tags between the resource and its actual usage in the XML, e.g.,

<resourceInfo> ...

  <usageInfo> ...

    <actualUsageInfo> ....

      <useNLPspecific>parsing</useNLPspecific> ....

Where is in the IULA model this is considerably simplified to

:resource a ms:Resource ;

  ms:actualUse ms:parsing   

 

This would be great, but it also loses information, for example, the IULA schema associates the availability with the Resource. However, the XSD schema associates an availability with each Distribution (download file). In fact, there are resources that have different availability for different downloads (e.g., BabelNet), so there is information loss here. Thus, LingHub is very conservative and sticks to the XSD, e.g.,

:resource a ms:ResourceInfo ;

  ms:usageInfo [

    ms:actualUsageInfo [

      ms:useNLPspecific ms:parsing ] ]

What shall we recommend here?

 

Again, discuss on a case-by-case basis. For instance, for availability, we have re-introduced the distribution element, as  otherwise we lose in semantics. For other cases, I think we should see them more closely. The grouping into components made sense in XSD because it brought together elements. I will have to look at them more closely and explain for each case why this grouping was meant, so that we can decide if this should also remain in the RDF mapping. Is there an easy way of spotting these cases?

OK, we should discuss this in a telco.

 

A final question: how will we add the comments/decisions from the previous googlesheet to the current one? As said, I can do this for the distribution/licensing module elements but for the rest?

Add any comments you want (possibly copied from previous doc). Apart from that I would like to keep the sheet itself clean until the next ldl4lt telco at least

Regards,
John

 

Best,

Penny