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]>
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]> on behalf of "Robert Del
> Toro Jr." <[email protected]>
> Reply-To: MarkLogic Developer Discussion <[email protected]>
> Date: Thursday, November 19, 2015 at 7:47 AM
>
> To: MarkLogic Developer Discussion <[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]>
> 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]> on behalf of "Robert Del
>> Toro Jr." <[email protected]>
>> Reply-To: MarkLogic Developer Discussion <[email protected]
>> >
>> Date: Wednesday, November 18, 2015 at 1:32 PM
>> To: MarkLogic Developer Discussion <[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]>
>> 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]> on behalf of "Robert
>>> Del Toro Jr." <[email protected]>
>>> Reply-To: MarkLogic Developer Discussion <
>>> [email protected]>
>>> Date: Wednesday, November 18, 2015 at 7:21 AM
>>> To: "[email protected]" <[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]
>>> 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
>>
> _______________________________________________
> General mailing list
> [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

Reply via email to