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

Reply via email to