Log of the #duraspace-ff channel on chat.freenode.net

Using timezone: Eastern Standard Time
* edInCo leaves01:46
* edInCo joins08:27
* fasseg joins09:07
I implemented one out of three APIs for SCAPE on top of Fedora 4 using drop-in jars for additional http endpoints, and it worked like a charm: https://github.com/openplanets/scape-fcrepo4-planmanagement09:09
* ajs6f joins10:01
fasseg: Have you actually loaded part of the SCAPE material into that cluster?
<fasseg>Not real material, I created a TB of random data and ingested in on 15 nodes
<ajs6f>All: FCREPO3 committers' call at 11?10:02
fasseg: Oh, still, that's super-cool that you got part of the API up.
<fasseg>this was really easy, hardest part was to get a bit more familiar with SPARQL10:03
I cant believe there's no UPDATE in there
and deleting a triple was actually harder than I thought, since I was confused by the internal subject uris starting with info:fedora/objects....10:04
<ajs6f>A) We should be offering Sparql update at per-resource endpoints… is that not useful?
B) I don't think those URIs should be being exposed by now… barmintor did a lot of work to see that they aren't...10:05
<fasseg>Im not using the fcrepo rest api
<ajs6f>OH!
Are you wiring directly against the repo?
<fasseg>im using objects/datastreamservice
<cbeer>ajs6f: but there is no "change value X to Y" in SPARQL-Update
<fasseg>right
<cbeer>just delete this, add that.
<ajs6f>cbeer:/fasseg: Oh, I see. Actually, you could use reification for that purpose… :)
<fasseg>errr elaborate pls, I have no Idea what you are talking about10:06
<cbeer>ajs6f: https://wiki.duraspace.org/display/FF/Object+properties+and+SPARQL-UPDATE
i documented the update pattern there
<ajs6f>fasseg: Using DatastreamService, you should be able to add back in barmintor's special sauce to "referencable-ify" your URIs.10:07
barmintor/cbeer: What's the name of that class?
<cbeer>ajs6f: GraphSubjects
<ajs6f>HttpGraphSubjects?
<cbeer>yes
<fasseg>right but then the @Path annotation on the Resource has to match the URI of the object which is not true in the SCAPE case
<ajs6f>fasseg: http://en.wikipedia.org/wiki/Reification_(computer_science)#RDF_and_OWL .
You can address a given triple. To delete/recreate it atomically.10:08
<fasseg>the path is /scape/plan/<id> while the Path of the Node is objects/scape/plans/<id>
<ajs6f>But it's a tractability nightmare.
The "path of the node" I get, but what is the "path"? The URI in the SCAPE API?10:09
<fasseg>So I was just using the updateProperties(String) method and created the subjects myself
from the @Path annotation10:10
<ajs6f>Hm. Maybe we need to expand on barmintor's work for those (like fasseg) who want control over external URIs, but aren't using the HTTP API.
Something in kernel to translate.
<fasseg>and HttpGraphSubjects uses the UriInfo's path...10:11
a translator would be nice
<ajs6f>Right. But am I right in thinking that HttpGraphSubjects impls GraphSubjects (in kernel)?
You could do another impl of GraphSubjects to your own design.10:12
(Launching Eclipse...)
<cbeer>yes, you got it.
<ajs6f>Right. So we do have the opportunity there.10:13
fasseg: Instead of working directly with the @Path, you could impl ScapeGraphSubjects or the like.
<cbeer>whether it's a good idea to take it is probably open for debate.
<fasseg>It would be nice to have something like GraphSubject.newInstance(String origPrefix, String translatedPrefix)
<ajs6f>cbeer: Really? I thought this was the pattern we wanted?
Different people with different ideas about external URIs get to choose for their own...10:14
fasseg: that's GraphSubject.getGraphSubject(), I think. IOW, you define the mapping between internal IDs and external IDs. If your mapping is similar to HttpGraphSubjects, mabe you can subclass?10:17
<fasseg>Oh didn't see that let me check
<ajs6f>It's the backwards of GraphSubjects.getNodeFromGraphSubject().10:18
<fasseg>but that would have to be implemented as well... No simple call to a method to get a new Instance of GraphSubject10:19
<ajs6f>Because GraphSubject isn't a concrete class.
A new instance makes now sense.
The mapping is arbitrary. It's not a matter of a semi-defined string manipulation.
I could (theoretically) look up the mapping in a database.10:20
<fasseg>right but I though you were refereing to a static factory method on an abstract calss
<ajs6f>Or in the JCR itself.
<fasseg>Ill have a look at it and come up with a suggestion....
<ajs6f>No, sorry. interface GraphSubjects. You write the impl. barmintor wrote the impl for the HTTP API.
You write the impl for Scape's API.
:)
<fasseg>and IMHO it would make sense to provide a simple factory method for simple path mappings10:21
<ajs6f>Sounds like a helper class alongside GraphSubjects.
<fasseg>so that third party developers wont have to implemtn a class for each of thier use cases
<cbeer>sorry, that does what?10:22
<ajs6f>Which reminds me to whine about us making helper classes abstract. The best people all make them concrete with private constructors.
<fasseg>and I can see that mapping in between URIs and Node's paths is a common use-case
<ajs6f>cbeer: That does a very simple "add or subtract a prefix" mapping.
<fasseg>so final rather than abstract?
<cbeer>https://github.com/futures/fcrepo4/blob/master/fcrepo-kernel/src/main/java/org/fcrepo/rdf/impl/DefaultGraphSubjects.java10:23
that adds and subtracts info:fedora
<ajs6f>fasseg: Right, final with private constructor. I even make the constructor throw an exception to make it really obvious that this is not an instantiable class.
<cbeer>no reason it couldn't be made even more abstract
<ajs6f>cbeer: Right. Maybe DefaultGraphSubjects just needs to be a little more flexible… and that would make fasseg's life easier. :)10:24
<fasseg>cbeer: right im using that one for the delete I think, but I still have to add the http://local... part for the response then....
<cbeer>and https://github.com/futures/fcrepo4/blob/master/fcrepo-http-commons/src/main/java/org/fcrepo/api/rdf/HttpGraphSubjects.java takes the JAX-RS class you want to build on.. but it sounds like fasseg needs to do more serious munging
<fasseg>cbeer: right because that one taked the path directly from the @Path annotation and that does not match the node's path in my use-case
<ajs6f>cbeer/faseg: Yeah. I think we have a good contract, and we just want to make sure we have nice supporting tools so that people can fulfill the contract without extra work.
<cbeer>i guess i don't know what tool we'd provide him that's actually generally useful. it sounds like fasseg is doing some SCAPE-specific URI building with SCAPE-specific path munging10:27
<ajs6f>Sounds like he's asking for prefix-manipulation tools.10:29
If it's just prefixes at stake, I think we could do something. More than that gets too use case specific.10:30
fasseg?
<cbeer>"fasseg: the path is /scape/plan/<id> while the Path of the Node is objects/scape/plans/<id>"
unless that was a typo, there's some node-path munging going on too10:31
<ajs6f>but there's no need to put scape in the JCR path unless these repos support more than scape.
which would make /scape/plan/* <=> objects/plan/*10:32
ish
Part of this is about selecting a good repo structure to make the paths useful.
<cbeer>true, but if that was the case, fasseg could use the HttpGraphSubjects API now10:33
<fasseg>sorry
<cbeer>it's not bound to the fcrepo-http-api
<ajs6f>E.g., if there is more than SCAPE going on in these repos, fasseg could use workspaces for multitenency instead of paths.
He's not using the HTTP API at all. Right, fasseg?
(which doesn't mean he couldn't use HttpGraphSubjects, of course.)10:34
* eddies leaves
<fasseg>right: I have to translate from http://localhost:8080/fcrepo/rest/scape/plan/plan-1 to info:fedora/objects/plans/plan-1 and vice versa
no HTTP API just the services
<ajs6f>fasseg: You _would_ have to do that, if you used HttpGraphSubjects.
<fasseg>I could use HttpGraphSubjects but I would have to implement it first that's my whole point!10:35
<ajs6f>The essential task is to get from info:fedora/objects/plans/plan-1 to whatever SCAPE shows in its API.
HttpGraphSubjects _is_ an impl of GrpahSubjects.
<fasseg>It's much easier to just create the subjects yourself if there is no helper method
<ajs6f>fasseg: Would prefix manipulation be enough?
<fasseg>but the paths differ one time it /scape/plan/plan-1 and in the repo it 's just /plans/plan-110:36
<cbeer>fasseg: why not make the JCR paths align better with the URI?
<ajs6f>So if you stopped using /plans/plan-1 and used /plan/plan-1, then adding a prefix would be enough.
cbeer: +1
<fasseg>cbeer: because I wanna organize the data in fcrepo so that you can see all you stuff on the top level using the rest api10:37
<ajs6f>fasseg: So you want to provide both the SCAPE and Fedora HTTP APis?
<fasseg>so the top level should have 3 different folders
yes
<ajs6f>I think we're still okay.
You don't have to put objects in /objects.10:38
<fasseg>but the spec says "plan" and it would make sense to call the folder "plans" using a plural s
that's not that an uncommon use case is it? and we dont wanna hamper the third party developers we wanna support them....10:39
<ajs6f>fasseg: yes, but grammar doesn't trump code. :)
I'm not sure how much reponsibility we can take for mapping identifiers over which we intentionally have no remit10:40
<fasseg>im not talking about grammar im talking about providing the tools for common use cases
<ajs6f>Helper methods, sure.
Actually, it makes more sense (to me) to say "plan".10:41
But this is getting into the difference between English and REST. :)
fasseg: Can you describe what you would want in helper methods to do your mapping easily?
Beyond prefix swapping?10:42
<fasseg>sorry call brb
<ajs6f>cbeer: I can see this going too far into a whole templating regime for ID mapping.
Or maybe that's not too far?
I dunno.
<fasseg>ajs6f: im just interested in prefix mapping10:43
<ajs6f>Okay. I think it's pretty reasonable to have a helper class alongside GraphSubjects with that in it. cbeer?10:44
<fasseg>independent of the UriInfo and therefore the @path annotation
<ajs6f>Just string manip.
Like String.replace(), but specific to prefixes? That's a one-liner.10:45
<fasseg>right it is trivial, that's why I didnt use GraphSubjects but build the subjects' uris myself10:46
<ajs6f>So you just want a little more richness in the API to make life easier for future fassegs? :)
We could include a config-able PrefixMappingGraphSubjects.10:47
BeanFactory.
<fasseg>GraphSubjects.create(String prefix) would be enough for me I think but let me check the code10:48
<ajs6f>It wouldn't be on GraphSubjects. That's the contract.
No impl there.
Maybe a PrefixMappingGraphSubjects that HttpGraphSubjects extends.10:49
No mixins in Java. :)
I guess GraphSubjects could be an abstract class, but that feels dirty.10:50
<fasseg>hehe sorry confusion there: I normally call my interfaces GraphSubject and my Factory classes GraphSubjects, factories are distinguised by a plural s
<ajs6f>M. I wonder if that's a common convention we should follow.
<fasseg>So iwas talking about GraphSubjectsFactory.create(String prefix)
ajs6f: it's from Josh Bloch book10:51
effective java thingie
<ajs6f>So maybe a "convenience factory" PrefixMappingGraphSubjectFactory(String prefixToRemove, String prefixToAdd) which creates GraphSubjects impls of the kind fasseg wants?10:52
Or just a configurable convenience impl? (Which would make the wiring cleaner.)
<fasseg>id rather see factories than more impls10:53
and there could be a builder interface for more complex GraphSubjects if the need comes up...10:54
<ajs6f>But we're going to have to wire them up. More people will use wiring than programmatic use, I think.
A builder API is a nice idea, but that's a good bit of work, I think.10:55
<fasseg>that's a good point
<ajs6f>You can wire factories. It's just a little more verbose and less clear.
<fasseg>with annotations?
<ajs6f>Eh?
<fasseg>you have to declare them in a bean xml then....
<ajs6f>Yeah, exactly.10:56
Ah, this is where CDI looks better and better.
<fasseg>so not just @Autowired...
righ
<ajs6f>@Autowired is fine, as long as you want to write the XML to fulfill your needs.
<fasseg>right but at the momement it's enough to just @Autowire if it's a component service or anything, but with a factory you'll ylways need the xml, thats my point10:57
<ajs6f>Yes. But with a straight impl, you'll still need to wire it in XML. (So as to choose which impl you want to use.)10:59
<fasseg>and im not sure how one would use a builder in a spring bean factory thingie
<ajs6f>(And to configure it, if you need it.)
Yeah, I've never tried to use a fluent builder in SPring XML. Can't imagine it looks very nice.
<fasseg>probably a lot of MethodInvocationBeans or sth11:00
<ajs6f>Going to hangout. all?11:01
* fasseg is not on this sprint11:02
but I got time
so if you want me to join
<ajs6f>Cool— I think this is techincally the fcrepo3 committers' call, but hey, anything goes...
<fasseg>oh right
<ajs6f>Release manager barmintor?
<barmintor>call time, cal time
be there in just a sec11:03
<ajs6f>Cool.
chris wilper: Chris Wilper <cwilper@gmail.com>11:11
<OLB>https://github.com/fcrepo/fcrepo/pull/13
ajs6f, fasseg ^^
* eddies joins11:21
* eddies leaves
* eddies joins
* kaarefc joins11:45
* edInCo leaves12:19
* ajs6f1 joins12:52
* ajs6f leaves
* ajs6f1 leaves12:54
* edInCo joins13:01
<cbeer>ok, got our marmotta snapshot release now14:16
i'll double check it works and then ship https://github.com/futures/fcrepo4/pull/99
* github-ff joins15:02
[fcrepo4] cbeer force-pushed ldpath from b025dd2 to c339e3e: http://git.io/K9x81w
fcrepo4/ldpath c339e3e Chris Beer: Fedora transformation service...
* github-ff leaves
* bljenkins leaves15:33
* bljenkins leaves23:03
* bljenkins joins23:07
* edInCo joins23:53

Generated by Sualtam