Linked Data breakout -- 27 Jun 2010

RC: Richard Cyganiak

MU: Michael Uschold

NN: Natasha Noy

DB: David Booth

GS: Guus Schreiber

db: two topics: a) follow your nose and b) vocabulary for co-reference

MU: co-reference includes owl:sameAs issues

RC: third issue: document usage guidelines for vocabulary and linked data
... in other words, codifying the linked data principles

DB: lets start with the follow your nose issue, a hard one.
... what is it exactly?

<cygri> from my workshop submission:

<cygri> 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

<cygri> 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.

RC: RDF says nothing about URIs other than what it dereferenes to

GS: huge discussion in a tech plenary back in 03. Social meaning of URIs.
... what is the tech goal for this? CoolURIs?

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

GS: need to be more precise than that.

RC: not here, that is for the working group later

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.

RC: lets not do that now.

DB: we need to frame the issue now.

RC: I think obvious inputs are Architecture for WWW document, explains authoritative meaning, de-referencing, etc, CoolURIs.

<dbooth> Mike: there's also a big issue of overloading of URIs

MU: is this related to overloading URIs?

RC: 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.

<dbooth> dbooth: I think overloading is part of the issue.

MU: so you mean just pull together existing material, and not do new work?

RC: some new work will be necessary

GS: when this discussion happened before, authority issues, saying negative things is an issue. We want to leave this out. Debates led nowhere.

RC: some of this went into architecture for WWW document.

GS: is it ok to discuss what happens when an RDF query is posed?

RC: meaning is complicated

GS: how about 'operational meaning'

RC: is it the meaning? a hint? the social process?

GS: depends on discussions of semantics documents.

RC: this is what I want to avoid.

GS: yes ideally, but in reality, we may have to address it.
... 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.

RC: technical issue likely to appear: how relate to RDF semantics

<dbooth> Suggest we include as inputs this one: http://dbooth.org/2010/ambiguity/

<dbooth> and this one: http://dbooth.org/2009/lifecycle/

DB; 3 roles: author, owner, consumer,

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.

NN: Feeling lost. If I have a URI, then are we going to specify how it resolves to a specific location?

DB: that is one part.

GS: recipes for publishing vocabularies document is one technical baseline. It is a very practical document.

<cygri> http://www.w3.org/TR/swbp-vocab-pub/

RC: CoolURIs document is very similar.

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.

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.

GS: maybe leave this out.

RC: DB wants this in. But I also want it out. Will nto work ast W3C reccomendation, too contentious.

GS: enormous can of worms, despite being very interesting issue. Not mature enough for standardization

RC: we want this as one item in the list.

GS: we are splitting into two issues.

DB: are yo suggest we only address responsibilities of URI owner?

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.

GS: a technical recipe w/o any social implications of meaning.

NN: distinction between how to get to the graph and ?

GS: recipe is key here. Recipe for going from URI to a graph that the URI is intended to access.

<natasha> NN: distinction between *how* to get to the graph describing the resources vs *what* hat description (graph) should contain

DB: 'authoritative' is a judgment

RC: it is an official W3C term, authoritative means the owner/controller of the host name of the URI.

DB: wha exactly are you including? A vocabulary that is well known and widely used. THen the domain goes out of business. What happens?

RC: this case we are not covering. There is no longer any authoritative description.

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.

DB: that is one piece of the picture.

RC: follow your nose is EXACTLY this recipe. You cannot standardize.

DB: I disagree, you can use shoulds instead of musts and provide guidance.

GS: split into two items. 1) recipe to get graph and 2) intended meaning

RC; yo can tell your vendor her eis the spec,, buy something that does linked data properly

GS: we can use that as input for the first section

<dbooth> http://www.w3.org/2001/sw/wiki/RDF_Core_Charter_2010#Linked_Data

RC: i disagre. Tims document not a recipe for resolve URIs, it is general practice for creating a web using this mechanism.

GS: this is true, but not all about what RDF gropu is about.

RC: yes, this is why I say it is too broad.

GS: can we have the reference, we need to identify this as an input anyway.

RC: references are optional, good if we have them, but lets not chase references to see if we want to include them

DB: what is being suggested? Is overall objective of this breakout still to produce document with recommendations>?

RC: OK I propose doing nothing... If Sandro comes in, he can comment. Lets not second guess him.

