How to remove people from Vivo

53 views
Skip to first unread message

J. Dornbusch

unread,
Apr 6, 2020, 10:01:33 AM4/6/20
to VIVO Tech
Hello everyone,

We occasionally need to remove people from Vivo, typically when we find out that the person is a duplicate created by the automatic feeding system and we merge the two records externally.
Deleting the person from the back-office leaves all attached objects unchanged (vcard:Indiviual, etc.) and only deletes their relationship to the person.
Should we use the feed mechanism to eliminate all involved triples? Can people or organizations be safely deleted from the user interfaces?

Thanks for your help
Joachim

Gross, Benjamin

unread,
Apr 6, 2020, 11:31:06 AM4/6/20
to vivo...@googlegroups.com
Hi Joachim,

Unfortunately there’s no easy way to do this automatically. There are rare cases where the VIVO application has logic built in to traverse the graph ‘just far enough’ to delete the appropriate triples. I’m thinking about the image deletion functionality. The general problem lies in the complexity and variety within the VIVO ontology. 

For example, assume you have object A, connected to object B, which is in turn connected to object C. If you were to delete object A, should object B be deleted? How about object C? In your example, if we delete a foaf:Person (object A), we would like to also delete the vcard:Individual (object B), and the vcard:Name (object C) attached. But what about the publications for that person? If we delete the foaf:Person, we want to delete the attached vcard:Author (object B), but likely not the bibo:Document (object C) attached. 

So a multi-object deletion function has to be context aware. The way I handle this is by writing complex SPARQL queries that construct all the data I want to delete. It’s a huge pain. If it’s just a single thing I want to delete, I’ll do it through the UI, though. I think a nice feature in the UI would be a deletion option that allows you to delete the primary object, plus whatever else is created via the UI when you create a new object. It could re-use the logic in the form controller (I think this is how image deletion is set up). 

Benjamin




_____________________________ 
Benjamin Gross
VIVO Product Manager

Web of Science Group | webofsciencegroup.com

--
You received this message because you are subscribed to the Google Groups "VIVO Tech" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vivo-tech+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vivo-tech/c62b3f06-663a-4798-98ab-5bc6a7fdc2de%40googlegroups.com.

J. Dornbusch

unread,
Apr 7, 2020, 3:19:13 AM4/7/20
to VIVO Tech
Hi Benjamin

Thank you for this very complete answer.
I was thinking that perhaps, objects linked to a property marked as "stub" could be deleted when the "carrier" object is deleted.
Another possibility would be an automatic deletion of orphan objects: vcards without individuals, publications without authors, and for us membership without members. This could take place synchronously or asynchronously, through a script.

Joachim
To unsubscribe from this group and stop receiving emails from it, send an email to vivo...@googlegroups.com.

J. Dornbusch

unread,
Apr 9, 2020, 2:12:35 AM4/9/20
to VIVO Tech
Hi Benjamin

Following your advice I have written custom Sparql CONSTRUCT requests for the removal of people. It works well except that a few labels remain on "ghost" objects.

---------------------------------------------------------------------------------------------------------------------------------------------
| pred                                         | obj                                | graph                                                 |
=============================================================================================================================================
| <http://www.w3.org/2000/01/rdf-schema#label> | "Directeur.trice de recherches"@fr | <http://vitro.mannlib.cornell.edu/default/vitro-kb-2> |
| <http://www.w3.org/2000/01/rdf-schema#label> | "Research professor"@en            | <http://vitro.mannlib.cornell.edu/default/vitro-kb-2> |
---------------------------------------------------------------------------------------------------------------------------------------------

I tried to rebuild the "label" statements provided by the Sparql CONSTRUCT query.
But whatever I send to DELETE DATA through my Sparql client (Ruby)  has no effect on those labels :


