IRC log of rdf-wg on 2012-02-01

Timestamps are in UTC.

16:01:57 [RRSAgent]
RRSAgent has joined #rdf-wg
16:01:57 [RRSAgent]
logging to
16:01:59 [trackbot]
RRSAgent, make logs world
16:01:59 [Zakim]
Zakim has joined #rdf-wg
16:02:01 [trackbot]
Zakim, this will be 73394
16:02:01 [Zakim]
ok, trackbot; I see SW_RDFWG()11:00AM scheduled to start 2 minutes ago
16:02:02 [trackbot]
Meeting: RDF Working Group Teleconference
16:02:02 [trackbot]
Date: 01 February 2012
16:02:11 [ivan]
zakim, who is on the phone?
16:02:15 [Zakim]
SW_RDFWG()11:00AM has not yet started, ivan
16:02:19 [Zakim]
On IRC I see RRSAgent, MacTed, AlexHall, gavinc, Arnaud, AZ, pfps, swh, AndyS, LeeF, mischat, ivan, SteveH, danbri, mdmdm, manu1, davidwood, yvesr, NickH, trackbot, manu, sandro,
16:02:22 [Zakim]
... ericP
16:02:23 [ivan]
zakim, dial ivan-voip
16:02:28 [Zakim]
ok, ivan; the call is being made
16:02:31 [Souri]
Souri has joined #RDF-WG
16:02:57 [MacTed]
Zakim, this is 73394
16:02:58 [Zakim]
ok, MacTed; that matches SW_RDFWG()11:00AM
16:02:59 [MacTed]
Zakim, who's here?
16:02:59 [Zakim]
On the phone I see Peter_Patel-Schneider, davidwood, AZ, OpenLink_Software, ??P11, AlexHall, Arnaud, gavinc, Ivan, sandro, ??P16, Souri
16:03:02 [Zakim]
On IRC I see Souri, Zakim, RRSAgent, MacTed, AlexHall, gavinc, Arnaud, AZ, pfps, swh, AndyS, LeeF, mischat, ivan, SteveH, danbri, mdmdm, manu1, davidwood, yvesr, NickH, trackbot,
16:03:04 [Zakim]
... manu, sandro, ericP
16:03:11 [MacTed]
Zakim, OpenLink_Software is temporarily me
16:03:12 [AndyS]
zakim, ??P11 is me
16:03:12 [swh]
Zakim, ??P16 is me
16:03:13 [MacTed]
Zakim, mute me
16:03:14 [Zakim]
+MacTed; got it
16:03:18 [Zakim]
+AndyS; got it
16:03:20 [Zakim]
+swh; got it
16:03:22 [Zakim]
MacTed should now be muted
16:03:42 [AlexHall]
scribe: alexhall
16:03:47 [davidwood]
PROPOSED to accept the minutes of the 25 Jan telecon:
16:03:47 [davidwood]
16:03:51 [AlexHall]
topic: admin
16:04:02 [davidwood]
Action item review:
16:04:02 [trackbot]
Sorry, couldn't find user - item
16:04:02 [davidwood]
16:04:02 [davidwood]
16:04:10 [AlexHall]
davidwood: no objections, minutes accepted
16:04:21 [AlexHall]
01RESOLVED to accept the minutes of the 25 Jan telecon
16:04:40 [MacTed]
Zakim, unmute me
16:04:40 [Zakim]
MacTed should no longer be muted
16:04:44 [Zakim]
16:04:53 [Zakim]
16:05:15 [AlexHall]
davidwood: action item reviews
16:05:18 [MacTed]
s/RESOLVED to accept/RESOLVED: accept/
16:05:34 [patH]
patH has joined #rdf-wg
16:06:04 [AlexHall]
davidwood: eric completed his review of XML Schema changes, andy commented, can mark it done
16:06:28 [zwu2]
zwu2 has joined #rdf-wg
16:06:28 [AlexHall]
davidwood: past-due action items
16:06:34 [zwu2]
zakim, code?
16:06:34 [Zakim]
the conference code is 73394 (tel:+1.617.761.6200, zwu2
16:06:52 [AlexHall]
patH: will work on action 120
16:07:14 [Zakim]
16:07:28 [zwu2]
zakim, mute me
16:07:28 [Zakim]
zwu2 should now be muted
16:07:37 [AlexHall]
davidwood: let's talk about issue 79, what is the value of a datatyped literals whose datatype IRI is not a datatype?
16:07:41 [davidwood]
16:07:44 [Zakim]
16:08:20 [AlexHall]
davidwood: cygri mentioned that he's satisfied with changes made to the wording of the spec to address this, per message on the mailing list
16:09:26 [AlexHall]
patH: prefer the original wording, but this is OK
16:09:48 [AlexHall]
davidwood: objections to closing issue 79?
16:09:49 [sandro]
16:09:49 [trackbot]
ISSUE-79 -- What is the value of a literal whose datatype IRI is not a datatype? -- pending review
16:09:49 [trackbot]
16:09:57 [AlexHall]
patH: editorial, not substantive
16:10:05 [davidwood]
RESOLVED to ISSUE-79 close
16:10:37 [davidwood]
Topic: Revisit XML Schema Datatypes in RDF and OWL?
16:11:07 [davidwood]
XML Schema Datatypes in RDF and OWL is a W3C Working Group Note dated 14 March 2006:
16:11:07 [davidwood]
16:11:15 [AlexHall]
davidwood: cygri brought up that we might need to revisit 2006 wg note on XSD datatypes in RDF and OWL
16:11:18 [ivan]
16:11:23 [davidwood]
ack ivan
16:11:26 [Zakim]
16:11:44 [AlexHall]
ivan: don't consider that a very high-priority issue
16:12:01 [NickH]
zakim, ??P34 is me
16:12:01 [Zakim]
+NickH; got it
16:12:04 [AlexHall]
... wonder if anybody out there actually used the mechanism for defining new XSD datatypes in RDF
16:12:07 [NickH]
Zakim, mute me
16:12:07 [Zakim]
NickH should now be muted
16:12:12 [gavinc]
ivan, TQ uses it
16:12:15 [MacTed]
Zakim, mute me
16:12:15 [Zakim]
MacTed should now be muted
16:12:26 [AlexHall]
davidwood: think some XML-heads in large enterprise might have used it
16:12:53 [swh]
Some talis people use it, but arguably incorrectly
16:12:54 [gavinc]
ivan, used when importing XML schema into RDF
16:13:04 [MacTed]
Zakim, unmute me
16:13:04 [Zakim]
MacTed should no longer be muted
16:14:15 [AlexHall]
macted: can't think of any use off the top of my head, but gut is that yes it has been used
16:14:56 [gavinc]
q+ Section 4: needs to change
16:15:08 [gavinc]
q+ to talk about Section 4: needs to change
16:15:32 [AlexHall]
ericP: scenario where we need to update the note is that the mechanism for defining literals changed, most likely it's backwards compatible and doesn't need revision
16:15:44 [davidwood]
ack gavinc
16:15:44 [Zakim]
gavinc, you wanted to talk about Section 4: needs to change
16:15:55 [AlexHall]
patH: willing to look at it from semantics perspective
16:16:40 [AlexHall]
gavinc: note mentions that duration doesn't have a well-defined value space, should at least revise that part
16:17:05 [AlexHall]
davidwood: think we have an obligation to keep docs up to date, will email jeremy
16:17:19 [AlexHall]
action: davidwood to ask jeremey to review XSD in RDF and OWL note
16:17:19 [trackbot]
Created ACTION-139 - Ask jeremey to review XSD in RDF and OWL note [on David Wood - due 2012-02-08].
16:17:20 [davidwood]
Topic: RDF and Time
16:17:26 [mischat]
mischat has joined #rdf-wg
16:17:27 [gavinc]
Zakim, mute me
16:17:27 [Zakim]
gavinc should now be muted
16:17:36 [AlexHall]
action: patH to review XSD in RDF and OWL from semantics perspective
16:17:36 [trackbot]
Created ACTION-140 - Review XSD in RDF and OWL from semantics perspective [on Patrick Hayes - due 2012-02-08].
16:18:24 [AlexHall]
davidwood: while pat is here, would like to talk about RDF and time to try and move forward with named graphs
16:18:43 [AlexHall]
... pat made point on mailing list that there is no notion of time sensitivity in RDF at all
16:19:10 [AlexHall]
... surprised me that named graphs are so closely related to time variability
16:19:26 [sandro]
16:19:50 [AlexHall]
... thought that RDF graphs always expressed a snapshot of the world at the time they were written
16:20:16 [AlexHall]
patH: if you think of RDF that way, it doesn't fit with the semantics
16:20:44 [Zakim]
16:20:45 [AlexHall]
... facts in RDF are not time-relative, 2 + 2 = 4 for all of eternity
16:21:04 [sandro]
pat: RDF is a "timeless" framework, where facts are always true
16:21:14 [AlexHall]
... if you want to talk about time, you have to explicitly put them in the ontology
16:21:20 [Zakim]
16:21:37 [sandro]
pat: from Aristotle forward, that's how mathematicians have liked to think of it.
16:21:55 [sandro]
pat: or you have have a time-embedded framework, with an implicit "now".
16:21:58 [ericP]
pat: in time-embedded, if you say the same thing at different times, it means different things
16:22:02 [AlexHall]
... you can also think of facts as time-embedded, saying the same thing at two different times can mean two things
16:22:15 [sandro]
pat: in the second case, the inference rules change.
16:22:15 [ericP]
... so you have to incorporate that context into the semantics
16:22:28 [AlexHall]
... it's natural to think that way, but it complicates the logic when time is implicit in the graph
16:22:52 [sandro]
pat: so the question is whether RDF is timeless or time-embedded. It's not possible to prevent people from using it in a time-embedded way because that's how people think of this.
16:22:58 [AlexHall]
... impossible to prevent people from using RDF in a time-embedded way
16:22:59 [sandro]
16:23:42 [sandro]
eric: Do have to say, "as of this date, our understanding is, this protein has these properties..."
16:24:35 [AlexHall]
patH: scale is important; if data is expected to change over the course of the time that the data is used, then you need to account for time
16:24:54 [sandro]
eric: So they differ in degree -- time range of things changing -- not actually in kind.
16:25:12 [AlexHall]
patH: e.g. weather report for this week vs. geologic time scales
16:25:38 [sandro]
ted: One might expect that HTTP caching and expiration mechanism could be used to help with this.
16:26:23 [Arnaud]
given that time sensitivity is really dependent on the type of data you're dealing with isn't that better left to the application?
16:26:33 [AlexHall]
patH: expect that this conversation is going to arrive at the point where we have to acknowledge that people use RDF in a time-embedded way
16:27:01 [sandro]
davidwood: Our charter gives us use cases that need this to be address to solve them....
16:27:49 [AlexHall]
david: Find this to be the heart of the problem, that named graphs are very closely tied to provenance which is how time sensitivity is addressed
16:28:25 [AlexHall]
patH: one approach is to say that the modelers are always going to have to account for time in their data
16:28:49 [AlexHall]
... but modelers aren't going to do that because it's hard and unnatural
16:28:54 [sandro]
16:29:01 [davidwood]
ack sandro
16:29:07 [AlexHall]
david: also affects versioning and merging of graphs created at different times
16:29:48 [AlexHall]
patH: true, time information has to be captured to effectively merge datasets where time is implicit
16:29:57 [patH]
peter, I never saw you as a tosser.
16:30:23 [AlexHall]
sandro: can add a simple triple into the dataset, "the time right now is X"
16:31:00 [AlexHall]
... use this triple to add extra checks to see that merged graphs were at the same time
16:31:33 [AlexHall]
patH: the point is, lots of applications aren't currently doing this check and would be broken
16:31:36 [sandro]
pat: context logics, sub-intervals
16:31:48 [gavinc]
+q to ask Who is asking us to fix this?
16:32:01 [AlexHall]
david: these rules would be very complicated. i might choose to believe data that's an hour old and not a week old.
16:32:04 [ericP]
q+ to give a use case: should i prescribe drug X for disease Y given old evidence that it helped and newer (but less-reviewed) evidence that it hurts
16:32:22 [davidwood]
ack gavinc
16:32:23 [Zakim]
gavinc, you wanted to ask Who is asking us to fix this?
16:32:27 [AlexHall]
patH: context logics have tried to account for this by adding time intervals, etc.
16:32:32 [davidwood]
ack ericp
16:32:32 [Zakim]
ericP, you wanted to give a use case: should i prescribe drug X for disease Y given old evidence that it helped and newer (but less-reviewed) evidence that it hurts
16:33:16 [patH]
eric, that is a different issue i think.
16:33:18 [AlexHall]
ericP: the way we usually solve this is with SPARQL -- put thresholds in the query, get all information to make a human decision
16:33:35 [Souri]
Is it too naive to consider use of the fourth component (graph?) to define the context (time, space, ...): <ctxt1> { :John a :TeenAger } <ctxt2> { :John a :Octogenarian} <ctxt3>{ <ctxt1> :when 1937 . <ctxt2> :when 2007} <ctxt4> {<ctxt3> :creationYear 2012}
16:34:17 [mischat]
mischat has joined #rdf-wg
16:34:19 [AlexHall]
... state of the art for this is to put relevant information in front of a human to make final decision
16:34:19 [patH]
souri, i think that is the only feasible ideas to standardize, but might be too restrictive.
16:34:39 [AlexHall]
does this scale at all?
16:34:39 [patH]
16:35:40 [AlexHall]
gavin: out of all of us, who is trying to work on a system that is approaching this from a time-implicit way?
16:36:15 [AlexHall]
sandro: asked govt people about this, they use dc:temporal with a time range, required to be in any dataset
16:36:16 [davidwood]
ack patH
16:36:20 [zwu2]
I know a use case that requires associate creation timestamp with every triple
16:37:00 [gavinc]
Zakim, mute me
16:37:00 [Zakim]
gavinc should now be muted
16:37:02 [AlexHall]
patH: saw another use case where they had an OWL ontology, described for each property its likely time persistence (short/long/medium-lived)
16:37:25 [AlexHall]
... allows for pretty complicated modeling (about weather in this case)
16:38:14 [AlexHall]
... going back to eric's use case, you really do have to have a human for this, it's too complex. lots of use cases are simpler, e.g. weather forecasts
16:38:43 [AlexHall]
... think we can at least give advice to implementers about how to handle these simpler use cases
16:38:45 [Zakim]
16:39:17 [AndyS]
zakim, who is on the phone?
16:39:17 [Zakim]
On the phone I see Peter_Patel-Schneider, davidwood, AZ, MacTed, AndyS, AlexHall, gavinc (muted), Ivan, sandro, swh, Souri, LeeF, PatH, zwu2 (muted), EricP, NickH (muted)
16:39:20 [AlexHall]
david: think implementers would say it's too much cost for not much benefit
16:39:43 [AlexHall]
sandro: would love to have steve's input, they harvest lots of time-sensitive data
16:40:00 [LeeF]
swh, are you here?
16:40:05 [LeeF]
SteveH, are you here?
16:40:08 [AlexHall]
eric: think they incorporate a timestamp into the graph tag
16:40:33 [AlexHall]
... use metadata to track the graphs
16:40:58 [swh]
LeeF, yeah, Im here, was AFK breifly
16:40:59 [AlexHall]
pat: this is the 4th approach so far this call. lots of different possibilities
16:42:41 [AlexHall]
steveH: we do incorporate a timestamp into the graph IRI, add a statement inside the graph to record this timestamp
16:43:23 [AlexHall]
... if something is true across time, then it will appear in multiple graphs for as long as it's true
16:43:41 [AlexHall]
eric: is the triple predictable? could it already be in the graph?
16:43:54 [gavinc]
Ding ding! Graph IRI varies with date, same way that WARC solved this as well.
16:44:09 [MacTed]
self-description is important...
16:44:13 [AlexHall]
steve: we don't allow this, we would filter out that predicate
16:44:17 [MacTed]
"follow your nose" falls down without it
16:44:36 [AlexHall]
patH: how do you distinguish things that are time-dependent vs. what isn't?
16:45:06 [AlexHall]
steve: we don't mix different approaches in one system. either a system is time-dependent or it isn't
16:45:15 [davidwood]
16:45:41 [AlexHall]
david: eric mentioned grabbing data from a particular time range and present to the user for a choice. do you do this?
16:45:44 [MacTed]
"the graph IRI", "inside the graph" refer to Gsnap? Gtext? Gbox? hurrah for overloaded terms!
16:46:00 [AlexHall]
steve: we just grab the most recent value, maybe show the most recent time it was true.
16:46:05 [gavinc]
well, time
16:46:54 [AlexHall]
david: would like to talk about gavin's point that time is encoded in the data with graph IRIs.
16:47:02 [Zakim]
16:47:14 [AlexHall]
sandro: would UUID's also work? you don't actually get time from the timestamp?
16:47:50 [AlexHall]
s/from the timestamp/from the timestamped IRI/
16:48:14 [AlexHall]
steve: we mostly use the timestamp for human readability, UUID would be OK
16:49:05 [Souri]
time-delimited truth
16:49:16 [AlexHall]
david: think this discussion has been valuable. we know that people are encoding time data in RDF for stuff that's true for a time. we know people are using this in the field. we know not every fact expressed in RDF is eternally true
16:49:43 [patH]
the real issue is, is the time-stamp part of the rdf data or not?
16:49:53 [AlexHall]
... where does that leave us in relation to e.g. time-varying IRIs?
16:50:39 [AlexHall]
sandro: sounds like steve's approach is what i labeled as TRIG/equality, think that's a reasonable straw-man starting point
16:50:47 [patH]
and is it in each triple or just in an entire graph?
16:50:51 [ericP]
q+ to point out that we can let people migrate from eternal to snapped
16:50:55 [gavinc]
Not really no ;)
16:51:09 [patH]
16:51:34 [AlexHall]
... vs TRIG/REST which would put the time-varying nature of the retrieval more into the core
16:51:38 [patH]
16:52:17 [AlexHall]
... TRIG/equality makes the relation between a graph IRI and its triples time-invarying, think this is a safer approach
16:52:46 [AlexHall]
... steve, after you read in a graph and associate an IRI with it, do you ever modify it?
16:53:01 [gavinc]
"Assign an IRI that is globally unique for its period of intended use."
16:53:09 [AlexHall]
steve: no, it stays constant
16:53:34 [sandro]
16:54:07 [AlexHall]
ted: that's the danger of putting timestamps into IRIs, blurs the line between opaque IRIs and the urge for humans to ascribe meaning to the IRIs
16:54:15 [davidwood]
ack ericP
16:54:15 [Zakim]
ericP, you wanted to point out that we can let people migrate from eternal to snapped
16:54:44 [AlexHall]
(universal agreement that you shouldn't be parsing a timestamp from an IRI, it should be explicit in triples)
16:55:23 [AlexHall]
eric: could get pushback from people who just want to do simple time-invariant modeling if we make it more complicated to account for time variance.
16:56:17 [AlexHall]
... we should make it easy for people to start with the easy case (invariant) and optionally adding in time variance
17:29:11 [AlexHall]
david: this tells me that all graphs are potentially time-variant
17:29:11 [davidwood]
ack PatH
17:29:11 [AndyS]
The graph (value) does not vary in RDF's ideal view of the world.. The value in the g-box changes.
17:29:11 [AlexHall]
patH: no -- if we're talking about geologic time spans, we don't expect to RDF data to survive this
17:29:11 [MacTed]
17:29:11 [sandro]
Yeah. How the heck are people supposed to publish the weather in RDF? It's the first example in AWWW.
17:29:11 [AlexHall]
... if the publisher of the data expects the data to be time-varying, that has to be accounted for
17:29:11 [sandro]
ted: Until the moment things change, you may think what you're saying is going to be true for all time.