Thanks for working on that. Unfortunately you were right, I forgot one more spot where the tracking deletion was called.
However I seem not to be able to push to the merge request and I don't know how to push on it otherwise :/
I thought the negation would be more convenient because it does not touch the existing behaviour and I don't have to change any defaults in the database etc. I would really be more happy with an interface for the users to simply check the option. Our typical target group is art historians who hardly are able to install Drupal at all and can't really handle the installation itself - so having no option here does simply give our project team even more load in infrastructural parts, while it could be avoided :/
I've attached a patch for IndexLoadItemsTest.php.
I would like to maintain this module. I've already prepared a patch for Drupal 9 and 10 which would make it work again. ORCID is very important for scientific projects in Germany :)
Unfortunatelly I can not see the screenshots as watchdog seems to have removed them, I'm sorry :/
Can you send them to me via chat.wiss-ki.eu? :D
It is not very hardcoded, it looks in the pathbuilder for image paths for this particular group (in this case collection) and fetches things from that. How should this be more dynamic than auto-selected based on the available fields? :)
You don't need to maintain content twice, it is a semantic database. However you have to tell the system what you exactly want and what you want is: You want to have a collection and show all the images from this collection :)
And this is only possible by creating a collection semantically and have image paths there :)
Cheers
In Pathbuilder-logic: a main group talking about the collection and there has to be a field that references all the objects of the collection and all the images from these.
Hope this helps :)
Yes, that's possible. I guess we did not modernize the code of the skos adapter in some time as we didn't have a use-case for it. Do you need it and can you provide a use-case?
Cheers!
I don't really understand - what do you want to do with the gui? :)
Cheers!
yes, WissKI RDF via SPARQL1.1 Adapter is for RDF only and WissKI SPARQL1.1 Adapter with Pathbuilder is for OWL 1 only. The funny thing is that for us the typical usecase is OWL and not RDF and therefore we don't interpret rdf properties etc. Of course OWL is based on RDF, but the OWL-Adapter searches for owl:objectProperty etc. in the triple store and not for rdf:property. So the only real difference is what the adapters look for.
WissKI does a semantical mapping with the pathbuilder and to alter the pathbuilder in any way you will need an ontology, yes. But it may be any kind of rdf/owl ontology. However we have limitations to the features an ontology provides.... :)
I think it is configurable, you just have to build a form the collection and the collection has to have a field to all the associated images of the collection via the objects ( collection -> objects -> images of the objects). Then the manifest of the collection has everything in it :)
Cheers!
So you want all objects in one single window? One manifest for all objects?
You can do that by building your own view with all the objects in it.
But it will be a long time loading if there are many objects (our
object catalogue e.g. has ~172.000 objects with up to 1000 images per
object.
Cheers :)
Hm,
I'm unsure if I can help there. I know that between Mirador 3 and Mirador 2 the settings changed. Can you check if the setting array is correct for your version of mirador?
Cheers :)
It is used to display links to other entities. We used that in Drupal 6 when entity reference was not really working well. Furthermore it is much more performant than other solutions. It can be used e.g.: If you have a database of persons and a database of objects that belong to a certain person, then you can do such things like "for the object I am currently viewing, show me all the other objects the person possesses." etc.
Cheers!
Hi :)
I'm not sure if that really is a WissKI issue. Typically we just provide the options to the mirador viewer and we had problems with mirador itself in the past. I guess you would have to have a deeper look in the console, see if the parameter is really provided to mirador and if so you have to ask over at https://github.com/ProjectMirador/mirador - otherwise I'll have to fix that :)
Cheers!
You're welcome - don't worry about your english, I will try to understand everything and if not, I will ask back :)
See you there!
You have to check how your data is modelled. There are some people doing bad practices like using the uri of a concept as it's name etc. But somewhere there must be something in there that stores the data itself - so a string or whatever :)
We can meet on chat.wiss-ki.eu or somewhere else with screen sharing and have a look together! This will speed you up much more! You just have to propose something :)
Cheers!
In principle: You're doing it right.
Typically a path is something that should end on a datatype property, because the data is displayed here. So you can't end in an infinite circle.
What exactly should be shown where depends on you and you alone - just you know what is in your data and how you want it to be displayed for you and for other users. You can have a look at the example pathbuilder to see how we are typically doing things... but I would need much more information on your domain/data to point you into a certain direction :)
Cheers!
Did you save in the pathbuilder? You should get menus in /wisski/navigate according to the main groups of your pathbuilder. Do you see these? And you simply end up having 0 instances? Did you clear the cache? :) Is there anything in the logfile? Did you import your triples into a graph? I am unsure if it will work with the default graph of blazegraph :)
Cheers!
Dear all,
no, especially that is NOT one of the compatible links. http://erlangen-crm.org/231027/ is - it is set to download the ontology if you access the link directly and it works as intended :)
Cheers!
You go to Configuration -> WissKI Ontology and load this ontology by providing the URL. According to the Ontology the URL should be the base namespace (https://renie26.github.io/homepage.github.io/resource/ont/MAoCorpus/MAon... has http://EncodingActs.github.io/annotated/MAon# as base namespace). However http://EncodingActs.github.io/annotated/MAon# gives me a 404 neither the base namespace nor the file on github do fulfill the requirements from the "Best Practice Recipes for Publishing RDF Vocabularies" (https://www.w3.org/TR/swbp-vocab-pub/). So in fact this ontology is a worst praxis example for a not-really-linked-open-data (without wanting to offend anybody - they probably do their best!).
So this probably can't be loaded from WissKI properly and there is only a workaround possible which is directly loading the ontology to the triplestore into a named graph "http://EncodingActs.github.io/annotated/MAon#". However this does not give you any namespaces - that simply does not work with work-arounded ontologies.... We do not really intend to support worst-practices :/ But you should not have any drawbacks from that other than a not-so-beautiful pathbuilder...
Sorry!
Switch on Quad-Mode. WissKI needs full SPARQL 1.1 support :)
Cheers!
Smartgroup should calculate the "common" part of the group automatically. It was like that in Drupal 6 - but it made more problems than it solved - so this functionality never was implemented in the current version.
So never use SmartGroup pls :) - it will be deleted.
Cheers!
You don't do that. The pathbuilder does not use the labels currently and does not care about languages. And language of the T-Box does not affect the language of the A-Box. You can create entities as a user with multiple languages and they are handled by language-flags on the strings automatically like:
E21_Person_Knurg is_identified_by E41_Appellation_Person_name_of_Knurg has_string_representation "Knurg"@en :)
You just have to enable the desired languages in drupal and switch on entity translation for the WissKI entities.
Cheers!
We have generic support for anything that can be imported via SKOS and several specific authority file adapters that draw information directly from the authority file provider like GND and Geonames :)
So it depends on what you want to do! I would need more information about that to be more specific and point you to the correct direction :)
Cheers!
In Drupal 6 we had modules like https://www.drupal.org/project/thejit → - but we don't have these currently in D10 :/
Cheers!
Yes, we speak english on demand, just ask in english and we answer in english.
There are english community parts, but we can't force germans to do it right away currently :)
Yes, I think we should throw out apus some time in the future, but currently people still use them in drupal 8/9 and we will have to migrate this code or find a new solution to be backward compatible :/
Cheers!
Yes, this is also the purpose of WissKI - go for it! :)
Just be sure to do the modelling correctly according to your data :)
Cheers!
yes, that is the purpose of WissKI and the BIG difference to nearly anything else out there like Wikidata etc.
Cheers!
I don't think that we will do that:
- Nobody really used this module
- Nowadays it is much more flexible to do such things with views :)
-> Delete Jit Module and/or build modules on it's own via views.
You can't! They are populated from your ontology when loading the ontology. :)
Cheers
These modules are only minimally maintained and for backward compatibility. They are used for triple generation from html text fragments. If you need help with that, contact the usergroup directly at https://chat.wiss-ki.eu/ :)
Cheers!
@rnsrk Please clarify the documentation :)
The red color marks the disambiguation point, see https://wiss-ki.eu/de/node/54 :)
Cheers!
Yes, you have to create an adapter, see https://wiss-ki.eu/documentation/authority-files - in the beginning:
CONFIGURATION
Add adapters
:)
Cheers
There is a running docker container with an example wisski with
example data at
https://wiss-ki.eu/documentation/installation/docker/wisski-example
Cheers :)
I am unsure if virtuoso really works as WissKI does queries with e.g.
the * operator. The typical systems we had used in the past are rdf4j,
graphdb, blazegraph and stardog. Jena FUSEKI was not working well in
the past because it did not do cross-graph-reasoning which is needed
if you have a rather complex ontology tree in the backend.
We will have to join forces on this as we don't have virtuoso up and
running and you have it.
You have to select the adapter according to your needs. If you want to
do OWL you need the regular SPARQL 1.1 Adapter - that is what we
typically do. The RDF-Adapter is just in case you don't want to do OWL
and just want to do RDF, but it is optimized for the rdf version of
cidoc crm and might not fit your specific needs.
Default Graph etc. are prefilled by default with useful values that
should work right away. It won't trouble you in the beginning :)
There is a running docker container with an example wisski with
example data at
https://wiss-ki.eu/documentation/installation/docker/wisski-example
Cheers :)
Works well for me - lets add this! +1!!! :)
Thanks to all for the great work!
I hope I've catched em all.