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

Using timezone: Eastern Standard Time
* ksclarke leaves02:03
* Guest8123 leaves02:47
* ruebot leaves
* pmurray leaves
* pmurray joins03:00
* Guest8123 joins03:11
* ruebot joins
* Guest8123 leaves03:28
* ruebot leaves
* pmurray leaves
* Guest8123 joins03:32
* ruebot joins
* pmurray joins03:37
* Jotudin leaves05:53
* Jotudin joins
* f4jenkins leaves05:58
* f4jenkins joins
* MohamedAR joins08:03
<pivotal-bot____>Stefano Cossu added "Cannot create weakreference property without referenced node" https://www.pivotaltracker.com/story/show/8136484208:13
* awead joins09:12
<awoods>all: Jenkins is looking stronger than ever: http://jenkins.fcrepo.org/09:23
<pivotal-bot____>Andrew Woods accepted "Add RDF serializer to message consumer" https://www.pivotaltracker.com/story/show/8105351209:24
Andrew Woods accepted "Update dependencies" https://www.pivotaltracker.com/story/show/81068400
Andrew Woods accepted "Move DefaultIdentifierTranslator.java to tests" https://www.pivotaltracker.com/story/show/80923140
Andrew Woods accepted "Remove fcr:nodetypes POST" https://www.pivotaltracker.com/story/show/80574160
Andrew Woods accepted "Nested blank nodes aren't fully skolemized" https://www.pivotaltracker.com/story/show/81238280
Andrew Woods accepted "Verify fcrepo4 against real world RDF" https://www.pivotaltracker.com/story/show/81112310
Andrew Woods accepted "fcrepo-message-consumer build error messages" https://www.pivotaltracker.com/story/show/81198770
Andrew Woods accepted "Update <developers> section of fcrepo4.pom.xml" https://www.pivotaltracker.com/story/show/81241578
Andrew Woods accepted "fcrepo4 should not emit events with "fcr:content" references" https://www.pivotaltracker.com/story/show/81279166
Andrew Woods accepted "References to skolemized blank nodes (and any blank node tree that follows) should be embedded in responses " https://www.pivotaltracker.com/story/show/81245484
Andrew Woods accepted "Kill compiler warnings in kernel" https://www.pivotaltracker.com/story/show/81290082
Andrew Woods accepted "Support RDF language " https://www.pivotaltracker.com/story/show/81273072
Andrew Woods accepted "fcrepo-integration-ldp: Use maven.build-helper for port conflicts" https://www.pivotaltracker.com/story/show/8130797209:25
Andrew Woods accepted "Filter out root version from RDF" https://www.pivotaltracker.com/story/show/79460404
* github-ff joins09:39
[fcrepo4] awoods pushed 2 new commits to master: http://git.io/vQGjKg
fcrepo4/master 9fe97e3 Aaron Coburn: Changed JMS header prefix to org.fcrepo.jms. in order to provide compatibility with the STOMP protocol
fcrepo4/master 38760db Andrew Woods: Merge pull request #583 from acoburn/jms_headers...
* github-ff leaves
<pivotal-bot____>Esme Cowles added "Non-RDF resource properties should be visible on its description HTML page" https://www.pivotaltracker.com/story/show/8137050209:51
* travis-ci joins
fcrepo4/fcrepo4#2952 (master - 38760db : Andrew Woods): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/6460611415c4...38760db0757f
Build details : http://travis-ci.org/fcrepo4/fcrepo4/builds/38927912
* travis-ci leaves
<pivotal-bot____>Esme Cowles edited "Non-RDF resource properties should be visible on its description HTML page" https://www.pivotaltracker.com/story/show/81370502
<f4jenkins>Project fcrepo-message-consumer build #799: UNSTABLE in 5 min 58 sec: http://jenkins.fcrepo.org/job/fcrepo-message-consumer/799/09:55
* osmandin joins10:01
<pivotal-bot____>Osman Din started "Require version label" https://www.pivotaltracker.com/story/show/8101156810:02
Andrew Woods edited "Non-RDF resource properties should be visible on its description HTML page" https://www.pivotaltracker.com/story/show/8137050210:04
* github-ff joins10:14
[fcrepo4] escowles force-pushed link-to-ds-metadata from 04b5ece to 619b3dd: http://git.io/wQMOAw
fcrepo4/link-to-ds-metadata 9be09b8 Esmé Cowles: Linking to datastream fcr:metadata in HTML UI
fcrepo4/link-to-ds-metadata 619b3dd Esmé Cowles: Updating REST API to include children by default for HTML view
* github-ff leaves
<pivotal-bot____>Esme Cowles added comment: "I've updated this PR to make the REST API include the child resources by default, so the views can use them fo�" https://www.pivotaltracker.com/story/show/8095240810:15
Esme Cowles finished "Datastreams in HTML view should have /fcr:metadata" https://www.pivotaltracker.com/story/show/8095240810:16
Osman Din added comment: "https://github.com/fcrepo4/fcrepo4/pull/574" https://www.pivotaltracker.com/story/show/81011568
Osman Din finished "Require version label" https://www.pivotaltracker.com/story/show/81011568
* gregjansen leaves10:20
* ajs6f joins10:24
cbeer:http://alex.nederlof.com/blog/2013/07/28/caching-using-annotations-with-jersey/10:25
Not for today, but good to thin about.
think
* travis-ci joins10:26
fcrepo4/fcrepo4#2953 (link-to-ds-metadata - 619b3dd : Esmé Cowles): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/04b5ece66eea...619b3dd28b59
Build details : http://travis-ci.org/fcrepo4/fcrepo4/builds/38931275
* travis-ci leaves
* ksclarke joins10:27
<pivotal-bot____>Osman Din added comment: "@jaredwhiklo Following the above steps, I get only the usual "error converting name to string."" https://www.pivotaltracker.com/story/show/7884734810:35
Andrew Woods added comment: "@osmandin, the errors I see are as follows: ""11:04
1) In HTML UI, select "datastream"
- Leave "identifier" field bla�" https://www.pivotaltracker.com/story/show/78847348
* github-ff joins11:05
[fcrepo-message-consumer] awoods pushed 1 new commit to master: http://git.io/a8WjCw
fcrepo-message-consumer/master 8747087 Aaron Coburn: Use org.fcrepo.jms. as a header prefix rather than http://fedora.info/definitions/v4/repository#...
* github-ff leaves
* github-ff joins11:06
[fcrepo-message-consumer] awoods closed pull request #60: Use org.fcrepo.jms. as a header prefix (master...jms_headers) http://git.io/w_Vc_A
* github-ff leaves
<pivotal-bot____>Andrew Woods added comment: "Resolved with: ""
https://github.com/fcrepo4/fcrepo-message-consumer/commit/87470872fafde17ec422d8cd0abbaee3e88c�" https://www.pivotaltracker.com/story/show/81285766
Andrew Woods delivered "Update JMS message headers to support more protocols" https://www.pivotaltracker.com/story/show/8128576611:07
<f4jenkins>Yippee, build fixed!11:09
Project fcrepo-message-consumer build #801: FIXED in 3 min 40 sec: http://jenkins.fcrepo.org/job/fcrepo-message-consumer/801/
awoods: Use org.fcrepo.jms. as a header prefix rather than http://fedora.info/definitions/v4/repository#
<osmandin>awoods or anyone, for https://www.pivotaltracker.com/story/show/80555496, I plan to test the session timeout by creating a large number empty datastreams and then doing a GET for the triples.. do you think that's a good enough approach to test out the feature?11:12
<pivotal-bot____>feature: Test auto-session-logout with large response RDF (unstarted) / owner:
<awoods>osmandin: I think that is a good first step. I would also suggest keeping your (jetty:run) terminal open looking for I/O stack traces while using the HTML UI. I have not been able to create a repeatable scenario, but I have been seeing a lot of new stack traces that look to be a result of prematurely closed streams when navigating in the HTML UI.11:15
all: I need to step away for a moment... construction in the office.11:18
<osmandin>awoods: ok thx.. so far no stack trace, just the UI landing page is a bit sluggish
* nikhiltri joins11:39
* dwilcox joins11:43
* dwilcox leaves11:48
* gregjansen joins11:49
* jonroby joins11:51
<pivotal-bot____>Chris Beer added "Handle xsd:date datatype" https://www.pivotaltracker.com/story/show/8138061411:57
Chris Beer started "Handle xsd:date datatype" https://www.pivotaltracker.com/story/show/81380614
* awoods leaves12:00
<cbeer>ajs6f: ping?12:03
* awoods joins
<cbeer>or, escowles?12:06
<pivotal-bot____>Jared Whiklo added comment: "@osmandin This may have changed as I think I added this ticket prior to some pretty big changes by cbeer. I'l�" https://www.pivotaltracker.com/story/show/7884734812:12
<cbeer>jena--12:27
<pivotal-bot____>Chris Beer unstarted "Handle xsd:date datatype" https://www.pivotaltracker.com/story/show/8138061412:29
Chris Beer edited "How should we handle invalid RDF literal values?" https://www.pivotaltracker.com/story/show/8138061412:30
Chris Beer started "How should we handle invalid RDF literal values?" https://www.pivotaltracker.com/story/show/81380614
Chris Beer estimated "How should we handle invalid RDF literal values?" as 3 points https://www.pivotaltracker.com/story/show/81380614
Osman Din added comment: "As a first step, I was able to create 125k empty datastreams and GET all the triples back (response size: ~12mb,�" https://www.pivotaltracker.com/story/show/8055549612:32
Andrew Woods added comment: "@osmandin, are you using the REST-API directly or the HTML view?" https://www.pivotaltracker.com/story/show/8055549612:36
<jonroby>awoods: what was the name of that project you mentioned that might help springboard the PrincipalProviders work? sorry, I know you mentioned it twice, I never quite caught it.12:37
<pivotal-bot____>Osman Din added comment: "Both. All the triples show up using both curl and in the UI, but it does take a minute." https://www.pivotaltracker.com/story/show/8055549612:38
<awoods>jonroby: https://github.com/fcrepo4-labs/fcrepo-webapp-plus
<jonroby>awoods: thanks!
<pivotal-bot____>Andrew Woods started "Test auto-session-logout with large response RDF" https://www.pivotaltracker.com/story/show/8055549612:39
Andrew Woods added comment: "I would suggest continuing to poke around based on the http-api/session logout changes in the above commit lo�" https://www.pivotaltracker.com/story/show/8055549612:41
<osmandin>afk12:44
* github-ff joins12:54
[fcrepo4] awoods pushed 2 new commits to master: http://git.io/ih0qtA
fcrepo4/master 5074ed6 osmandin: Require version label
fcrepo4/master 33275b9 Andrew Woods: Merge pull request #574 from osmandin/81011568-PR...
* github-ff leaves
<pivotal-bot____>Andrew Woods delivered "Require version label" https://www.pivotaltracker.com/story/show/81011568
<ajs6f>cbeer: sorry, pong (should have afk'd)12:58
<cbeer>ajs6f: i've run into a new problem round-tripping RDF statements.
ajs6f: at the core of it, there are two problems:
ajs6f: 1) jena is (by default) vary lenient in coercing literal types. If it doesn't parse as a type, it treats it as a plain string with a type attribute12:59
<ajs6f>Ok.
But what is that tpe attribute?
<cbeer>ajs6f: and, 2) RDF types are way more expressive than JCR types; so, for xsd:date, Jena gives us a Calendar with an xsd:date type, and we store the calendar and lose any way to track precision.13:00
ajs6f: sorry, typed literals.
ajs6f: so, if you tell Jena, e.g.:
ajs6f: "2012-01-01T01:01:01Z"^^xsd:dateTime, it'll parse that into an XSDDateTime type and give us a Calendar13:01
ajs6f: if you give it: "2012"^^xsd:date (thanks MODS-RDF!), it'll parse that as a TypedLiteral of xsd:date and give us the string "2012" (because that doen't parse as an xsd:date)
so, jena isn't lossy, but we happily take Jena's down-converted values and store them.13:02
and in some cases, jena isn't lossy, but we downconvert them to store them in JCR.
ajs6f: i'm wondering if we're being too lenient.
ajs6f: and, then, what to do about xsd:date in particular.13:03
<pivotal-bot____>Andrew Woods added comment: "@nikhiltri, can you please rebase PR-484 on master? and update your PR." https://www.pivotaltracker.com/story/show/79207804
<ajs6f>cbeer: I'm sorry, but I just walked in the door with groceries. Can we put this off for a few minutes and maybe meet on Hangout? I'm getting the sense that there's an impedance mismatch between JCR and Jena/RDF (and I'm already wondering about what the possibility of OWL-based type systems might mean here, because OWL-compatibility is a good test of "you're doing RDF and you think you're doing it for the future, but are you really"13:06
<cbeer>ajs6f: no hurry.
<ajs6f>?) but I need to have a sense of context
to get a sense of the scope.
Okay.
I'll check in in a few.
* travis-ci joins13:07
fcrepo4/fcrepo4#2956 (master - 33275b9 : Andrew Woods): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/38760db0757f...33275b92324c
Build details : http://travis-ci.org/fcrepo4/fcrepo4/builds/38947559
* travis-ci leaves
* github-ff joins13:15
[fcrepo4] cbeer created lang-tag-literals (+1 new commit): http://git.io/Kcks6w
fcrepo4/lang-tag-literals aa20cf1 Chris Beer: Update graph tidying logic to support language-tagged literals
* github-ff leaves
<ajs6f>cbeer: hangout?13:23
<cbeer>ajs6f: give me a sec. i'm writing some integration tests to show what's going on.
<ajs6f>cbeer: np. ping me.
* travis-ci joins13:27
fcrepo4/fcrepo4#2957 (lang-tag-literals - aa20cf1 : Chris Beer): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/commit/aa20cf1ff085
Build details : http://travis-ci.org/fcrepo4/fcrepo4/builds/38949135
* travis-ci leaves
<cbeer>ajs6f: sorry, now it's taking me longer than i thought. had to figure out how to create a jcr repository without spring, and now i'm finding some (unrelated) bugs in our impl.13:44
<ajs6f>cbeer: those may be more important.
<cbeer>ajs6f: at least they're avoidable.
<ajs6f>cbeer: We can always meet two type systems of the expressivity of RDF and JCR losslessly. It just may be ugly and hell of a lot of work right before release.13:45
And we may chose not to do it.
hoose.
choose.
We may hoose not to do it, as well.
"hoose" should be a word.
<cbeer>ajs6f: i'm not even sure it's important to be perfect. good enough with well documented conditions (and deciding whether to be strict or lenient..)13:46
ajs6f: if the data is truly important, they can always use non-rdf sources
<ajs6f>cbeer: Yes, to both, although I'd rather not do that and then come back in three months and say, "Oh, you can do the easy thing now."13:47
But if that's what we do… so be it.
cbeer: It's not important to be perfect except insofar as perfect (in this case) supports transparent.13:48
Transparent is good.
<cbeer>ajs6f: huh. here's an interesting issue in the same vein.. JCR up-converts byte + int types to longs.13:49
at least it's not lossy, i suppose.
<ajs6f>cbeer: and we return them as such?
<cbeer>ajs6f: yeah, we tag 'em as xsd:long on the way out (because we can't know any better)13:50
<ajs6f>cbeer: Right. Well, as you say, it's not lossy, but I think you mean it's not lossy in the value space, which it isn't.
It is lossy in the lexical space.13:51
<cbeer>yes, of course.
<ajs6f>People expecting to get back the same type they persisted might be annoyed to find otherwise.
But this is pretty minor, when we think about the field of clients.
Dates are more worrisome.13:52
People use timestampts.
<pivotal-bot____>Esme Cowles added comment: "I've copied the JcrXml wiki page and modified to fit the RDF serializer: ""13:55
https://wiki.duraspace.org/display/F�" https://www.pivotaltracker.com/story/show/81154196
Esme Cowles finished "Document RDF Serializer" https://www.pivotaltracker.com/story/show/81154196
<cbeer>ajs6f: yep. and at least the byte/int/long thing are all #sameValueAs each other13:56
<ajs6f>cbeer: Yeah. That's not the worry here. Have you looked at the irc://irc.freenode.net:6667/#sameValueAs  question for dates? (I haven't.)13:58
Nice URL translation, Adium.
<cbeer>ajs6f: i haven't (but will in just a moment..), but I don't think they're the same. precision matters.14:00
<ajs6f>cbeer: Right. I think we may have to deal with the date thing, either by impl or by documentation.
escowles: You guys do RDF as far through the stack as anyone I know: would this be a problem for you?14:01
<escowles>ajs6f: i don't think so -- we usually have either 4-digit years or full iso8601 timestamps14:02
<cbeer>ajs6f: can you chime in on https://issues.apache.org/jira/browse/JENA-805?
ajs6f: i must not be clear enough about the problem
<ajs6f>escowles: Well, 4-digit years would come back as four-digit years. The difference between 4 and four is about as dangerous as the difference we're talking about.
cbeer: On my way.14:03
<escowles>if we put in a 4-digit year and get it back as a string, we'd still be able to deal with that
<cbeer>escowles: what type are you giving that literal?14:04
<escowles>right now, i don't think we are typing our dates
but if we wanted to type them, we could add -01-01 or -12-31 depending on the context if we had to14:05
so it would be a minor workaround to preserve the way we're using them now
<ajs6f>escowles: Minor, but gross. You'd be making assertions you knew to be more precise than true.14:09
<escowles>ajs6f: yep, it would be better to be able to do "2004"^^xsd:date of course14:10
<ajs6f>escowles: That points us back at impl'ing the RDF/XSD notion of dateTime in JCR. Which is another flavor of the lang tag question.14:11
<cbeer>(just a note that "2004"^^xsd:date is invalid)14:12
gYear is probably the right type
<ajs6f>cbeer: If we got gYear, what would we do with it in JCR?
<cbeer>ajs6f: right. it's back into the same bucket of unmappables.
ajs6f: actually, if we decided we didn't care about fcr:sparql, we could stash the type as a suffix in a string-type field.14:13
maybe that'd be the right thing to do.
<ajs6f>cbeer: Well, "things we haven't yet mapped and really kind of don't want to because it's already October and we need to release and, and and…"
cbeer: If we have to do the impl, we should have a good pattern in pocket.14:14
* github-ff joins14:15
[fcrepo4] cbeer created cbeer-rdf-types (+3 new commits): http://git.io/quEyaA
fcrepo4/cbeer-rdf-types 00d7857 Chris Beer: Update value converter to short-circuit in the most common case
fcrepo4/cbeer-rdf-types 78610a4 Chris Beer: Add examples of failing round-trips
fcrepo4/cbeer-rdf-types 8198fe8 Chris Beer: Add round-tripping integration tests for ValueFactory
* github-ff leaves
<ajs6f>cbeer: Crap, I forgot about Sparql.
cbeer/awoods/escowles/all: This is why indexing/search is _NOT_ a core functionality.14:16
<cbeer>ajs6f: i'm happy to keep forgetting about it. if it's really that important, they'll have an external store.
<ajs6f>cbeer++
I argued about this until I was blue in the face (which takes about thirty seconds, given my habits) in that December meeting several years ago, but "We _have_ to do some kind of search!"14:17
Yes, but we don't have to make it dependent on the core type system, which is what we did.
I'm getting tired of people who think that Fedora is DSpace/ContentDM/whatever: an unpackable Christmas gift box that will solve all your problems with durability and discovery and management, without you ever having to actually think about those things.14:19
I would love to just take the meat axe to fcr:sparql and do some docs on how to set up the external triplestore arrangements on which escowles and others have worked so hard and move on.14:20
* travis-ci joins
fcrepo4/fcrepo4#2958 (cbeer-rdf-types - 8198fe8 : Chris Beer): The build has errored.
Change view : https://github.com/fcrepo4/fcrepo4/compare/00d78574665b^...8198fe88998b
Build details : http://travis-ci.org/fcrepo4/fcrepo4/builds/38954227
* travis-ci leaves
<ajs6f>Some more docs, sorry, because it's already doc'd.14:21
cbeer: I'm getting the depressing sensation that we're going to get pushed towards a pattern where _any_ literal property gets stored as a node with metadata {value, lang, type}.14:23
<cbeer>ajs6f: i'm going to resist as long as possible. a type system within a type system makes me sad.14:26
ajs6f: and i'm happy to accept the up-conversions that preserve sameValueAs14:28
<ajs6f>cbeer: Yes, and it will _suck_ for readability or maintainability.
cbeer: yes, I don't thin anyone will complain about the numbers. It's the dates that nag at me.14:29
cbeer: But I hate to make a special case of them.
<cbeer>ajs6f: XSD beat you there. those g* types are pretty miserable.14:30
<ajs6f>cbeer: Yes, they are. Didn't that get inherited from some ISO thing?
The Marines leave no man behind. Does that mean we can't?14:31
* gregjansen leaves14:32
<cbeer>ajs6f: all these XSDanyURI, XSDtoken XSDName, etc are there to support RDFS and the like, right?14:35
<ajs6f>cbeer: The JCR date, it seems to me, has a value space into which any of the practical XSD types could map.
cbeer: Well, they certainly do, but I think they have more application...
<cbeer>ok. guess i'll write them out too.14:36
<ajs6f>cbeer: Can we just push anything that looks like a date into JCR date, then return JCR dates, and say, "Look, we're being at least as precise as you were."?
<cbeer>ajs6f: how do we know how precise the input was?
<ajs6f>cbeer: And the g* stuff goes awry, and no one cares.
cbeer: Damn.
cbeer: Wait, have we actually tried something like a pure year? Does JCR add false months and days and so forth, or does it just keep the years and return it?14:38
<cbeer>ajs6f: it depends how you tag it.
<ajs6f>cbeer: Tag it? Beyond the type itself? You mean how you offer a serialized form to be persisted?
<cbeer>ajs6f: if you tag a pure year as something syntactically invalid (xsd:date, xsd:dateTime), we don't coerce it correctly.14:39
ajs6f: if you tag it as gYear, Jena helpfully gives us a Calendar and we store it with full date precision.
but we lose the mask.
<ajs6f>cbeer: Which results in a wrong return when we give the value back.
Well, a too-precise return.
We map into the wrong value-space.14:40
Because Calendar isn't really right. Its value space is too fine-grained.
We need Jena to use something like "Year".
<pivotal-bot____>Andrew Woods added comment: "Adding a note the the main indexer page (https://wiki.duraspace.org/display/FF/Indexer+Configuration) detaili�" https://www.pivotaltracker.com/story/show/8115419614:42
<cbeer>https://gist.github.com/cbeer/7aa67e39a3a904d22450
* github-ff joins
[fcrepo4] cbeer force-pushed cbeer-rdf-types from 8198fe8 to 9a63db4: http://git.io/W7NFIQ
fcrepo4/cbeer-rdf-types 9a63db4 Chris Beer: Add round-tripping integration tests for ValueFactory
* github-ff leaves
<cbeer>https://github.com/fcrepo4/fcrepo4/commit/9a63db452f4edfb0bceda7343d60eaee73fbcf16#diff-5963d8e64520bac8632452710e2cf72eR10514:43
https://gist.github.com/cbeer/7aa67e39a3a904d22450
there's the scope of our major problems.
<ajs6f>cbeer: niicely laid out.14:46
cbeer: let's break out the type and add a few @Ignores and we're done, right? :)14:48
* travis-ci joins14:49
fcrepo4/fcrepo4#2959 (cbeer-rdf-types - 9a63db4 : Chris Beer): The build has errored.
Change view : https://github.com/fcrepo4/fcrepo4/compare/8198fe88998b...9a63db452f4e
Build details : http://travis-ci.org/fcrepo4/fcrepo4/builds/38956766
* travis-ci leaves
* nikhiltri leaves14:53
* github-ff joins14:59
[fcrepo4] cbeer pushed 1 new commit to cbeer-rdf-types: http://git.io/22Uv4Q
fcrepo4/cbeer-rdf-types 3170534 Chris Beer: Include type information for unknown string types
* github-ff leaves
* dwilcox joins15:02
<jonroby>would anyone like to have a chat about modeshape/authentication?15:03
* escowles leaves15:04
* gregjansen joins
* travis-ci joins15:05
fcrepo4/fcrepo4#2960 (cbeer-rdf-types - 3170534 : Chris Beer): The build has errored.
Change view : https://github.com/fcrepo4/fcrepo4/compare/9a63db452f4e...317053462a11
Build details : http://travis-ci.org/fcrepo4/fcrepo4/builds/38958171
* travis-ci leaves
* gregjansen leaves15:08
* nikhiltri joins15:09
* github-ff joins15:14
[fcrepo4] cbeer force-pushed cbeer-rdf-types from 3170534 to a65316d: http://git.io/W7NFIQ
fcrepo4/cbeer-rdf-types a65316d Chris Beer: Include type information for unknown string types
* github-ff leaves
<cbeer>ajs6f: ok, so something stupid like that takes care of all our unknown types. i guess we could do the same for all the non xsd:DateTime types too
leaving us with just the float <-> double problem
<ajs6f>cbeer: You're talking about stringliteral2node()?15:15
<cbeer>ajs6f: yep. totally stupid, but.15:16
<ajs6f>cbeer: Float and Double is a case for the most austere compilers of research data. I have a hard time imagining use cases. Thorny wants to supply Taverna workflows with Fedora data, and that doesn't even make a use case.
Lemme look at stringliteral2node().
I bet it's fine.15:17
<cbeer>ajs6f: oh, i've just realized the big flaw here, though.. we don't let you have a property with multiple value types. if you make it a Calendar, it's always a calendar.15:18
<ajs6f>cbeer: sorry, looking at https://github.com/fcrepo4/fcrepo4/pull/573/files#r19358462, are you talking about stringliteral2node();
?
* travis-ci joins15:19
fcrepo4/fcrepo4#2961 (cbeer-rdf-types - a65316d : Chris Beer): The build has errored.
Change view : https://github.com/fcrepo4/fcrepo4/compare/317053462a11...a65316dfc9c5
Build details : http://travis-ci.org/fcrepo4/fcrepo4/builds/38959337
* travis-ci leaves
<cbeer>ajs6f: wrong paste?
<ajs6f>What? no, I'm just trying to follow two different threads. Actually, four different threads, two of which are relevant here.
<cbeer>ajs6f: I don't see the connect to https://github.com/fcrepo4/fcrepo4/pull/573/files#r1935846215:23
<ajs6f>cbeer: There isn't one. 0That I know of.)
* dwilcox leaves15:25
<ajs6f>cbeer: What is ""\30^^\30""?
<cbeer>ajs6f: random garbage.
ajs6f: that we'd be betting doesn't show up in real data.
<ajs6f>cbeer: Wait, so what is the value of distinguishing literal2node and stringliteral2node?15:26
<cbeer>ajs6f: one place we know we have a string and have to bother with. Other things are just types that'll get their RDF types correctly applied normally.15:27
<ajs6f>cbeer: Are we offering a secret way to offer a type that will be preserved?
* dwilcox joins
<ajs6f>Like if you put ""\30^^\30"" in you can get special treatment?
* gregjansen1 joins
<cbeer>ajs6f: yes, unless we write some escaping logic (in which case, we could make that separator a less implausible string).15:28
<ajs6f>cbeer: Can we just try to recognize the data types about which we care? Like parse it somewise via Joda and let the result of that be the determiner?15:29
Assuming that if someone is presenting something that parses perfectly as an ISO datetime, they meant a datetime?
<cbeer>ajs6f: did you see the other half of that commit? https://github.com/fcrepo4/fcrepo4/commit/a65316dfc9c54189f808214f1d50880312e52d25#diff-669b1da6e2478664cffc40d1ca91eca2R15315:30
ajs6f: if it gets there, it's not a type we're converting into native JCR types15:31
ajs6f: and if there's an RDF type, we stash it in the value
<ajs6f>cbeer: Okay, so what is the point of the special delimiter? Is it so that clients can intentionally trigger special behavior? I'm sorry for being slow.15:32
<cbeer>(and, i'm still not advocating that this is a good idea. just that it's an idea.)
ajs6f: you give me some RDF with the literal "xyz"^^ajs:specialKindOfString
<ajs6f>k
<cbeer>ajs6f: we store that as the value "xyz\30^^\30ajs:specialKindOfString"
ajs6f: and unpack it on the way out.
<ajs6f>cbeer: So it's an escape to allow non-XSD RDF literal types.15:33
<cbeer>ajs6f: or, non-native JCR types.
because there are XSD RDF literal types we can't deal with either (gYear, etc)
ajs6f: so, we use the JCR type system where it can store semantically equivalent values, and we avoid it for everything else.15:35
<ajs6f>cbeer: I'm starting to wonder if we should go whole-heartedly down that road. Just let clients record the type themselves. Stop trying to guess their intentions.
cbeer: What are we getting out of the JCR literal type system?
<cbeer>ajs6f: i don't understand how what you said is any different that what that commit does.
<ajs6f>cbeer: The node type system, sure, but what is the literal system doing for us?
cbeer: It's not.
cbeer: I'm saying we maybe should do what you do in that commit and _nothing else_. Call it a day.15:36
cbeer: Don't try to go xsd:int -> jcr:int, etc.
There's a lot of hairy code we wrote for that stuff.
<cbeer>ajs6f: oh, and store everything as JCR strings with types in the values?15:37
<ajs6f>But does LDP require us to do any of that, or just preserve the syntatic record of type assignments?
cbeer: Something like that.
<cbeer>ajs6f: LDP gives us permission to do whatever we want.
<ajs6f>If you want a type, record it, and we'll produce the same lexical value with the same annotations.
We're not going to let you do math inside the repo.
<cbeer>ajs6f: i think i'm fine with dropping our literal mapping logic, but we'd probably have to drop fcr:sparql.15:38
<ajs6f>cbeer: I've already expressed my opinion about that in this forum.15:39
<cbeer>ajs6f: get awoods on board and I'm game.
<ajs6f>cbeer: I'm on it.
awoods: *(^(*^*) fcr:sparql. Okay?
(I can't imagine the reposte.)
awoods: ping?15:41
cbeer: It's cool. I'm sure awoods is fine with it. Let's just do it.15:42
<awoods>ajs6f/cbeer: back15:48
what's the scoop?
<ajs6f>awoods: Just say, "Yes" and we'll take it from there.
<cbeer>ajs6f: you know, if we remove all the code, we'll have far fewer edge cases to deal with too.15:49
<ajs6f>cbeer: Oh my yes.
cbeer: And we'll be much surer of doing what the client really wants.15:50
<cbeer>ajs6f: transparent serialization all the way down.
<ajs6f>cbeer: Neil will get what he's always after.
* scossu joins15:51
<awoods>cbeer: the question is whether to drop fcr:sparql or not?15:52
<cbeer>awoods: that is the question. ajs6f wants it gone, it'd let us drop some convoluted logic, and isolate us from some more JCR behavior.15:53
<awoods>cbeer: and the type/translation issue is moving us that direction...
cbeer: because of the imprecision in the type mapping?15:54
<cbeer>awoods: the mis-match between RDF types and JCR types, yes.
<ajs6f>awoods: Because the work to make the mapping precise is considerable, error-prone, and of dubious value.
awoods: In theory, we could do it, and no one would care, and it would be awful code.15:55
<awoods>cbeer/ajs6f: There is a fairly strong use-case for being able to detect synchronous updates.
cbeer/ajs6f: are we not happy with the caveats that come with the current fcr:sparql?15:56
<ajs6f>awoods: SPARQL is a rotten way to understand deltas.15:58
* github-ff joins15:59
[fcrepo4] cbeer force-pushed cbeer-rdf-types from a65316d to f03ac97: http://git.io/W7NFIQ
fcrepo4/cbeer-rdf-types 23902f5 Chris Beer: Refactor Jena -> sesame literal conversion
fcrepo4/cbeer-rdf-types 96601c9 Chris Beer: provide a better isomorphic failure error message
fcrepo4/cbeer-rdf-types 877933f Chris Beer: Add integration tests for round-trip isomorphism for MODS-RDF and Geonames RDF
* github-ff leaves
<cbeer>awoods: we have a lot of caveats now that require you to understand how fcrepo4 is managing data internally16:00
<awoods>ajs6f: I would be more inclined to do what we have been doing and say that the internal fcr:sparql is limited in <these ways>
cbeer/ajs6f: the caveats have increased lately?
<cbeer>awoods: they are the same right now. properly supporting a range of RDF types will increase them.16:01
awoods: and, if we removed fcr:sparql, we could also support a wider range of storage use cases too.
<ajs6f>awoods: The <these ways> include <not actually being SPARQL>.
<cbeer>awoods: include mixed-type properties (some <x> as an integer or a string)
<ajs6f>awoods: Mashing literal types is a pretty basic fail.
awoods: If we could declare a genuine subset of SPARQL, a profile of sorts, that would be one thing.16:02
awoods: But that's not where we're headed.
<cbeer>ajs6f: well, we could still... you can only do sparql queries against relations and types. all literal values are off the table.16:03
ajs6f: i'm not sure that's compelling.
<ajs6f>cbeer: mdurbin does far more SPARQL for admin than do I (for UVa), and while I can't speak for him, I think he would be unimpressed.16:04
<awoods>cbeer/ajs6f: The fact is we some level of very basic internal search.
... we <need> some level ...
<pivotal-bot____>Chris Beer added "Support the full range of RDF datatypes" https://www.pivotaltracker.com/story/show/8139994016:05
Chris Beer started "Support the full range of RDF datatypes" https://www.pivotaltracker.com/story/show/81399940
Chris Beer finished "Support the full range of RDF datatypes" https://www.pivotaltracker.com/story/show/81399940
<ajs6f>awoods: This has been a claim for a while, and I haven't yet heard it substantiated by the example of any site that uses internal search and has no other.
<pivotal-bot____>Chris Beer added comment: "https://github.com/fcrepo4/fcrepo4/pull/587" https://www.pivotaltracker.com/story/show/81399940
* github-ff joins
[fcrepo4] cbeer opened pull request #587: Cbeer rdf types (master...cbeer-rdf-types) http://git.io/DjJoPw
* github-ff leaves
<awoods>ajs6f: mikeAtUVa and scossu have the use-cases.
<ajs6f>awoods: Perhaps they should accompany them with PRs?16:06
<cbeer>awoods: do they have use cases that can only be solved with an internal sparql search index?
<ajs6f>awoods: I'm not joking. At what point do we allow a single use case to warp software out of shape?
<cbeer>awoods: or do they have use cases that can be solved with such?
<awoods>cbeer: they have use cases that require search on synchronous updates.16:07
<cbeer>awoods: are they on the wiki?
<ajs6f>awoods: Are those kinds of cases amenable to being solved at the application layer, and is that in fact the appropriate architectural level?
awoods: IOW, is that a Fedora use case, or a Hydra use case, or a X-framework-on-top-of-Fedora-that-you-use use case?16:08
<awoods>ajs6f: I appreciate the need for a very simple search within the repo... likely one that could be supported by fcr:search.
<cbeer>awoods: only fcr:search and not fcr:sparql?16:09
<ajs6f>awoods: If fcr:search is to the point, then let's (for Pete's sake!) leave it at that.
cbeer: exactly.
<scossu>awoods, ajs6f: the reason why I prefer keeping (and improving) the internal SPARQL search are in this ticket: https://www.pivotaltracker.com/n/projects/684825/stories/8038931416:10
<ajs6f>I like offering SPARQL as much as the next guy. Hell, I'd like to offering SPARQL over an inferencing store. But I'm convinced now that it's architecturally unsound to offer it from inside the repository process.
<awoods>cbeer/ajs6f: https://wiki.duraspace.org/label/FF/uc-search16:11
* travis-ci joins
fcrepo4/fcrepo4#2962 (cbeer-rdf-types - f03ac97 : Chris Beer): The build has errored.
Change view : https://github.com/fcrepo4/fcrepo4/compare/a65316dfc9c5...f03ac97aeeca
Build details : http://travis-ci.org/fcrepo4/fcrepo4/builds/38963030
* travis-ci leaves
<scossu>It may even not be SPARQL, as long as it is as flexible.
<cbeer>awoods: i don't see use cases there that want SPARQL.
<ajs6f>awoods: I don't find those reasons compelling at all (for our discussion), and the second (no indexing for security) I suspect may involve a misunderstanding of the proposed architecture.16:12
<awoods>cbeer: no, internal sparql is not a requirement
<ajs6f>awoods: Well, what we're talking about is SPARQL. I have no desire to keep fcr:search around either, but leave that be.
<cbeer>ajs6f: good thing fcr:search is gone.
<ajs6f>cbeer: Good.
<awoods>ajs6f/cbeer: I would be inclined to keep some minimal internal search capability, sparql or otherwise.16:14
<cbeer>awoods: can you define the requirements for a minimal internal search?
<ajs6f>awoods: having read those (https://wiki.duraspace.org/label/FF/uc-search) use cases, I still don't see where synch search is a prereq for any of them.
<awoods>ajs6f/cbeer/scossu: it is internal search, so security seems like less of an issue.
<ajs6f>awoods: scossu did not want to use external indexing for security reasons. I'm not sure that is the best understanding of possible architecures.16:15
<awoods>ajs6f: I am pretty sure mikeAtUVa has sync search in mind. Even if it is not explicitly spelled out in: https://wiki.duraspace.org/display/FF/University+of+Virginia+-+Applications+can+be+easily+built+to+work+against+fedora16:16
<ajs6f>awoods: Or to reuse your words, "it is internal search, so security seems like less of an issue." but in my view, it is not actually an issue in either mode.
<scossu>awoods: I am too, and more than inclined to keep an internal search tool - unless an external indexer can handle the access policies in the repo, which seems to me more unlikeny than anything else.
<ajs6f>awoods: We can offer a sidecar synch search that doesn't break the basic operation of the repo. I'm not arguing against that. I am arguing that we shouldn't prefer a "Son of Fedora 3 Admin Search" to doing the basic type system right.16:17
<awoods>ajs6f/cbeer: If I understand this correctly, there is a desire to manage types within F4 with precision, and doing that as well as supporting fcr:sparql is difficult, at best.16:18
<ajs6f>awoods: Yes. In the larger picture, we would like to return clients RDF that actually matches the RDF they stored, modulo the RDF specs.16:19
awoods: But fcr:sparql doesn't operate on RDF. It operates on JCR.
awoods: For many types, the difference won't matter very much. But for some, and those not the least interesting, it will.16:20
awoods: And from the POV of sustainability, the code required to map the two systems will always be confusing, difficult-to-test, and something of a slowly-moving target.16:21
<scossu>ajs6f: if you could suggest a better idea for what I am trying to achieve I would be very grateful - but still I feel like a repository without an even minimal internal search facility seems odd to me.
<awoods>cbeer/ajs6f: my question is, "what level of search can we reasonably support given the goals of round-tripping RDF"?
<ajs6f>scossu: I'm not sure I understand yet where the external indexer doesn't meet your needs. Perhaps we can talk synchronously?
cbeer/awoods: cbeer's suggestion of structural SPARQL would surely work, but it might not meet the needs of which you are thinking.16:22
you-awoods.
<awoods>ajs6f: that is the crux of the question. Would that level of search meet the need?16:23
<ajs6f>awoods: I haven't yet met the need, so I can't say.
<scossu>ajs6f: a simple use case: I have some tags which I store as nodes in fcrepo. I want to search resources related to these tags.
<ajs6f>scossu: Another way to think about this: a repository without search is unsurprising. A repository _system_ or _infrastructure_ without search would be odd at best.16:24
<scossu>Some of the tags are confidential though and I don't want to make them available to everyone.
<awoods>scossu: who are the consumers of this search?
<ajs6f>scossu: In what way does the external indexer system fail here? Simply don't expose your index to the world… I think I must be missing something here.
<scossu>awoods, ajs6f: I need different levels of access to some of the tags.16:25
The tags can either be indexed or not - i.e they are either searchable by everybody or nobody.
<ajs6f>scossu: This seems like it is certainly an application-level concern, not a repository-level concern. After all, the agents obtaining (various levels of) access to the tags are not sending HTTP requests directly to the repo, are they?16:26
<scossu>Some tags are departmental and we can't share thainformation even across depts.
<awoods>scossu: what is the reason that these users can not wait for an external index to be updated?
<ajs6f>scossu: but the various agents involved are using applications that talk to the repo, right? they are not talking to the repo themselves?
awoods: also a good question.16:27
* gregjansen1 leaves
<scossu>ajs6f: they would send the query to Fedora through a client app. But then I would have to replicate the access policies in the client, won't I?
awoods: timing and sync are not an issue in this case.16:28
<awoods>ajs6f/cbeer/scossu: maybe we get closer to a resolution if we are able to bundle external search with a version of the deployable war.
<ajs6f>awoods: +1
That's just Maven trickery.
We can do tht.
<awoods>scossu: I do not think security was ever envisioned as a part of the "internal admin search".16:29
scossu: that said, establishing patterns for authz in external solr and triplestore is a general community concern.
<ajs6f>scossu: Your auth framework is a crucial part of the complete architecture, but I'm not sure that it's a good design to have it completely instantiated by the repository alone.
<scossu>I might have been offline for the beginning of this conversation - has another search language, closer to JCR, been considered?
<ajs6f>scossu: Or over and over again by clients.16:30
* yinlin leaves
<cbeer>scossu: fcrepo4 is not JCR and should not look like JCR (or, if you want JCR, there are many good JCR implementations out there)
<ajs6f>awoods: Yes, we have gotten that kind of question since GSearch and the RI. It's totally legitimate, but internal search does nothing to solve it.16:31
ModeShape isn't bad.
<scossu>ajs6f: so your suggestion is to build security policies for records to be indexed outside of Fedora?16:33
<awoods>scossu/ajs6f: that is the model that has been adopted by hydra wrt solr, no?16:34
<ajs6f>scossu: I wouldn't like to make a very concrete suggestion until I understand more about your case. For example, you mentioned cross-departmental restrictions: are those defined by some data source (e.g. some enterprise service)? That kind of question.16:35
awoods: I'll defer to someone who knows something about Hydra.
<scossu>ajs6f: e.g. some resources are restricted to a certain department, e.g. Conservation. If we index them for search, these resources and their metadata will be available to all departments.16:37
<ajs6f>scossu: Let's be careful. If you index them, they will be indexed. It is when your application displays search results that they become available.16:38
scossu: I'm suggesting loosely that you can index things and not display them.
scossu: Or display parts of them.
<scossu>But you also have to index their metadata if you want the search to be any useful.16:39
<ajs6f>scossu: If you're using something like Solr, we're talkoing about nothing much more than a facet.
scossu: Sure. Why not? Index it, and then display it or not depending on your application-level choices.
<scossu>ajs6f: but then you have to build all of the security outside of Fedora. And the advantage of using fancy stuff like XACML is gone.16:40
<awoods>ajs6f/scossu: we have intentionally been calling it "internal admin search" to make it clear that security is not on the table.16:41
<scossu>at least for what we are using...
<ajs6f>awoods: Right.
scossu: I think there's an important point here that awoods may be alluding to: putting the search inside the repo doesn't help your use case at all.
scossu: The search is not protected by XACML any more than an external index would be.16:42
<awoods>ajs6f: I am thinking of the admin use case...
ajs6f: I just created a bunch of objects and want to find one of them... maybe a quick change.
<ajs6f>awoods: Okay, but what scossu is describing is sounding more and more to me like admin search.
awoods: Again, where is the problem with external search?
awoods: If you are typing faster than your ActiveMQ message broker can keep up, you have a different kind of problem.16:43
<awoods>ajs6f/scossu: as a note, I am very interested in the patterns that are yet to be established about authz and external search services: solr and triplestores16:44
<scossu>ajs6f, awoods: good point about admin search. But how is security in Fedora useful if we need an external security layer for everything that's indexed?16:45
<ajs6f>awoods: I agree that it is crucial that we explore and support that kind of design problem. In the past, that sort of thing has been largely left to application framework over Fedora, and I'm not sure that's not still a viable apporach, but we should be able to offer some solidity around those questions.
<awoods>ajs6f++16:46
ajs6f/cbeer: I would be interested what level of search we can support in the context of RDF round-tripping.
<scossu>Maybe I need to think it differently, but for now I just see a lot of duplicate work to maintain very similar security policies in two places. And more if you have more than one client accessing the indexer.
<ajs6f>scossu: Fedora is able to protect your content. Once you index it, Fedora is not automatically able to protect your index. That doesn't mean that the problem is not important, but I do think it may mean that authZ at that stage is a larger question that a repository framework should be answering.16:47
than a repo framework etc.
scossu: Again, it's crucial to understand that the internal search would not help you here.
scossu: the problem does not go away if you use internal search. The indexed results remain available.16:48
<awoods>ajs6f/scossu: what I would like is for the same policies that are created in the repository can be used by other systems. That is the conversation that is currently underway in the Hydra community.
<pivotal-bot____>Osman Din added comment: "I tested other things a bit (without seeing any red flags), and also let the original process run in the backgro�" https://www.pivotaltracker.com/story/show/80555496
Osman Din finished "Test auto-session-logout with large response RDF" https://www.pivotaltracker.com/story/show/80555496
<cbeer>ajs6f: can i get your help with a Jena thing? i'm trying to figure out how to go from a URI in-hand to a Jena datatype object and coming up short.
<ajs6f>awoods: That would be lovely.
cbeer: Yep, give me a minute to deal with some IRL household stuff. brb16:49
<scossu>awoods: that woud be of great help. We still would need to build an infrastructure that understands complex scenarios.
* awoods must eat food
<cbeer>ajs6f: as opposed to virtual household stuff?
* osmandin leaves16:51
<ajs6f>cbeer: Yes, my virtual household is virtually spotless and virtually perfectly arranged and my virtual child is a virtual angel and my virtual pets are handsome and charming. The only thing that is consistent between my virtual and real lives is that my wife is really talented and beautiful in both.
* dwilcox leaves16:53
<cbeer>ajs6f: nm. found it on NodeFactory, i hope.
* dwilcox joins16:58
<ajs6f>cbeer: k, cool.17:01
* awead leaves17:02
<ajs6f>awoods: "ajs6f/cbeer: I would be interested what level of search we can support in the context of RDF round-tripping."17:06
awoods: You're talking about some kind of internal search?
<awoods>ajs6f: yes, I am talking about our existing fcr:sqarql.17:19
<ajs6f>awoods: I think cbeer's idea of a "structural SPARQL" could make sense, but it would take considerable work.17:21
awoods: and we would want to actually define it pretty clearly, to avoid misleading people.17:22
<awoods>ajs6f: we already have fcr:sparql, does it completely break with cbeer's current RDF-round-tripping efforts?
<cbeer>awoods: not the current effort, no.17:23
<ajs6f>awoods: They are on a collision course, but I'll leave it to cbeer to explain.
cbeer: You don't think that the literal typing issues will results in SPARQL queries giving results that shouldn't be produced?
Matches that don't really match according to the spec?17:24
<cbeer>ajs6f: i think the work in https://github.com/fcrepo4/fcrepo4/pull/587 will be no worse than what we're already doing.
ajs6f: i think the work we're discussing would ruin it in several cases.
<ajs6f>cbeer: Okay. I guess I'm only now starting to realize what we are doing.
<cbeer>awoods: so, our long-standing bug with the way we store RDF statements is due to the JCR type system. That type system doesn't let us mix multiple value types under the same predicate name.17:25
<ajs6f>cbeer: For example, we are, in several cases, returning matches because the JCR type of a property is a sort of "super-type" of the original RDF property's type, right?17:26
<cbeer>awoods: at the same time, we want to correctly deal with values that do not map cleanly into the JCR type system
* jonroby leaves
<cbeer>awoods: we have a way to serialize RDF outside the JCR type system (by building our own types within the JCR String), and deserialize them back to their expected values17:27
awoods: within -kernel and -http-api, everything would be happy with that.
awoods: within fcr:sparql, things break. fcr:sparql only works because it can lean on the Modeshape search index, and all of a sudden, our values aren't within its type system.17:28
<awoods>cbeer: so you are thinking of actually serializing type information into property values?17:29
<cbeer>awoods: yes. that's what we've been discussing above.
<awoods>cbeer: just making is crystal clear17:30
s/is/it/
<ajs6f>awoods: and the concomitant change is that SPARQL makes no sense over those new values.
<cbeer>awoods: and https://github.com/fcrepo4/fcrepo4/pull/587 does a limited form of that.. serializing into the quasi-type system for things we can't handle as JCR types.
* github-ff joins
[fcrepo4] cbeer created kill-the-jcr-type-system (+1 new commit): http://git.io/JFumSg
fcrepo4/kill-the-jcr-type-system cd3f906 Chris Beer: Stop using the JCR type system for literals
* github-ff leaves
<nikhiltri>I'm working on rebasing a pull request for https://www.pivotaltracker.com/n/projects/684825/stories/79207804, and one of the issues I'm running into is setting the primaryType of a node. Are we no longer allowing that?17:31
<awoods>cbeer: so the specific search issues would arise when these un-mappable types are requested by fcr:sparql.
* github-ff joins
[fcrepo4] cbeer force-pushed cbeer-rdf-types from f03ac97 to d58c00c: http://git.io/W7NFIQ
fcrepo4/cbeer-rdf-types d58c00c Chris Beer: Round-trip all XSD types without semanic lossiness
* github-ff leaves
<cbeer>awoods: right. which, in #587 is only types we are handling poorly anyway.. but that requires users to know how we're dealing with things internally, which is bad.17:32
<awoods>nikhiltri: I do not think we have ever allowed (or at least ever supported) other primarytypes.
<cbeer>awoods: but if we go all the way, it's all the user data.
<ajs6f>awoods/cbeer: irc://irc.freenode.net:6667/#587  would also mean making a fairly arbitrary distinction amongst RDF literal types.
<cbeer>awoods: we could still commit to server managed properties and relations.. but without knowing the real use case behind fcr:sparql, i can't judge if that's sufficient.. it certainly seems less-than-useful.17:33
* github-ff joins17:34
[fcrepo4] cbeer force-pushed kill-the-jcr-type-system from cd3f906 to f3cfd04: http://git.io/QTh-RA
fcrepo4/kill-the-jcr-type-system f3cfd04 Chris Beer: Stop using the JCR type system for literals
* github-ff leaves
<awoods>cbeer: are we hearing complaints about the current asymmetric RDF-round-tripping?17:35
<cbeer>awoods: just me, trying to put real-world RDF into the repository.17:36
<ajs6f>awoods: I would find it problematic, because it could much up timestampts.
<cbeer>awoods: but that's a guarenteed problem once you have real users.
<ajs6f>muck up
<cbeer>awoods, ajs6f: yeah, dates are the biggest offender, but non-XSD schema types, and not-formatted-correctly values are up there too.17:39
<awoods>cbeer/ajs6f: I can see the high value in round-trip symmetry. But we also need to offer a valid alternative to folks who are now expecting some basic search capability... that we have advertised.
<ajs6f>the best thing I've heard suggested so far is "structural SPARQL". We could define and impl that with some real precision and it would be supportable over the long term.17:40
<cbeer>awoods, dwilcox : then, as the people collecting and summarizing user stories, can we get you to provide a concrete description of the requirements for that capability?
<ajs6f>cbeer: +1
<cbeer>awoods: you keep saying we need one, but i don't know what one does.
<ajs6f>I have the bad feeling that some amount of people are just thinking of F3's admin search.
<awoods>ajs6f: that is right, basic property search.17:41
<nikhiltri>awoods: We were using custom primarytypes up until recently. Much of this fix assumes that it's possible. The code essentially 1) Looks for velocity templates for a node's parent primary types if a one can't be found directly matching fcrepo:primaryType, 2) Looks for templates matching a node's mixins if nothing is found in 1. Is this necessary if custom primaryTypes aren't allowed?
<ajs6f>awoods/cbeer: maybe the best thing here is the most unstructured: keyword search over the internal indexes, and that's it. Done.17:42
<awoods>nikhiltri: searching for mixins makes sense.
* github-ff joins
[fcrepo4] cbeer force-pushed cbeer-rdf-types from d58c00c to 432159f: http://git.io/W7NFIQ
fcrepo4/cbeer-rdf-types fd8e175 Chris Beer: provide a better isomorphic failure error message
fcrepo4/cbeer-rdf-types 627f2d8 Chris Beer: Add integration tests for round-trip isomorphism for MODS-RDF and Geonames RDF
fcrepo4/cbeer-rdf-types 432159f Chris Beer: Fix boolean RDF literal/JCR type mapping
* github-ff leaves
<awoods>ajs6f: that was the essence of fcr:search, no?17:43
<ajs6f>awoods: Not to my recollection. There was a lot of business about properties and the like.
* github-ff joins
[fcrepo4] cbeer force-pushed kill-the-jcr-type-system from f3cfd04 to 4d84078: http://git.io/QTh-RA
fcrepo4/kill-the-jcr-type-system 95bc444 Chris Beer: Stop using the JCR type system for literals
fcrepo4/kill-the-jcr-type-system 4d84078 Chris Beer: kill fcr:sparql
* github-ff leaves
<ajs6f>awoods: I'm talking about a one-field search.
<cbeer>ajs6f: and i have no faith that a keyword search actually solves a user need.
<ajs6f>Google search.
cbeer: Me neither. But awoods says otherwise.17:44
cbeer: Or you mean to distinguish a keyword search and a property search?
* travis-ci joins
fcrepo4/fcrepo4#2967 (kill-the-jcr-type-system - f3cfd04 : Chris Beer): The build has errored.
Change view : https://github.com/fcrepo4/fcrepo4/compare/cd3f906700f8...f3cfd049ac0f
Build details : http://travis-ci.org/fcrepo4/fcrepo4/builds/38971157
* travis-ci leaves
* dwilcox leaves17:45
<f4jenkins>Project fcrepo-module-auth-rbacl build #291: UNSTABLE in 3 min 28 sec: http://jenkins.fcrepo.org/job/fcrepo-module-auth-rbacl/291/
<cbeer>ajs6f: i mean, i don't think a keyword search is a useful service for fcrepo4 to provide when we have no control over its recall.17:46
ajs6f: i have a hard time imagining a scenario where i know a record has some string in it and i want to go to the repository to find out what that record is... that's what your search index is for.
<ajs6f>cbeer: I'm just trying to get at the MVP for this idea of "internal search".
<awoods>ajs6f/cbeer: as far as I know, we have two primary stakeholders for the internal search capability: scossu and mikeAtUVa. Let's have a meeting next week to get the cards on the table.17:48
* travis-ci joins
fcrepo4/fcrepo4#2964 (kill-the-jcr-type-system - cd3f906 : Chris Beer): The build has errored.
Change view : https://github.com/fcrepo4/fcrepo4/commit/cd3f906700f8
Build details : http://travis-ci.org/fcrepo4/fcrepo4/builds/38970982
* travis-ci leaves
* github-ff joins
[fcrepo4] cbeer opened pull request #588: Kill the jcr type system (cbeer-rdf-types...kill-the-jcr-type-system) http://git.io/2IZyTg
* github-ff leaves
<scossu>awoods: sounds good to me.17:49
<ajs6f>awoods: Okay. Let me just merge that PR from cbeer, and we can talk date/time.
<awoods>ajs6f/cbeer: I am in favor of moving towards external search, but we can not toss other committed community members to the wayside in the process.
<cbeer>ajs6f: that PR "solves" date/time.
<ajs6f>Badump-ching!
* dwilcox joins
<ajs6f>awoods: No one is suggesting that. I am increasingly confident that when we have more information, it will become clear that use cases for "internal search" can be supported and well-supported by indexing outside the repo.17:50
<nikhiltri>awoods: So a template based on a mixin can be used to override the default template display provided by the primary type?17:52
* travis-ci joins17:53
fcrepo4/fcrepo4#2968 (cbeer-rdf-types - 432159f : Chris Beer): The build has errored.
Change view : https://github.com/fcrepo4/fcrepo4/compare/d58c00c97afa...432159ffe942
Build details : http://travis-ci.org/fcrepo4/fcrepo4/builds/38972070
* travis-ci leaves
* github-ff joins17:54
[fcrepo4] cbeer force-pushed cbeer-rdf-types from 432159f to 666e7c3: http://git.io/W7NFIQ
fcrepo4/cbeer-rdf-types 2af39c1 Chris Beer: provide a better isomorphic failure error message
fcrepo4/cbeer-rdf-types ab4455b Chris Beer: Add integration tests for round-trip isomorphism for MODS-RDF and Geonames RDF
fcrepo4/cbeer-rdf-types 6d90d6d Chris Beer: Fix boolean RDF literal/JCR type mapping
* github-ff leaves
<awoods>nikhiltri: a mixin seems more specific than a primary type, so I can see that being reasonable. ajs6f, cbeer, thoughts?
* github-ff joins17:55
[fcrepo4] cbeer force-pushed kill-the-jcr-type-system from 4d84078 to 492a390: http://git.io/QTh-RA
fcrepo4/kill-the-jcr-type-system 9049a9c Chris Beer: Stop using the JCR type system for literals
fcrepo4/kill-the-jcr-type-system 492a390 Chris Beer: kill fcr:sparql
* github-ff leaves
<ajs6f>awoods/all: Yes, that seems pretty reasonable, although we would need to define a complete order on the hierarchy.
That could just be by inheritance paths and then by name, or something.17:56
<awoods>nikhiltri: that is the tricky part, it may be hard to select out the mixin that you actually want.
cbeer: seriously? you just dropped the monkey on fcr:sparql!
<ajs6f>It would have to be deterministic, and the easiest way to ensure that would be a total order.17:57
cbeer: I didn't know you had a monkey. You should bring that to the next conf. That would be a big hit.
<cbeer>awoods: in that PR, yes. that's separate from the PR to master.
s/separate/separate and in addition to/
<awoods>ajs6f: you have mixins and a primarytype, where does the ordering come in?17:58
<ajs6f>awoods: You might have six mixins of which three have templates. Which one wins?
<awoods>ajs6f: exactly, that is the tricky part17:59
of nikhiltri's suggestion
<ajs6f>awoods: That is what a total order on the mixins would solve.18:00
Which one wins? The highest (or lowest, whichever).18:01
<awoods>ajs6f: yes, and how is that "total order" established?18:02
<ajs6f>awoods: that's what I'm saying we have to do.18:03
<nikhiltri>awoods/ajs6f: That desired priority might be different for each implementation, no?
<ajs6f>nikhilitri: Very possibly.
<awoods>nikhiltri/ajs6f: I would assume that you would have a single "marker" mixin that you want to be used for a given resource type.18:06
* travis-ci joins
fcrepo4/fcrepo4#2970 (kill-the-jcr-type-system - 4d84078 : Chris Beer): The build has errored.
Change view : https://github.com/fcrepo4/fcrepo4/compare/f3cfd049ac0f...4d840788cac7
Build details : http://travis-ci.org/fcrepo4/fcrepo4/builds/38972146
* travis-ci leaves
<awoods>nikhiltri/ajs6f: if you mixin multiple such markers, then all bets are off.
<ajs6f>awoods: I don't know what you mean by "resource type".18:10
* travis-ci joins18:12
fcrepo4/fcrepo4#2974 (kill-the-jcr-type-system - 492a390 : Chris Beer): The build has errored.
Change view : https://github.com/fcrepo4/fcrepo4/compare/4d840788cac7...492a390e6196
Build details : http://travis-ci.org/fcrepo4/fcrepo4/builds/38973156
* travis-ci leaves
* travis-ci joins18:14
fcrepo4/fcrepo4#2972 (cbeer-rdf-types - 666e7c3 : Chris Beer): The build has errored.
Change view : https://github.com/fcrepo4/fcrepo4/compare/432159ffe942...666e7c3cd372
Build details : http://travis-ci.org/fcrepo4/fcrepo4/builds/38973139
* travis-ci leaves
<ajs6f>out for the weekend. See y'all Monday.18:16
* ajs6f leaves
* github-ff joins18:20
[fcrepo4] cbeer force-pushed cbeer-rdf-types from 666e7c3 to adc2677: http://git.io/W7NFIQ
fcrepo4/cbeer-rdf-types 51973be Chris Beer: provide a better isomorphic failure error message
fcrepo4/cbeer-rdf-types e8d77fd Chris Beer: Add integration tests for round-trip isomorphism for MODS-RDF and Geonames RDF
fcrepo4/cbeer-rdf-types 6d684a3 Chris Beer: Fix boolean RDF literal/JCR type mapping
* github-ff leaves
<cbeer>ok, hopefully that finally works. rebasing is confusing.
* github-ff joins
[fcrepo4] cbeer force-pushed kill-the-jcr-type-system from 492a390 to 69abd97: http://git.io/QTh-RA
fcrepo4/kill-the-jcr-type-system ad0d790 Chris Beer: Stop using the JCR type system for literals
fcrepo4/kill-the-jcr-type-system 69abd97 Chris Beer: kill fcr:sparql
* github-ff leaves
* ksclarke leaves18:22
* travis-ci joins18:29
fcrepo4/fcrepo4#2976 (cbeer-rdf-types - adc2677 : Chris Beer): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/666e7c3cd372...adc267727469
Build details : http://travis-ci.org/fcrepo4/fcrepo4/builds/38975277
* travis-ci leaves
* travis-ci joins18:30
fcrepo4/fcrepo4#2978 (kill-the-jcr-type-system - 69abd97 : Chris Beer): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/492a390e6196...69abd97dd229
Build details : http://travis-ci.org/fcrepo4/fcrepo4/builds/38975304
* travis-ci leaves
* github-ff joins18:34
[fcrepo4] cbeer created non-rdf-js (+1 new commit): http://git.io/m0hDwg
fcrepo4/non-rdf-js c9847fd Chris Beer: Use javascript to detect requests to non-rdf source properties and redirect them to the metadata page instead
* github-ff leaves
* github-ff joins
[fcrepo4] cbeer opened pull request #589: Use javascript to detect requests to non-rdf source properties and redir... (master...non-rdf-js) http://git.io/MayBww
* github-ff leaves
* scossu leaves18:40
* MohamedAR leaves18:42
* dwilcox leaves18:43
* Jotudin leaves
* Jotudin joins
* travis-ci joins18:44
fcrepo4/fcrepo4#2980 (non-rdf-js - c9847fd : Chris Beer): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/commit/c9847fd3ffe1
Build details : http://travis-ci.org/fcrepo4/fcrepo4/builds/38976147
* travis-ci leaves
* dwilcox joins18:48
<f4jenkins>Yippee, build fixed!18:50
Project fcrepo-module-auth-rbacl build #296: FIXED in 3 min 4 sec: http://jenkins.fcrepo.org/job/fcrepo-module-auth-rbacl/296/
<pivotal-bot____>Nikhil Trivedi added comment: "@awoods Rebased: https://github.com/fcrepo4/fcrepo4/pull/484" https://www.pivotaltracker.com/story/show/7920780418:57
* dwilcox leaves19:00
* nikhiltri leaves19:06
* dwilcox joins19:09
<pivotal-bot____>Chris Beer added "Mixing URI and literal types should work" https://www.pivotaltracker.com/story/show/8141132419:32
Chris Beer added "Handling incoming RDF with datetime without a timezone" https://www.pivotaltracker.com/story/show/8141137619:33
Chris Beer added "Make LDP containers optional" https://www.pivotaltracker.com/story/show/8141141619:34
* dwilcox leaves19:35
* nikhiltri joins20:32
* ksclarke joins20:37
* nikhiltri leaves20:51
* nikhiltri joins20:58
* nikhiltri leaves21:06
* awead joins21:57
* awead leaves22:07

Generated by Sualtam