--- Comment #22 from David Cook <[hidden email]> ---
(In reply to Mirko Tietgen from comment #21)
> From this comment by David on bug 10662 I take we need 1.018 anyway and
> the version in Stretch is not enough for all enhancements.
> It should pass the test for this patch, but we require a higher version for
> the harvesting client.
> David, can you confirm that is correct?
>  https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10662#c128
It seems like the dependency isn't specified anywhere here. I think maybe I
just did that for bug #10662?
For bug #18713, version 1.015 should be enough (now that I've reviewed the
versions more thoroughly again).
However, for bug #10662, we'll need version 1.017 or 1.018, since that bug does
bulk SPARQL operations and older versions like 1.015 don't work for that.
--- Comment #25 from David Cook <[hidden email]> ---
(In reply to Mirko Tietgen from comment #24)
> (In reply to David Cook from comment #23)
> > Or maybe I added the dependency to #18585 ...
> I'd say you either could set this bug to 'depends on' one of the bugs that
> have the dependency declared, or you also add it for this one.
What |Removed |Added
Status|Signed Off |Needs Signoff
CC| |[hidden email]
--- Comment #32 from Katrin Fischer <[hidden email]> ---
(In reply to David Cook from comment #26)
> After gaining more experience with RDF and triplestores, I'm not really
> happy with this one anymore.
> This functionality should probably be moved into a Koha::RDF::Triplestore
> module, as it's very triplestore specific... or maybe Koha::RDF::Model...
> since you could use other non-triplestore models.
> But there's other things that can be done in Koha::RDF that don't need to
> relate to models/triplestores...
>For what it's worth, I'm no longer convinced what I have here is the best way >forward, but I suppose it's better than nothing.
Those comments make me doubt that we should put more work into this. I'd really
like to get more opinions on this. I am asking for a second sign-off, also to
widen the audience on this bug beyond the QA team.
--- Comment #33 from David Cook <[hidden email]> ---
(In reply to Katrin Fischer from comment #32)
> Those comments make me doubt that we should put more work into this. I'd
> really like to get more opinions on this. I am asking for a second sign-off,
> also to widen the audience on this bug beyond the QA team.
As the author of the patch, I'd say it's probably worth pausing for the time
I think our next priority should be changing biblio_metadata.marcflavour to
something like biblio_metadata.schema (Tomas and I have talked about this
Then the next step would be to store RDFXML in biblio_metadata.metadata with a
biblio_metadata.format of "rdfxml" and a schema like "BIBFRAME".
The next logical step would probably be to generate RDF from MARC, so that 1
"bibliographic record" can have 2 different metadata records.
After that, we could focus on allowing Koha to use RDF (or any non-MARC
metadata really). Practically, this might mean introducing a Koha intermediate
metadata format which maps to/from other metadata formats.
RDF itself isn't necessarily that hard to work with. RDFXML is awful to look at
in comparison to Turtle or N3, but it's machine readable and easy enough to
work at after it's parsed into triples in Perl.
However, "Linked Data" is difficult. When RDF objects are links to external
objects, things get tricky. However, I have yet to find a RDF system that
handles perfectly Linked Data.
Fedora Commons 4.x uses RDF natively but it doesn't have any "Linked Data"
handling. You can have an external URI as an object, but it won't do anything
special. That'll be up to the application one level higher from Fedora. (I
haven't worked with Samvera or Hydra or Fez or anything like that.)
IIIF is a RDF metadata schema that mostly embeds literal values although some
objects can be resolvable URIs. I don't think anyone does that in practice