Edit non-SKOS dataset in VocBench

[Frederik Elwert]

Hello,

we are making good use of VocBench in editing a SKOS thesaurus. Now we have another dataset in RDF, but not in SKOS, that we would like to edit in a similar fashion. (It’s a gazetteer following the LinkedPlaces format[1]). The hierarchical concept view would actually be useful because the place entries in the gazetteer also have a hierarchical structure.

Is it possible to edit a non-SKOS RDF dataset in VocBench? The website suggests so but I could not find out how to approach this. We would need the main entries to be of class geojson:Feature instead of skos:Concept, and add some custom properties.

Any hints are very much welcome.

Regards,

Frederik

[1]: https://github.com/LinkedPasts/linked-places-format/

[Pedro Paulo Favato Barcelos]

Hi Frederik,

Do you want to edit the non-SKOS dataset inside a SKOS project or are you going to create a new project? Vocbench allows you to create an OWL project with RDFS lexicalization, which can be what you are looking for. 

In addition, when already inside a project, you can import other ontologies (vocabularies, datasets, etc.) in Metadata > Namespaces and Imports.

Hope this can be useful =)

Kind regards,

Pedro Paulo F. Barcelos

[Armando Stellato]

Sorry,

 

it didn’t make it up to the list. For some reason with some senders even with a reply-all I get the address of the sender only, so I’m resending it.

 

Kind Regards,

 

Armando

 

From: Armando Stellato On Behalf Of Armando Stellato
Sent: Tuesday, September 21, 2021 10:40 PM
To: Frederik Elwert <frederi...@rub.de>
Subject: RE: [vocbench-user] Edit non-SKOS dataset in VocBench

 

Dear Frederick,

 

I’m glad you find well with VocBench.  About the RDF dataset, well, it’s more a matter of reversing the problem :-)

 

VB indeed allows you to edit whatever data you find providing that it’s RDF triples. Obviously, if you want to see a nice class diagram in the graph view, you need to have classes (rdfs or owl classes), if you want a concept tree, you need concepts… and so on…

 

Note that it’s still possible to see a SKOS tree if the data is not directly represented as SKOS. You can always remap (if it’s possible) your ontology to SKOS by stating that a certain class that classifies your objects is, say, a subclassof of skos:Concept. VocBench will check inheritance so this would work and still allow you to have your custom classes.

When I say “if it’s possible” I mean not from the mere technical point of view of VB (you can always edit whatever you want) but “publication-wise”. E.g. if the ontology you are using is not under your control (i.e. it’s not published by you) then you shouldn’t alter its axioms. You can extend it, but not alter the content that it’s already there (e.g. the description of a resource defined there).

Same thing with properties. If there’s certain property realizing the hierarchy, then you can consider making it a subproperty of skos:broader (and, again, VB will check the inheritance when building the tree)

 

I gave a quick look at GeoJSON [1] and, assuming that you are not the developer of it, I suggest not to change the ontology. However, there seems also no reference to any hierarchy. The elements are geographical references such as point, line, polygon etc..

So, besides what VB can do, you should ask yourself: if I had the perfect interface build exactly for it, how would I look for its content?

For instance, if the various primitives could have names, you could rdfs:label them, and then use the search to look into the whole recordset of geometry primitives. In order to restrict the search, you could import the GeoJSON ontology, select with the mouse the class for which you want to look for a certain instance, and then use the search, filtering it on the class.

