17:03:54 RRSAgent has joined #rdfn-lod 17:03:54 logging to http://www.w3.org/2010/06/27-rdfn-lod-irc 17:04:00 rrsagent, make logs public 17:04:16 guus has joined #rdfn-lod 17:04:22 Anchakor has joined #rdfn-lod 17:05:21 mibbit-test has joined #rdfn-lod 17:05:45 UscholdM has joined #rdfn-lod 17:06:21 RC: Richard Cyganiak 17:06:29 MU: Michael Uschold 17:06:36 NN: Natasha Noy 17:06:41 DB: David Booth 17:06:46 GS: Guus Schreiber 17:07:06 Meeting: Linked Data breakout 17:07:10 chair: dbooth 17:07:26 present: rc, mu, nn, db, gs :) 17:09:31 db: two topics: a) follow your nose and b) vocabulary for co-reference 17:10:59 MU: co-reference includes owl:sameAs issues 17:12:30 RC: third issue: document usage guidelines for vocabulary and linked data 17:15:32 RC: in other words, codifying the linked data principles 17:15:42 DB: lets start with the follow your nose issue, a hard one. 17:16:28 DB: what is it exactly? 17:16:55 from my workshop submission: 17:16:56 RDF statements are assertions about the world. But to understand what a statement means, one has to know what the URIs refer to. One has to know what they name. Despite the centrality of URIs in the RDF data model, the RDF specifications have nothing to say about how a URI actually receives its meaning. This needs fixing. It is possible to get a coherent picture of the process by referring to a number of other documents, in particular the httpRange-14 TAG Find 17:16:56 the Architecture of the World Wide Web document, the Cool URIs for the Semantic Web Note, and a number of documents published by enthusiasts outside of W3C. Further progress towards codification was made by the TAG's AWWSW task force. Finally completing this job is an important companion to the standardization of Named Graphs; both together allow for a solid account of Web document metadata and thus context information for RDF data published on the Web. 17:22:33 RC: RDF says nothing about URIs other than what it dereferenes to 17:23:20 GS: huge discussion in a tech plenary back in 03. Social meaning of URIs. 17:23:35 GS: what is the tech goal for this? CoolURIs? 17:24:01 RC: if you use an URI in RDF you can resolve it using follow your nose.. get back RDF document that tells you more abotu the URI 17:24:10 GS: need to be more precise than that. 17:24:23 RC: not here, that is for the working group later 17:25:10 DB: two imputs. Talk at SemTech last week .Also IJCAI conference talk on URI lifecyles. Some suggestion starting point. Framing the issue. I can summaris this briefly now. 17:25:18 RC: lets not do that now. 17:25:23 DB:we need to frame the issue now. 17:26:02 RC: I think obvious inputs are Architecture for WWW document, explains authoritative meaning, de-referencing, etc, CoolURIs. 17:26:36 Mike: there's also a big issue of overloading of URIs 17:28:15 MU: is this related to overloading URIs? 17:29:00 DB: lets not overload this discussion too much here. Much is not coded in anywhere in one place. Must piece things together from various W3C specs. This is the core idea I want to address. 17:29:03 dbooth: I think overloading is part of the issue. 17:29:16 s/DB/RC/ 17:29:36 MU: so you mean just pull together existing material, and not do new work? 17:29:43 RC: some new work will be necessary 17:30:15 GS: when this discussion happened before, authority issues, saying negative things is an issue. We want to leave this out. Debates led nowhere. 17:30:44 RC: some of this went into architecture for WWW document. 17:31:00 GS: is it ok to discuss what happens when an RDF query is posed? 17:31:06 RC: meaning is complicated 17:31:14 GS: how about 'operational meaning' 17:31:32 RC: is it the meaning? a hint? the social process? 17:31:49 GS: depends on discussions of semantics documents. 17:31:54 RC: this is what I want to avoid. 17:32:17 GS: yes ideally, but in reality, we may have to address it. 17:32:45 GS:if Pat Hayes were here, he would say it is important to say what it means. He may not be wrong, but it is a can of worms. 17:33:02 RC: technical issue likely to appear: how relate to RDF semantics 17:33:33 Suggest we include as inputs this one: http://dbooth.org/2010/ambiguity/ 17:34:12 and this one: http://dbooth.org/2009/lifecycle/ 17:35:14 natasha has joined #rdfn-lod 17:36:08 DB; 3 roles: author, owner, consumer, 17:36:45 RC: opinion.. probably better ideaa to define something along lines: given a URI, here is how I look it up and get an RDF graph back. FOr this we an avoid question of what the statements mean. 17:37:06 NN: Feeling lost. If I have a URI, then are we going to specify how it resolves to a specific location? 17:37:08 DB: that is one part. 17:37:39 GS: recipes for publishing vocabularies document is one technical baseline. It is a very practical document. 17:38:02 http://www.w3.org/TR/swbp-vocab-pub/ 17:38:03 RC: CoolURIs document is very similar. 17:39:05 GS: yesterday's paper reminded me of paper of Harry Halpern paper and Hayes on In Defense of Ambiguity. Need to see if this is relevant. 17:39:44 RC: two things. Can URI be more than just a string (ie has meaning). This is what I callcodifying follow your nose. Second thing is social meaning of what things refer to. 17:39:50 GS: maybe leave this out. 17:40:14 RC: DB wants this in. But I also want it out. Will nto work ast W3C reccomendation, too contentious. 17:40:34 GS: enormous can of worms, despite being very interesting issue. Not mature enough for standardization 17:40:53 RC: we want this as one item in the list. 17:41:01 GS: we are splitting into two issues. 17:41:13 DB: are yo suggest we only address responsibilities of URI owner? 17:41:39 RC: no, I suggest we explain how you can resolve a URI used in RDF into a graph tghat is an authoritative description of the URI. 17:42:00 GS: a technical recipe w/o any social implications of meaning. 17:42:28 NN: distinction between how to get to the graph and ? 17:43:49 GS: recipe is key here. Recipe for going from URI to a graph that the URI is intended to access. 17:43:55 NN: distinction between *how* to get to the graph describing the resources vs *what* hat description (graph) should contain 17:43:58 DB: 'authoritative' is a judgment 17:45:01 RC: it is an official W3C term, authoritative means the owner/controller of the host name of the URI. 17:45:26 DB: wha exactly are you including? A vocabulary that is well known and widely used. THen the domain goes out of business. What happens? 17:45:45 RC: this case we are not covering. There is no longer any authoritative description. 17:46:08 GS: are we not getting out of scope here? We onlyh have to consider the recipe for how you get the graph. REcipe is not on our place. 17:46:14 DB:that is one piece of the picture. 17:46:33 RC: follow your nose is EXACTLY this recipe. You cannot standardize. 17:46:44 DB: I disagree, you can use shoulds instead of musts and provide guidance. 17:47:37 GS: split into two items. 1) recipe to get graph and 2) intended meaning 18:08:36 RC; yo can tell your vendor her eis the spec,, buy something that does linked data properly 18:09:02 GS: we can use that as input for the first section 18:09:15 http://www.w3.org/2001/sw/wiki/RDF_Core_Charter_2010#Linked_Data 18:09:26 RC: i disagre. Tims document not a recipe for resolve URIs, it is general practice for creating a web using this mechanism. 18:09:36 GS: this is true, but not all about what RDF gropu is about. 18:09:47 RC: yes, this is why I say it is too broad. 18:10:05 GS: can we have the reference, we need to identify this as an input anyway. 18:10:27 RC: references are optional, good if we have them, but lets not chase references to see if we want to include them 18:10:47 DB: what is being suggested? Is overall objective of this breakout still to produce document with recommendations>? 18:11:10 RC: OK I propose doing nothing... If Sandro comes in, he can comment. Lets not second guess him. 18:11:22 TIM's LOD principles: http://www.w3.org/DesignIssues/LinkedData 18:11:27 DB do we eliminate line about producing document summarizing Linked Data principles? 18:12:13 DB:should I change codifies to 'supports'? 18:14:45 DB: how shall we word this? better specify? provide more guidance? 18:15:55 DB: we need to have better name for "follow your nose" 18:16:36 RC: I don't like word recipe, not convey enouhg. We already have it. We want to harden it into the infrastructure, beyond a mere reference. 18:16:44 DB: purpose is to find definition of URI, no? 18:18:07 RC: not quite. 18:19:48 GS: if you look up URI resource, you get back a graph. 18:20:01 DB: how you get a graph from a URI... http spec says how to do that. 18:20:08 GS: no it does not. 18:20:47 DB: we need to say why. 18:20:54 MU: agree, but why is different from what. 18:22:38 GS: if you go to a Wordnet URI now, you get a graph back. RC wants a formal/reliable/codified way to say what this means and how to do this. 18:23:37 MU; don't sue the phrase: "follow your nose" noone will know what it means, outside the community. 18:23:49 DB: no problem for us now, this will be sorted out later. 18:24:35 DB:why is this important? 18:25:25 RC: current practice is not reflected in the spec. The RDF spec just treats URIs as completely opaque, not reflect actual practice. They are dereferenced. 18:25:34 DB:any other reasons to do this now? 18:26:43 NN: codify that URIs should also be URLs. This is why do it now. 18:27:03 RC we need a clear story for this. 18:28:04 RC: we should not constrain what people do with RDF. Should allow URIs to be dereferencable or not. On the other hand, using www.google.com/blah/blah/blah is a very bad URI to use. 18:28:35 RC: not being codifeid means new work not taking it into account. 18:29:55 GS: there is a current practice that is not a part of the recomendations. We want it to be there to add clarity. 18:31:17 MU: current practice shojld be refelcted in recs, sure. But there are at least two cases: 1. current practice is a mess and causing problems and 2. current practis is just fine. For former case it is urgent to address. Less for for latter case. more about tidiness. 18:34:33 GS: current practice working fine, only if you view Web as static entity. As things evolve, current practice will not work. 18:34:37 reason for codifying follow-your-nose now: it provides a solid foundation on top of which to address issues like versioning etc 18:34:43 New person: DRAW: David Wood 18:35:35 Oops: DW: David Wood 18:39:52 DB: moving on to next issue: Intended meaning of a URI. IS ther a social contract, complete guidance. 18:40:22 RC: i believe this will not work, people will shred it apart,but we should anyway capture it as a possible work item. 18:40:33 DW: please explain again 18:42:13 DB: lifecycle of a URI. Owner mints a URI. Responsibilities when doing this. Also, RDF statement author. Using the URI when making a statement. statement author. ALso a consumer, someone that receives a graph with statements. Three roles: owner, author, user 18:44:02 DB: persons in each role have some responsibilities to make it all work properly. 18:44:16 DW: making a URI obsolete... if it is dereverencab.e, you get a 404 respons. 18:44:27 DB: other ways for a URI is obsolete. 18:44:39 DW: sure. 18:44:57 DB: there is at some point, a notion of a URI becoming obsolete, so there should be practices about this. 18:45:55 DW: also shodl be practices about URIs NEVER becoming obsolete. 18:46:44 DB: consumer needs way to know what statements mean. I.e. get the ontologies, get definitions of URIs being used, etc. 18:47:27 DW: how far to dig question is really central to how one is to follow your nose, not only standard web, but also semantic web. Now two choices: 1. not follow nose at all, or 2. follow nose completely. 18:47:37 RC: you can stop wheneve you want, application dependent 18:47:51 natasha has joined #rdfn-lod 18:48:03 DW: i see goals a defining goal in data so you can limit aribitrary application logic. Is there a way to leave some signposts in your data? 18:48:18 RC: good idea, how to interpret is still up to the consumer. 18:48:47 MU: huh? semantic is supposed to be about removing ambiguity. If consumre can have it mean whatever they want it to, bad idea. 18:49:27 DB: distinghish between 1) ability to accurately convey intended meaning of graph and 2) consumer decision of what to use. 18:51:01 DB: critical piece, you can have abaility of determining what he meant. 18:51:07 DW: there shold be signposts of rwhat things mean 18:51:16 RC: wrong place to have this discussion. 18:51:28 DB: people are already doing this. THere are.. 18:51:40 RC: i don't see why suddenly W3C should suddenly jump in... 18:51:48 DB: there is a lot of confusion. 18:51:58 RC: confusing because it is hard and needs research. 18:52:41 DW: this is a fair position. 18:53:20 MU: what we can do that is not research is summarize what is in fact going on at this time. Concise summary of the good, bad and ugly of current practice. 18:53:31 DW: things not being collated is what W3C could look into. 18:54:05 RC: this is very much an evolving topic. In one year, people will know a lot more than now. 18:54:14 DB: this is a good argument for not doing it now. 18:54:48 RC: if we standardize it now, it will be obsolete soon. This is a rapidly evolving topic. 18:55:05 DB: lets move on, just record that this is a reason for not doing this now. 18:55:29 RC: anyone can write these documents, anyone can write them, why should it be W3C? 18:55:39 DW: W3C papers are very helpful. 18:55:56 natasha_ has joined #rdfn-lod 18:56:07 GS: argument agains: it does not belong in RDF core. 18:56:51 DW: argument for, flip side, W3C cannot afford to do 2 WGs, so anythnig that needs to be done needs to go into this working group. 18:57:09 RC: this is a social contract, not a technical congtract and thus outside W3C 18:57:18 DB: WWW is about social contract. 18:57:38 GS: if this goes out to community, some will agree some now. 18:57:52 COrrection: "some now" --> "some not" 19:00:14 RC; fascinating topic, but should not be in W3C. 19:00:48 W3C should consider standardizing some properties for expressing co-reference between URIs, as alternatives to owl:sameAs. This kind of linking is core to the linked data practices. The strong semantics of owl:sameAs are often not appropriate, and the lack of a W3C-recommended alternative is a problem. The SKOS model with its model of gradual similarity (closeMatch, exactMatch) could be a starting point. A property for recoding a "sameTopic" relationship betwe 19:00:48 two documents would also be good. 19:02:01 DB: moving on: co-reference. identity 19:02:07 MU: reference: http://ontologydesignpatterns.org/wiki/Community:Overloading_OWL_sameAs 19:02:41 MU: another reference: http://ontologydesignpatterns.org/wiki/Community:Proliferation_of_URIs%2C_Managing_Coreference 19:11:48 DW: I have a graph, MU has a graph. I say two nodes are sameAs. Someone else disagrees. A query give wrong answers according to one of us. 19:12:01 GS: hijacking according to RC is complex issue. 19:12:23 RC: lets separate this from what we are talking about now. 19:13:55 DW: I want more OWL to capture the lack of similarity vocabulary. 19:14:38 GS: co-reference is common. 19:16:39 DW: work on now because it is being used more and more, deployments will be experiencing more and more difficulties. 19:17:56 NN: Don't need it, SKOS close match already here. 19:19:04 MU: but this is not argument to ignore it, we should put as a guideline when whether to use closeMatch vs. sameAs 19:21:44 DW: if you are in OWL world and discover two things are same, then you are socially obliged to use owl:sameAs. If you are in RDF world, you are not obliged to do so. 19:22:48 MU: another technical difficulty, choosing right set of terms, not too many to be too confusing, not too few which will allow same problem to continue, albeit to a less sever extent. 19:27:19 rrsagent, make logs public 19:27:35 ADJOURNED FOR LUNCH 19:27:37 rrsagent, draft minutes 19:27:37 I have made the request to generate http://www.w3.org/2010/06/27-rdfn-lod-minutes.html dbooth 20:36:24 cygri has joined #rdfn-lod 20:41:20 natasha has joined #rdfn-lod 20:55:48 dbooth has joined #rdfn-lod 20:56:05 s/rc, mu, nn, db, gs :)/Richard Cyganiak, Michael Uschold, Natasha Noy, David Booth, Guus Schreiber 20:56:12 rrsagent, draft minutes 20:56:12 I have made the request to generate http://www.w3.org/2010/06/27-rdfn-lod-minutes.html dbooth 21:47:46 dbooth has joined #rdfn-lod 21:48:51 cygri has joined #rdfn-lod 22:07:26 dbooth has joined #rdfn-lod 22:30:48 cygri has joined #rdfn-lod