Sheet2RDF and prefixes

[Thomas Francart]

Hello

The Sheet2RDF documentation related to how prefixes are analyzed [1] read the following:

"""

names for headers may follow two conventions:

• a valid qname (e.g. "skos:prefLabel")
• a custom name (e.g. "name").

In the first case, for the qname to be meaningfully used, its prefix should be mappable to a given namespace, by means of one of the following:

• the prefix is known a priori by the system (i.e. skosxl, skos, owl, rdfs, rdf,...)
• the prefix/namespace mapping is present into the input Model
• prefix/namespace is reported into the prefix_mapping sheet

"""

1. What is the "input Model" in the context of Sheet2RDF plugin in VB ? is it the project from which Sheet2RDF is launched, or something else ?
2. From my tests, it seems that Sheet2RDF is unable to read the prefixes declared in the VB project. If I name my column "xyz:foo", and prefix xyz is declared in the VB project, it will never be mapped automatically. Should it ? I wish it could ! (I tried closing/reopening the project. I correctly see the prefix when browsing the classes tree)
3. It would be nice if prefixes are interpreted also by the DefaultConverter : that is, if the value in a cell corresponds to a valid qname according to the known prefixes in the project, it should be turned into the corresponding URI automatically. My use-case is with an rdf:type column : it contains a few different values expressed with a qname, but the DefaultConverter will not recognize this. I will change them to full URIs.
4. With the use-case above, may I suggest an an idea for new converter ? a converter that would define a mapping from input values to target URI (could be target literals, also). So that, when the column contains a known and limited number of values, the mapping to the target URIs could be part of the mapping itself. The mapping would be passed as a parameter to the converter.

Cheers

Thomas

[1] :https://art.uniroma2.it/sheet2rdf/documentation/heuristics.jsf

--

Thomas Francart - SPARNA
linked data | domain ontologies | knowledge graphs
blog : blog.sparna.fr, site : sparna.fr, linkedin : fr.linkedin.com/in/thomasfrancart
tel :  +33 (0)6.71.11.25.97

[stel...@uniroma2.it]

Dear Thomas,

 

thanks, I’ve put it on the list of potential improvements.

Going specifically your points, I see that the Model is a reference to our OWLART API, which have been abandoned when we created VocBench 3 (those were used in VB 2, an old version that was developed in a conjoint effort with FAO). So, with any probability, we simply lost that part when switching to a native use of RDF4J.

So, I added this improvement, regaining the old functionality (it should be pretty easy) together with your idea of a new converter (which, btw, rang a bell to me and I was wondering whether we already developed something like that, but I don’t seem to see it in any converter list). Indeed, another possibility could be to make it CODA-centralized and have this as a feature for any converter (sort of pre-converter operation corresponding, in this case, to a check on the map which, if != null, would return the result and prevent the actual conversion). That could still be obtainable, should we go instead for creating a converter, with a converter chain.

Thanks as usual for your valuable input!

Armando

 

 

 

--
You received this message because you are subscribed to the Google Groups "vocbench-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vocbench-use...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vocbench-user/CAPugn7XxOkstsEzDMuWPGoSM3EZYku7z2qBLLrG54Z7L3-hwRg%40mail.gmail.com.