Another possibility is that the GeoJSON geographical objects are attached to some other meaningful object (e.g. the set of points describing the perimeter of a countryhouse, expressed through GeoJSON, and then possibly described according to an ontology of yours. Then you may consider if it’s not the case to represent the classes of this description as subClassesOf skos:Concept so that all of their elements would be *also* skos:concepts. Then each relevant object of your domain (e.g. “my country house”) could be easily searchable, and only then you would find the associated set of points, in case you want to check them.

 

Kind Regards,

 

Armando

 

 

[1] https://en.wikipedia.org/wiki/GeoJSON

 

--
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 on the web visit https://groups.google.com/d/msgid/vocbench-user/5453d3f8-f799-4c9a-a7a0-6feaacdce9aen%40googlegroups.com.

[Frederik Elwert]

Hi Pedro,

it’s a new project. A plain OWL/RDFS project might indeed be the way. But I guess one would lose the nice hierarchical structure that the SKOS view provides. Will try it out anyway.

Thanks,

Frederik

[Pedro Paulo Favato Barcelos]

Good morning!

In OWL projects you are going to view hierarchy in class structure, where a class may be a subclass of others. If your data are instances, they really are not going to be represented in a hierarchical way. In SKOS projects, "everything" made available are Concept, hence its hierarchy displays broader/narrower relations (which can be instantiation, part-of-relations or whatever you decide it to be).

Been aware that I am in a Vocbench group (I hope it is not a problem to comment about other tools here), you can also import and develop the dataset in other tools (but you can also use Vocbench, as mentioned) and export the data for a specific visualization tool, where you can set your preferences.

Kind regards - Cordiali saluti - Atenciosamente,
Pedro Paulo Favato Barcelos

--
You received this message because you are subscribed to a topic in the Google Groups "vocbench-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vocbench-user/LiNUpO7qK1c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vocbench-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vocbench-user/5e53886d-aff3-4a19-ac3d-06f76f57be86n%40googlegroups.com.

[Frederik Elwert]

Dear Armando,

thank you very much, that’s a lot of food for thought. You are right, GeoJSON does not have a concept of hierarchy, but LinkedPlaces extends it in various ways (through the use of other vocabularies). So I guess subclassing my main class to also be a subclass of skos:Concept might actually work. LinkedPlaces uses gvp:broaderPartitive for hierarchical relations. One complication is that it does not use it directly as a property, but through a sort of reification mechanism based on lpo:RelAttestation. So each place can have a set of reified relations, in JSON-LD notation:

"relations": [ { "relationType": "gvp:broaderPartitive", "relationTo": "http://mygaz.org/places/p_9876", "label": "part of Berkshire (UK)", "when": {"timespans":[ {"start":{"in":"1600"},"end":{"in":"1974"}} ]} },

I don’t know if I could make VocBench recognized that as a hierarchical relation, I guess I’d have to play around with that.

Thanks for the pointers anyway!

Regards,

Frederik

[Armando Stellato]

Hi!

 

Just jumping in the discussion for the “I hope it is not a problem to comment about other tools here”. Absolutely not a problem :-)

This is the discussion group of an open source software and any reference to anything outside it that is useful and constructive for the thread is well accepted and even welcome if it can suggest something to improve VB (or to discover that something was already possible, sharing the experience with the community).

 

So, no restraints :-)

 

Kind Regards,

 

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 on the web visit https://groups.google.com/d/msgid/vocbench-user/CAN0bbw6-ebMKpF02Tu8F4k7yjWBsJN31YPj13UxRh9FU3QxdeA%40mail.gmail.com.

[Pedro Paulo Favato Barcelos]

Great! Thank you Armando for making us so comfortable to use this discussion board! 

Kind regards - Cordiali saluti - Atenciosamente,
Pedro Paulo Favato Barcelos

[Thomas Francart]

Hello

VB indeed allows you to edit whatever data you find providing that it’s RDF triples. Obviously, if you want to see a nice class diagram in the graph view, you need to have classes (rdfs or owl classes), if you want a concept tree, you need concepts… and so on…

 

Note that it’s still possible to see a SKOS tree if the data is not directly represented as SKOS. You can always remap (if it’s possible) your ontology to SKOS by stating that a certain class that classifies your objects is, say, a subclassof of skos:Concept. VocBench will check inheritance so this would work and still allow you to have your custom classes.

Often this is not what one wants to do from an ontology engineering point of view.

As "VB allows to edit whatever data you find providing that it's RDF triples", it would be nice if "VB allows you to browse in a tree whatever data you find providing that it's any RDF triples expressing some kind of hierarchy" (not only skos broader/narrower or owl subClassOf). I am sure the tree view uses some configuration underneath that allows it to work with either SKOS or OWL, it would be nice if this kind of configuration is made visible when configuring a project, just as one chooses a lexicalisation model, one could choose or setup a "hierarchical display model".

Just my 2 cents !

Thomas

 

