You can use sparql update to drop the graph. That should remove them. From: [email protected] [mailto:[email protected]] On Behalf Of Robert Del Toro Jr. Sent: Thursday, November 19, 2015 8:03 PM To: MarkLogic Developer Discussion <[email protected]> Subject: Re: [MarkLogic Dev General] Managed vs Unmanaged Triples
I actually tried 'xdmp:collection-delete(sem:default-graph-iri())' yesterday and my triples are still there. Robert On Thu, Nov 19, 2015 at 12:07 AM Geert Josten <[email protected]<mailto:[email protected]>> wrote: There are other ways to find your triple data. Managed triples are always stored as XML documents with sem:triples as root element. So you could use that. They are also by default stored in a particular collection called http://marklogic.com/semantics#default-graph. You could just do an xdmp:collection-delete on that.. Kind regards, Geert From: <[email protected]<mailto:[email protected]>> on behalf of "Robert Del Toro Jr." <[email protected]<mailto:[email protected]>> Reply-To: MarkLogic Developer Discussion <[email protected]<mailto:[email protected]>> Date: Thursday, November 19, 2015 at 7:47 AM To: MarkLogic Developer Discussion <[email protected]<mailto:[email protected]>> Subject: Re: [MarkLogic Dev General] Managed vs Unmanaged Triples Thank you for your help, it's starting to make much more sense now. I never thought of putting the triples in the document properties. That worked well and now I don't have to remove therm when serving the document. However, I ran into a new problem. I did a SPARQL query and found my triples, which most were the ones I embedded in my document, but there was also a few others that I guess somehow ended up in the database. (This is all fairly new for me and I probably put them there at some point.) I'm assuming they are managed triples, I don't even know how to check. I tried to just delete them using: for $triple in $triples return (sem:database-nodes($triple) ! xdmp:node-delete(.)) I verified that $triples did hold all the triples that I wanted deleted, but nothing happens when I run this. When I broke it down, I found that 'sem:database-nodes($triple)' returns null even though $triple seems to be a valid triple. Someone online suggested using sem:database-nodes($triple, 'all') but that did not change anything. My triples are just hung up in limbo somewhere. The MarkLogic docs are not much help, I really feel like I'm missing docs because I can't seem to make sense of it. Robert On Wed, Nov 18, 2015, 10:22 AM Geert Josten <[email protected]<mailto:[email protected]>> wrote: Managed means they are stored/updated in MarkLogic automatically for you. Unmanaged means you have to handle that yourself. If you just insert RDF data, you end up with managed triples automatically. Same if you use SPARQL update. So that is just more practical in that sense. In other words, it makes most sense if you use MarkLogic as a plain triple store, or have no reason to embed triples in documents. To use documents and triples separately, just load the triples and the documents separately, and maybe just have extra triples that have subject or object value matching document uris to make links between the two worlds. Regarding ’triples’, that wrapper has no real meaning for MarkLogic, but it can be useful to bundle triples. It is used in managed triples documents as well, and can also be useful to put annotations on. You could for instance add a start-date and a end-date property on triples, and use that to get temporal triples. My best advice is to put triples in document properties. That means serializing them to XML first, but that is just a minor detail for MarkLogic. Even if you use DLS, you can still do direct updates on both documents, and properties. DLS is just a library to help you with versioning, it is not enforced rigidly. Though you probably want to provide some abstraction to make sure people do their updates correctly.. Hope that helps! Kind regards, Geert From: <[email protected]<mailto:[email protected]>> on behalf of "Robert Del Toro Jr." <[email protected]<mailto:[email protected]>> Reply-To: MarkLogic Developer Discussion <[email protected]<mailto:[email protected]>> Date: Wednesday, November 18, 2015 at 1:32 PM To: MarkLogic Developer Discussion <[email protected]<mailto:[email protected]>> Subject: Re: [MarkLogic Dev General] Managed vs Unmanaged Triples "If you are only interested in running SPARQL, nor want to annotate triples, using managed triples makes most sense." Why does it make the most sense? What is the advantage of doing it this way? "If you are using document data as well, then you could still consider not embedding them in the docs." How do I include document data without embedding the triple in a document? "A second option could be to store the triples in document properties, instead of the body. Consider using a triples property that has an array-node with triple objects." I did notice before I went to bed last night that the example of embedded triples in an xml doc on the MarkLogic documents was displayed inside a 'triples' object. I guess I haven't really found a strong advantage to using managed triples, which it seems like there should be (why do they call them managed anyway?), but I'm still not sure that I like that I have to strip my triples out of my document every time so the end user does not see them or that I have to update the document just to update the triple (I wanted to use Document Library Services to store changes to documents, but I did not want to store a new version every time a triple was added, edited, or deleted so the embedded triples seem like it will take more code to do that). On Wed, Nov 18, 2015, 3:35 AM Geert Josten <[email protected]<mailto:[email protected]>> wrote: Hi Robert, If you are only interested in running SPARQL, nor want to annotate triples, using managed triples makes most sense. If you are using document data as well, then you could still consider not embedding them in the docs. A second option could be to store the triples in document properties, instead of the body. I don’t think there are performance implications. The triple index will be equally fast, and I have not heard that ingest speed of the triples will be different because of this. I think it mostly comes down to what helps your application best, which solution to select. Regarding node-replace, that sounds like you are working with triple data embedded in json. Consider using a triples property that has an array-node with triple objects.. Kind regards, Geert From: <[email protected]<mailto:[email protected]>> on behalf of "Robert Del Toro Jr." <[email protected]<mailto:[email protected]>> Reply-To: MarkLogic Developer Discussion <[email protected]<mailto:[email protected]>> Date: Wednesday, November 18, 2015 at 7:21 AM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: [MarkLogic Dev General] Managed vs Unmanaged Triples Could someone please explain the pros and cons of using managed vs unmanaged triples? I understand that with managed triples, I can update or delete the triple without having to update the document, and with unmanaged triples I can include extra information that I could then search with, however, when trying to use triples stored in my documents I seem to run into complications. For instance, when I try to read my document from an API, my triples come with it. So in order to ensure that the user does not have access to the triples, I have to use a transform with every request to remove the triples. Also, when trying to update a document with more than one embedded triple using 'xdmp:node-replace', I get the error 'XDMP-CHILDDUPNAME: Object nodes cannot have two children with the same name'. I'm assuming because I have multiple nodes with the name 'triple'. Since using managed triples removes the ability to add meta-data to the triples, what are the advantages? (Speed?) Robert _______________________________________________ General mailing list [email protected]<mailto:[email protected]> Manage your subscription at: http://developer.marklogic.com/mailman/listinfo/general _______________________________________________ General mailing list [email protected]<mailto:[email protected]> Manage your subscription at: http://developer.marklogic.com/mailman/listinfo/general _______________________________________________ General mailing list [email protected]<mailto:[email protected]> Manage your subscription at: http://developer.marklogic.com/mailman/listinfo/general
_______________________________________________ General mailing list [email protected] Manage your subscription at: http://developer.marklogic.com/mailman/listinfo/general
