Get resource's graph version

[gfoo]

As discussed long time ago, we have to provide to the end users of LL a way to manage a draft version of a resource which is different of the valid version publicly available. Sometimes users can decide to tranform the draft version into the valid version.

A first naive approch is to maintain two resources, quite easy but tricky when I have to copy the draft version and its related resources into the valid version (yes, copy, because I want to keep the same IRI for the valid version!)

But if I store the validation date I could the get the valid version of a resource just by using ?version=TIMESTAMP on the same resource, the last version being the draft version, and the valid version, the resource at TIMESTAMP. So we could have a scenario like that:

As you can see the graph data changes over time and my questions are:

• if I request the Person1 and its related resources at Date2, will I have the the graph of Date2 box?
• is the ?version=TIMESTAMP facility accessible with gravsearch?

[benjamingeer]

if I request the Person1 and its related resources at Date2, will I have the the graph of Date2 box?

To get this graph, you will need to make more than one request.

If you request Person1 using the route Get a Full Representation of a Version of a Resource by IRI, specifying Date2, and if Person1 had a link to Position1 at that time, and if Position1 has not been deleted since then, the response will include a knora-api:LinkValue containing the metadata of Position1. To get the values of Position1, you will need to make another request, specifying the same timestamp.

is the ?version=TIMESTAMP facility accessible with gravsearch?

Not currently. Technically it could be done, but the necessary SPARQL would be involve a lot more work for the triplestore, and I suspect that this would make it a lot slower than a normal Gravsearch query. I would also like to try to avoid adding more complexity to the Gravsearch implementation unless it's really necessary.

Here's my suggestion: just do the full request for Person1 at TIMESTAMP, and display only the metadata for Person2 and Position1. Then if the user clicks for more information, you can get Person2 and/or Position1 at TIMESTAMP.

[gfoo]

@benjamingeer need some advice please

Context: we have to provide a way to edit a draft version of a resource (i.e.: the current Resource) and stamp in the past the version of the resource considered as valid to publish it on a web site

if Person1 had a link to Position1 at that time, and if Position1 has not been deleted since then, the response will include a knora-api:LinkValue containing the metadata of Position1

does it mean that I cannot in fact get a graph of the past? We cannot have a deleted resource which was available in the past while the resource is just mark as deleted... just to know :)

Because the only other way to implement the feature I'm talking about in this issue is to maintain two graphs, valid and current, and sometime copy the current into the valid (wee need to keep the same IRI this why I have to copy)

[benjamingeer]

With a timestamp, you can get one resource as it was in the past. If you want a graph, you can follow the links and request the linked resources with the same timestamp. You could store the timestamps of “draft” and “valid” in TimeValues.

[gfoo]

With a timestamp, you can get one resource as it was in the past. If you want a graph, you can follow the links and request the linked resources with the same timestamp. You could store the timestamps of “draft” and “valid” in TimeValues.

yep, I done that, works fine, but my question is about resource deleted.

[gfoo]

resource deleted.

but of course not deleted in the past. I cannot get it with a timestamp.

[benjamingeer]

Once a resource has been marked as deleted, it’s not accessible at all anymore. If you delete something, it’s because you don’t want people to use it anymore. Therefore they shouldn’t be able to continue using it by querying it with a timestamp.

We plan to add a feature allowing you to copy the contents of a deleted resource into a new resource with a new IRI.

Perhaps marking resources as deleted isn’t really what you want to be doing.

[gfoo]

Perhaps marking resources as deleted isn’t really what you want to be doing.

Good point, I should just delete the link value and not the related resource too, but in this case I will have many kind of orphan's resources from our model point of view.

We plan to add a feature allowing you to copy the contents of a deleted resource into a new resource with a new IRI.

I don't think that's useful for us, we just want to show and not maintain the past. But saying that, I remember that we want to query the past as well... but this is an another problem!

Maybe maintain two graphs would be a better solution, the last problem is to keep a constant IRI for the valid resource, would it be so weird to set the IRI of a resource ? ;-)

Many thanks !

[benjamingeer]

I think things could get very confusing if you could change the IRI of an existing resource. How about maintaining another resource with a link to the valid resource?

[benjamingeer]

To avoid having orphaned resources, you could add your own boolean flag to mark them as “obsolete” or something like that.