<guus> TIM's LOD principles: http://www.w3.org/DesignIssues/LinkedData

DB do we eliminate line about producing document summarizing Linked Data principles?

DB: should I change codifies to 'supports'?
... how shall we word this? better specify? provide more guidance?
... we need to have better name for "follow your nose"

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.

DB: purpose is to find definition of URI, no?

RC: not quite.

GS: if you look up URI resource, you get back a graph.

DB: how you get a graph from a URI... http spec says how to do that.

GS: no it does not.

DB: we need to say why.

MU: agree, but why is different from what.

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.

MU; don't sue the phrase: "follow your nose" noone will know what it means, outside the community.

DB: no problem for us now, this will be sorted out later.
... why is this important?

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.

DB: any other reasons to do this now?

NN: codify that URIs should also be URLs. This is why do it now.

RC we need a clear story for this.

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.
... not being codifeid means new work not taking it into account.

GS: there is a current practice that is not a part of the recomendations. We want it to be there to add clarity.

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.

GS: current practice working fine, only if you view Web as static entity. As things evolve, current practice will not work.

<cygri> reason for codifying follow-your-nose now: it provides a solid foundation on top of which to address issues like versioning etc

<scribe> New person: DRAW: David Wood

Oops: DW: David Wood

DB: moving on to next issue: Intended meaning of a URI. IS ther a social contract, complete guidance.

RC: i believe this will not work, people will shred it apart,but we should anyway capture it as a possible work item.

DW: please explain again

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
... persons in each role have some responsibilities to make it all work properly.

DW: making a URI obsolete... if it is dereverencab.e, you get a 404 respons.

DB: other ways for a URI is obsolete.

DW: sure.

DB: there is at some point, a notion of a URI becoming obsolete, so there should be practices about this.

DW: also shodl be practices about URIs NEVER becoming obsolete.

DB: consumer needs way to know what statements mean. I.e. get the ontologies, get definitions of URIs being used, etc.

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.

RC: you can stop wheneve you want, application dependent

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?

RC: good idea, how to interpret is still up to the consumer.

MU: huh? semantic is supposed to be about removing ambiguity. If consumre can have it mean whatever they want it to, bad idea.

DB: distinghish between 1) ability to accurately convey intended meaning of graph and 2) consumer decision of what to use.
... critical piece, you can have abaility of determining what he meant.

DW: there shold be signposts of rwhat things mean

RC: wrong place to have this discussion.

DB: people are already doing this. THere are..

RC: i don't see why suddenly W3C should suddenly jump in...

DB: there is a lot of confusion.

RC: confusing because it is hard and needs research.

DW: this is a fair position.

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.

DW: things not being collated is what W3C could look into.

RC: this is very much an evolving topic. In one year, people will know a lot more than now.

DB: this is a good argument for not doing it now.

RC: if we standardize it now, it will be obsolete soon. This is a rapidly evolving topic.

DB: lets move on, just record that this is a reason for not doing this now.

RC: anyone can write these documents, anyone can write them, why should it be W3C?

DW: W3C papers are very helpful.

GS: argument agains: it does not belong in RDF core.

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.

RC: this is a social contract, not a technical congtract and thus outside W3C

DB: WWW is about social contract.

GS: if this goes out to community, some will agree some now.

COrrection: "some now" --> "some not"

RC; fascinating topic, but should not be in W3C.

<cygri> 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

<cygri> two documents would also be good.

DB: moving on: co-reference. identity

MU: reference: http://ontologydesignpatterns.org/wiki/Community:Overloading_OWL_sameAs
... another reference: http://ontologydesignpatterns.org/wiki/Community:Proliferation_of_URIs%2C_Managing_Coreference

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.

GS: hijacking according to RC is complex issue.

RC: lets separate this from what we are talking about now.

DW: I want more OWL to capture the lack of similarity vocabulary.

GS: co-reference is common.

DW: work on now because it is being used more and more, deployments will be experiencing more and more difficulties.

NN: Don't need it, SKOS close match already here.

MU: but this is not argument to ignore it, we should put as a guideline when whether to use closeMatch vs. sameAs

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.

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.

<dbooth> ADJOURNED FOR LUNCH

<dbooth> s/rc, mu, nn, db, gs :)/Richard Cyganiak, Michael Uschold, Natasha Noy, David Booth, Guus Schreiber

- DRAFT -

Linked Data breakout

27 Jun 2010

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output