To view this discussion on the web visit https://groups.google.com/d/msgid/vocbench-user/AS8PR09MB4982E610DF62AD0E93060148C7A29%40AS8PR09MB4982.eurprd09.prod.outlook.com.

--

Thomas Francart - SPARNA
Web de données | Architecture de l'information | Accès aux connaissances
blog : blog.sparna.fr, site : sparna.fr, linkedin : fr.linkedin.com/in/thomasfrancart
tel :  +33 (0)6.71.11.25.97, skype : francartthomas

[Armando Stellato]

Hi Thomas!

 

100% agree.

I was describing the current situation and what can be done. Indeed, we will add this functionality to VB most probably with the next release. Pls consider that the current SKOS and OWL tree views are not just a simple query with a reconfigurable property. There’s quite a ton of other things (one would not think it’s so much, but there’s lot of stuff there, transitive closure of the property, nature of the resources – a set of various features - which requires in turn the transitive closure of the types of the resources, considering deprecation etc.. + a configurable rendering query fragment which is injected in the main query and that’s just the tip of the iceberg..) and many of these are specifically implemented for OWL and SKOS.
However, a trivial, configurable, hierarchy explorer added to them would do no harm and that’s why it’s on the TODO list :-)

 

Given the above, which I consider important in a system, I still suggest, to the matter of interoperability, that one considers the best way to make its data understandable by less-smart and configurable clients. E.g. removing all the fuss about “what being a concept is”, I think that SKOS provided a good way to tell any tool “hey! This is a hierarchy! And it’s not a hierarchy of categories (with all the implications of it), but a mere hierarchy of ground objects”. And a big difference between the rdfs:subClassOf and skos:broader (besides, again, the nature of the resources involved) is that the first represents a property which is relevant per se, thus it is normal to be transitive and have lot of implications attached, while the other is artificial: it is meant to visually build hierarchies (that’s why it is not transitive by default), up to the point for which the name itself (broader/narrower) might be misleading, in that it is legit to use it for purpose of a hierarchy, even though the relation is not really the one of being broader/narrower.

Obviously, considering something means not “doing that mandatorily”, so this is just a general advice for considering a mixed OWL/SKOS option.

 

Kind Regards,

 

Armando

[Armando Stellato]

Again, forwarding to the list…

 

From: Armando Stellato On Behalf Of Armando Stellato
Sent: Thursday, September 23, 2021 11:27 AM
To: Frederik Elwert <frederi...@rub.de>
Subject: RE: [vocbench-user] Edit non-SKOS dataset in VocBench

 

Dear Frederick,

 

there’s a way indeed, but before letting u waste time, I need to check one thing.

 

IF the tree is built by also considering inferred relationships, you could tinker with a ruleset in GDB to add a non-standard inference for which the reified relation is flattened into a normal one. Indeed, if the reification is performed through a simple property chain, then this property chain could be declared equivalent to a simple property by adding an axiom in OWL and then an OWL ruleset that covers p-chains would be enough.

 

The thing to check is if the concept tree is built by including inferred triples. I think that it did, but we chose at a certain point in time to avoid inference and only show the tree by working on explicit knowledge and trivial reasoning (e.g. subproperties of skos:broader) which is however performed on-the-fly as part of the SPARQL query. Just for your knowledge, the set of properties that can be used to drive the tree can be configured, it is possible to choose if to exploit subproperties etc.., however it’s still properties and not chains.

 

You gave us food for thought as well, as this could be an addendum to the configuration of the tree. It’s really a corner-case though, so we should find the best way to deal with it.

Another possibility, since reification is a not-so-uncommon problem, is to add configurable support for inference on reified statements (configurable to address specific patterns, thus getting beyond the mere prop-chains in OWL2) on the trivial inference sail that we introduced in VocBench since version 8.0

 

Kind Regards,

 

Armando

 

P.S: I see that the reification comes from the management of time in that ontology, in lack of some official way to deal with time in RDF. I’ve seen many attempts like that. Unfortunately, if each ontology follows its own patterns, what we get is something far from interoperability. A good solution should at least foresee two (redundant) paths, or at least a simple path for currently valid assertions and a reified one for those valid in a certain period.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/vocbench-user/d6a1319c-fd85-4618-a707-c9afe1b524d8n%40googlegroups.com.