RDF::Statement(statement.subject, RDF::RDFS.label, statement.object.to_s),
RDF::Statement(statement.subject, RDF::RDFS.label, RDF::Literal.new(statement.object.to_s)),
RDF::Statement(statement.subject, RDF::RDFS.label, RDF::Literal.new(statement.object.to_s, language: :fr)),
RDF::Statement(statement.subject, RDF::RDFS.label, RDF::Literal.new(statement.object.to_s, language: :fr, datatype: RDF.langString)
RDF::Statement(statement.subject, RDF::RDFS.label, '"'+statement.object.to_s+'"@fr')

Vivo update API doesn't seem to support the "DELETE WHERE" clause, which would be very convenient.

Joachim

Brian Lowe

unread,
Apr 9, 2020, 3:32:22 AM4/9/20
to vivo...@googlegroups.com

Hi Joachim,

 

Not sure what might have happened with your initial CONSTRUCT-based deletion.  The usual culprit when statements with literal values fail to delete is a character encoding mismatch somewhere between client and VIVO or VIVO and triple store, but the literals you show seem to include only ASCII characters where this wouldn’t likely be the issue.

 

I have used DELETE WHERE without problems.  One thing I would double check is that you’re explicitly specifying the graph to query and modify, in this case kb-2.  You should be able to do this by adding WITH <http://vitro.mannlib.cornell.edu/default/vitro-kb-2> to the top of the query, but looking at my own  code I see that I actually use the explicit form, e.g.

 

DELETE {

  GRAPH <http://vitro.mannlib.cornell.edu/default/vitro-kb-2> { <uri:something> ?p ?o }

} WHERE {

  GRAPH <http://vitro.mannlib.cornell.edu/default/vitro-kb-2> { <uri:something> ?p ?o }

}

 

Brian

To unsubscribe from this group and stop receiving emails from it, send an email to vivo-tech+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vivo-tech/97bd557c-d387-44c1-a45d-e700803d4405%40googlegroups.com.

J. Dornbusch

unread,
Apr 9, 2020, 5:00:30 AM4/9/20
to VIVO Tech
Hi Brian

Unfortunately, even with your explicit syntax, Vivo API keeps answering "<H1>400 No 'update' parameter.</H1>", message whose meaning is not clear to me

DELETE {
          GRAPH <http://vitro.mannlib.cornell.edu/default/vitro-kb-2> { <http://data.ehess.fr/individual/xxxxxxxxxx> ?p ?o }
        } WHERE {      
        GRAPH <http://vitro.mannlib.cornell.edu/default/vitro-kb-2> { <http://data.ehess.fr/individual/xxxxxxxxxx> ?p ?o }
        }

I also upgraded my Sparql client to Sparql 1.1 by passing the explicit "protocol" option (which defaults to 1.0). By looking into the code I can see that it only sets the "content type" HTTP header to "application/sparql-query".

Without results...


Le jeudi 9 avril 2020 09:32:22 UTC+2, Brian Lowe a écrit :

Hi Joachim,

 

Not sure what might have happened with your initial CONSTRUCT-based deletion.  The usual culprit when statements with literal values fail to delete is a character encoding mismatch somewhere between client and VIVO or VIVO and triple store, but the literals you show seem to include only ASCII characters where this wouldn’t likely be the issue.

 

I have used DELETE WHERE without problems.  One thing I would double check is that you’re explicitly specifying the graph to query and modify, in this case kb-2.  You should be able to do this by adding WITH <http://vitro.mannlib.cornell.edu/default/vitro-kb-2> to the top of the query, but looking at my own  code I see that I actually use the explicit form, e.g.

 

DELETE {

  GRAPH <http://vitro.mannlib.cornell.edu/default/vitro-kb-2> { <uri:something> ?p ?o }

} WHERE {

  GRAPH <http://vitro.mannlib.cornell.edu/default/vitro-kb-2> { <uri:something> ?p ?o }

}

 

Brian

 

From: vivo...@googlegroups.com <vivo...@googlegroups.com> On Behalf Of J. Dornbusch
Sent: Thursday, April 9, 2020 9:13 AM
To: VIVO Tech <vivo...@googlegroups.com>
Subject: Re: [vivo-tech] How to remove people from Vivo

 

Hi Benjamin

 

Following your advice I have written custom Sparql CONSTRUCT requests for the removal of people. It works well except that a few labels remain on "ghost" objects.

 

---------------------------------------------------------------------------------------------------------------------------------------------
| pred                                         | obj                                | graph                                                 |
=============================================================================================================================================
| <http://www.w3.org/2000/01/rdf-schema#label> | "Research professor"@en            | <http://vitro.mannlib.cornell.edu/default/vitro-kb-2> |
---------------------------------------------------------------------------------------------------------------------------------------------

I tried to rebuild the "label" statements provided by the Sparql CONSTRUCT query.

But whatever I send to DELETE DATA through my Sparql client (Ruby)  has no effect on those labels :

 

Brian Lowe

unread,
Apr 9, 2020, 5:22:59 AM4/9/20
to vivo...@googlegroups.com

Interesting.  So it’s not even getting to the point of trying to process your query, since it isn’t finding it in the first place.  Looking at the SparqlUpdateApiController I see that it’s expecting the update string to be sent as the value of the „update” parameter and throwing an exception if it’s not found.  That is, it appears that VIVO only supports the „update via URL-encoded POST” option described in the 1.1 spec https://www.w3.org/TR/sparql11-protocol/#update-operation and not the second „update via POST directly” option.  The former (application/x-www-form-urlencoded with explicit update parameter) is the only way I’ve ever done it.

 

First, however, are you sure your client is even trying to do an update rather than a query?  The content type for direct POST updates is listed as „application/sparql-update”, not „application/sparql-query".

To unsubscribe from this group and stop receiving emails from it, send an email to vivo-tech+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vivo-tech/f8ad236b-2f81-411b-a0f1-14511b66c977%40googlegroups.com.

Gross, Benjamin

unread,
Apr 9, 2020, 9:20:39 AM4/9/20
to vivo...@googlegroups.com
Hi Joachim and Brian,

VIVO’s wrapper around SPARQL update requires you to pass the delete command as a value attached to the ‘update’ key. Here’s the documentation:

This example removes the modified statement.

 curl -i -d 'email=test...@mydomain.edu' -d 'password=Password' -d '@delete.sparql' 'http://localhost:8080/vivo/api/sparqlUpdate'
delete.sparql
update=DELETE DATA {
      <http://test.domain/ns#book1>
          <http://purl.org/dc/elements/1.1/title>
          "Design Patterns" .
    }
}

If you’re using a client I’m guessing it’s not building exactly what VIVO is expecting, which is the SPARQL update command sent as part of a POST parameter called ‘update’. 

Here’s what that looks like in Postman:

Benjamin

_____________________________
Benjamin Gross
VIVO Product Manager

Web of Science Group | webofsciencegroup.com
Reply all
Reply to author
Forward
0 new messages