Chatlog 2012-02-01

From RDF Working Group Wiki
Jump to: navigation, search

See panel, original RRSAgent log or preview nicely formatted version.

Please justify/explain non-obvious edits to this page, in your "edit summary" text.

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> RESOLVED 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> +LeeF
16:04:53 <Zakim> +PatH
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> +zwu2
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> +EricP
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> issue-79?
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 close ISSUE-79
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> q+
16:11:23 <davidwood> ack ivan
16:11:26 <Zakim> +??P34
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: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:17:20 <davidwood> Topic: RDF and Time
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> q+
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> -Arnaud
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> +Arnaud
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> q-
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> q+
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> +q
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> -Arnaud
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> q?
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> +Arnaud
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> q+
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> q?
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
16:57:35 <AlexHall> david: this tells me that all graphs are potentially time-variant
16:57:45 <davidwood> ack PatH
16:58:20 <AndyS> The graph (value) does not vary in RDF's ideal view of the world..  The value in the g-box changes.
16:58:25 <AlexHall> patH: no -- if we're talking about geologic time spans, we don't expect to RDF data to survive this
16:58:35 <MacTed> q+
16:58:57 <sandro> Yeah.  How the heck are people supposed to publish the weather in RDF?    It's the first example in AWWW.
16:59:27 <AlexHall> ... if the publisher of the data expects the data to be time-varying, that has to be accounted for
16:59:42 <sandro> ted: Until the moment things change, you may think what you're saying is going to be true for all time.
17:00:14 <AlexHall> ... macted: time variance can't necessarily be predicted, unexpected change happens all the time in science, e.g.
17:00:21 <sandro> pat: All data is subject to being wrong, yes.    But that's not the same as tomorrow's weather is going to be different from today's.
17:00:35 <swh> database people have been dealing with this for decades - it's fine
17:00:49 <pfps> I agree with swh - strongly - there is nothing new here
17:00:55 <sandro> q+
17:01:02 <Zakim> -Souri
17:01:04 <ivan> ack MacTed
17:01:59 <AlexHall> macted: if data that was thought to be immutable suddenly becomes mutable, that is a bigger problem than data that was thought to be mutable actually being immutable
17:02:05 <sandro> q+ to say there seems to be confusion about what's mutable.    (1) what's true changes, (2) the state of resources MIGHT change or be frozen, (3) g-snaps never change.
17:02:49 <AlexHall> patH: that's true, but we shouldn't force all data to be mutable in the data model
17:02:56 <davidwood> ack sandro
17:03:17 <Zakim> sandro, you wanted to say there seems to be confusion about what's mutable.    (1) what's true changes, (2) the state of resources MIGHT change or be frozen, (3) g-snaps never
17:03:20 <Zakim> ... change.
17:03:34 <swh> publishing weather, dc:date… next?
17:03:38 <swh> q+
17:04:11 <davidwood> ack swh
17:04:30 <AlexHall> sandro: think we should focus on how do you publish the weather in RDF. it's the prototypical example, have no idea right now of how to do that, if we can do that then maybe it can be extended to other problems.
17:04:34 <patH> q+
17:04:57 <davidwood> ack patH
17:05:03 <NickH> +1 to swh
17:05:16 <AlexHall> steveH: i think we're overthinking this. database people have been handling this problem just fine for decades, using timestamp fields in tables
17:05:34 <sandro> swh, any idea why chose to use dc:temporal instead of dc:date ?
17:05:51 <AlexHall> patH: i agree, don't think it's hard, it's a question of how to do it?
17:06:28 <swh> sandro, no idea, dc:date is possibly not the right choice, was just a strawman
17:06:31 <davidwood> "every triple is sacred"
17:06:43 <AlexHall> ... don't want to have to timestamp every triple that can possibly be time-varying
17:07:04 <AndyS> different domain of discourse
17:07:32 <AlexHall> ... could modify the semantics if we decided a standard way of timestamping a graph. then people could understand one another.
17:08:13 <AlexHall> ivan: essentially defining a timestamp vocabulary
17:08:33 <AlexHall> patH: yes, and a convention for adding a timestamp triple to a graph
17:09:21 <davidwood> q?
17:09:34 <sandro> ted: lack of this triple has to be taken as there-with-a-bnode --- all the RDF data out there is implicitely time dependent.
17:09:45 <AlexHall> ???: what to do with all the existing data out there?
17:10:00 <AlexHall> ... it won't have this triple, but might be time dependent
17:10:00 <sandro> s/???/ted/
17:10:26 <AlexHall> patH: think we can work out the details of this over email
17:11:15 <AlexHall> david: if we were to do this and modify the semantics in a way with minimal impact to deployed data, would this buy us anything in the named graph discussion?
17:11:24 <AlexHall> patH: i think it would, yes
17:11:49 <AlexHall> davidwood: can you formulate a proposal for a strawpoll?
17:12:08 <AlexHall> patH: yes, maybe in the next week or so
17:12:31 <davidwood> Alex, please assign an action to Pat
17:12:42 <AlexHall> ivan: not sure what you mean by this. are all triples quads where the fourth entry is a timestamp?
17:13:53 <AlexHall> ... what does it mean that the timestamp vocabulary has a semantics? does it extend the model theory semantics? or is it just described in plain english?
17:13:54 <sandro> ivan: We have the word semantics used in the semantic web with many different semantics.  :-)
17:14:14 <AlexHall> pat: model theory
17:14:46 <AlexHall> ivan: this worries me. afraid that adding this to the model theory would make it too complicated.
17:15:03 <AlexHall> pat: don't think that describing it in english makes it any easier
17:16:49 <AlexHall> action: patH to propose a vocabulary and semantics for adding timestamps to RDF graphs
17:16:49 <trackbot> Created ACTION-141 - Propose a vocabulary and semantics for adding timestamps to RDF graphs [on Patrick Hayes - due 2012-02-08].
17:17:53 <Zakim> -gavinc
17:18:04 <AlexHall> davidwood: out of time. i think if pat can make a proposal, and if it has minimal impact on existing data, then i think we have a good way forward
17:18:13 <sandro> we don't have a named graphs deadlock -- we have no cogent proposals on which to deadlock.
17:18:19 <AlexHall> ... adjourned.