Chatlog 2011-04-14

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

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

<sandro> Guest: Paul Groth
<sandro> Guest: Steven Pemberton
<sandro> Present: Ivan, Mischa, Dan_Brickley, Matheus, Peter, Jan, Baget, Humfrey, Yves, Cygri, Champin, Fabien, Steve, Matteo, Sandro, Wood, Guus
<sandro> Remote: AZ, Gavin, Zhe, Corby, MacTed, Pat, Tom, AlexHall, webr3, LeeF, manu, souri
02:28:54 <MacTed> MacTed has joined #rdf-wg
05:17:45 <mbrunati> mbrunati has joined #rdf-wg
05:21:57 <mbrunati> mbrunati has joined #rdf-wg
05:22:16 <mbrunati> mbrunati has left #rdf-wg
06:21:58 <pgroth> pgroth has joined #rdf-wg
06:47:46 <pgroth_> pgroth_ has joined #rdf-wg
06:51:46 <tomlurge> tomlurge has joined #rdf-wg
07:11:44 <danbri> danbri has joined #rdf-wg
07:13:25 <OlivierCorby> OlivierCorby has joined #rdf-wg
07:18:50 <FabGandon> FabGandon has joined #rdf-wg
07:20:56 <ivan> ivan has joined #rdf-wg
07:21:03 <tomayac> tomayac has joined #rdf-wg
07:21:55 <tomayac> bonjour monsieur!
07:24:23 <pgroth> pgroth has joined #rdf-wg
07:30:32 <AZ> AZ has joined #rdf-wg
07:31:34 <mbrunati> mbrunati has joined #rdf-wg
07:32:13 <pchampin> pchampin has joined #rdf-wg
07:33:17 <tomayac> "the conference is restricted at this time" => have the dial-in details changed? using rdfwg1# code
07:34:05 <FabGandon> should work but we haven't called yet and a number of participants are still missing in the room
07:34:26 <tomayac>  9:30 sharp-ish ;-)
07:34:27 <PatH> PatH has joined #rdf-wg
07:39:52 <Guus> Guus has joined #rdf-wg
07:40:04 <SteveH> SteveH has joined #rdf-wg
07:40:19 <Steven_> Steven_ has joined #rdf-wg
07:40:29 <Steven_> zakim, list
07:40:29 <Zakim> I see SW_RDFWG(RDFWG1)2:00AM active and no others scheduled to start in the next 15 minutes
07:40:43 <mischat> mischat has joined #rdf-wg
07:40:49 <FabGandon> we will have to do an adhoc teleconf the teleconf chanel is not available for today
07:41:10 <pfps> pfps has joined #rdf-wg
07:41:13 <Steven_> zakim, code?
07:41:13 <Zakim> the conference code is 733941 (tel:+1.617.761.6200 tel:+33.4.26.46.79.03 tel:+44.203.318.0479), Steven_
07:41:38 <FabGandon> trying again...
07:41:39 <cmatheus> cmatheus has joined #rdf-wg
07:41:40 <Steven_> zakim, who is on the call?
07:41:40 <Zakim> On the phone I see OlivierCorby, OlivierCorby.a, OlivierCorby.aa, OlivierCorby.aaa
07:41:41 <cygri> cygri has joined #rdf-wg
07:41:55 <davidwood> davidwood has joined #rdf-wg
07:42:13 <PatH> Same message here
07:42:23 <tomayac> same here
07:42:45 <davidwood> We're working on it - please stand by
07:42:56 <Steven_> zakim, room for 15 for 600 minutes?
07:42:58 <Zakim> ok, Steven_; conference Team_(rdf-wg)07:42Z scheduled with code 26631 (CONF1) for 600 minutes until 1742Z
07:43:06 <davidwood> We'll announce a new dial in code shortly
07:43:12 <FabGandon> dial 26631
07:43:18 <davidwood> PLEASE USE CONFERENCE CODE 26631
07:43:35 <Steven_> Steven_ has changed the topic to: CODE is 26631
07:43:41 <davidwood> Sorry for the confusion.  Our bridge was not configured as we expected.
07:44:04 <Steven_> zakim, who is on the call?
07:44:04 <Zakim> On the phone I see OlivierCorby, OlivierCorby.a, OlivierCorby.aa, OlivierCorby.aaa
07:44:21 <NickH> Good Morning!
07:44:25 <Steven_> zakim, this is rdf-wg
07:44:25 <Zakim> Steven_, this was SW_RDFWG(RDFWG1)2:00AM
07:44:27 <Zakim> ok, Steven_; that matches Team_(rdf-wg)07:42Z
07:44:33 <Steven_> zakim, who is on the call?
07:44:34 <Zakim> On the phone I see Meeting_Room, PatH, tomayac, OlivierCorby
07:44:40 <OlivierCorby> Hi, phone is ok now
07:44:48 <Zakim> +AZ
07:45:46 <PatH> Sound quality is rather poor today 
07:45:50 <FabGandon> scribe: Fabien
07:46:31 <gavinc> gavinc has joined #rdf-wg
07:46:40 <FabGandon> guus: identifying the 4 issues to be discussed
07:46:50 <Steven> 30, 31, 15
07:46:51 <FabGandon> ... 5 30 31 and 15
07:46:57 <gavinc> zakim, the code is?
07:46:57 <Zakim> I don't understand your question, gavinc.
07:47:01 <JFB> JFB has joined #rdf-wg
07:47:03 <Steven> zakim, code?
07:47:03 <Zakim> the conference code is 26631 (tel:+1.617.761.6200 tel:+33.4.26.46.79.03 tel:+44.203.318.0479), Steven
07:47:32 <FabGandon> cygri: 31 is a bit out of the list
07:47:52 <mischat> http://www.w3.org/2011/rdf-wg/track/issues/30
07:48:06 <FabGandon> davidwood: sugest we start with issue 30
07:48:06 <Zakim> +gavinc
07:48:07 <FabGandon> Topic: Four issues of "Named Graphs".
07:48:08 <FabGandon> subtopic: Aligning SPARQL notions and RDF 1.1 g-* notions.
07:48:18 <FabGandon>   ISSUE-30: How does SPARQL's notion of RDF dataset relate our notion of multiple graphs?
07:48:18 <trackbot> ISSUE-30 How does SPARQL's notion of RDF dataset relate our notion of multiple graphs? notes added
07:48:20 <Steven> s/sugest/suggest/
07:49:47 <mischat> http://www.w3.org/TR/rdf-sparql-query/#rdfDataset <-- sparql dataset as per rdf sparql query 1.0
07:50:23 <FabGandon>   Cygri : SPARQL defines Dataset as data data model used in SPARQL query i.e. collection of graph = one default graph and a set of named graphs <IRI,Graph>  
07:50:33 <tomayac> AZ: +1, sound is low quality :-(
07:50:47 <mischat> http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs/RDF-Datasets-Proposal
07:51:19 <FabGandon>   ... they use the term named graph and it is a g-snap in our terminology because immutable  
07:51:50 <pchampin> http://www.w3.org/TR/2009/WD-sparql11-update-20091022/#sec_graphStore
07:52:37 <PatH> +q
07:52:43 <FabGandon> ... graph store :"unlike an RDF dataset, named graphs can be added to or deleted from a graph store"
07:53:03 <FabGandon> ivan: the mutability is on the store not on the graph
07:53:47 <pchampin> pchampin has joined #rdf-wg
07:53:49 <FabGandon> ... are the graphs explicitly immutable ?
07:53:51 <PatH> sound quality is poor but usable
07:54:26 <FabGandon> cygri : the spec are not specific on this ; not really addressed
07:54:57 <Guus> q?
07:55:17 <FabGandon> ivan: IMO the dataset is a set of g-boxes
07:55:38 <Guus> zakim, who is here?
07:55:38 <Zakim> On the phone I see Meeting_Room, PatH, tomayac, OlivierCorby, AZ, gavinc
07:55:52 <FabGandon> cygri: the evaluation of a SPARQL query is defined against an immutable dataset  
07:56:00 <gavinc> gavinc has joined #rdf-wg
07:56:09 <davidwood> q+ to discuss graph store relationships to g-boxes and g-snaps.
07:56:34 <ivan> q?
07:56:39 <ivan> ack PatH 
07:56:42 <davidwood> ack PatH
07:56:47 <FabGandon> PatH: we shouldn’t be agnostic we should say what the graph is e.g. we should say it is a g-box that has a name  
07:57:25 <FabGandon> cygri: SPARQL uses the term named graph, the IRI is the name for the graph in SPARQL
07:57:59 <mischat> PatH: there is no need to introduce confusion 
07:57:59 <AZ> We can certainly see a SPARQL dataset as a snapshot of the graph store (the graph store is mutable but the snapshot is fixed to define what's the result of a query)
07:58:47 <FabGandon>   PatH: RDF should specify the semantic of names if there is to be an interpretation of that name
07:59:14 <FabGandon> ... if we don't we leave the question open to endless discussions.
07:59:53 <davidwood> +1 to PatH, in that if we define what we mean we won't have misunderstandings as we do with "information resource" or "what *is* RDF".
08:00:41 <JFB> +1 to PatH: if there is some specifing meaning to names, it must be formalized in RDF Semantics
08:00:42 <FabGandon> PatH: we need to declare in a declarative text what the interpretation is for the IRI naming a graph.
08:01:34 <FabGandon> cygri: Can we use the name of doc as the name of graph.  
08:01:44 <FabGandon> PatH: we can't prevent that
08:03:10 <Zakim> davidwood, you wanted to discuss graph store relationships to g-boxes and g-snaps.
08:03:57 <FabGandon> davidwood: several graph stores are maintainers of g-boxes implemented as multiple reader single writer
08:04:38 <FabGandon> ... when a query comes in they generate sets of g-snaps from the current state of the g-boxes.  
08:05:12 <FabGandon> SteveH: yes that's what happens.
08:05:30 <PatH> we have yet to specify what a g-box is semantically. We will have to speak of states and g-snaps there.
08:06:22 <PatH> in other words, this box/snap issue will have to be dealt with there in any case.
08:06:31 <sandro> guus: When you do a SPARQL Query, you are querying at a point in time, so you are querying against the set of g-snaps which is the current contents of those g-boxes.
08:06:32 <FabGandon> Guus: at that point there is no conflict between our view and SPARQL
08:06:40 <davidwood> PatH: Yes
08:06:56 <davidwood> Yes, there is no conflict.
08:07:00 <FabGandon> subtopic: relation between the graph and its name.
08:07:40 <sandro> pchampin: I want to be able to use my own arbitrary data as the "graph" name in SPARQL.
08:08:00 <FabGandon> pchampin: I feel uncomfortable with fixing the semantics of the relation name of graphs  and the store ; it depends on my use of the quadstore
08:08:57 <FabGandon> cygri: I don’t see this machinery as answering a large demand ; I don’t feel there is a huge demand on fixing that semantics
08:09:27 <FabGandon> ... what do we gain from defining the interpretation of named graphs ?
08:09:56 <pchampin> sometimes, I name a graph in my quad store with the URI of the g-box this graph comes from,
08:10:08 <pchampin> sometimes, I name it with the URI of the resource it is about
08:10:09 <FabGandon> danbri: are you confortable with the level of interoperability that would set?
08:10:36 <sandro> +1 danbri we need more interop between datastores (there is breakage when people use different styles of URIs)
08:11:10 <pfps> I don't know how the RDF semantics is going to speak to things like timestamping downloads of RDF documents.
08:11:38 <FabGandon> PatH: defining the semantics will not have so much implication on the implementation that seems to be feared. The idea is not to interfere with the machinery.
08:11:42 <davidwood> ack PatH
08:11:46 <danbri> it's something like a lack of mechanism for saying how *my* sparql store is managed. One might use 'the URI I fetched = the graph URI', another uses a uuid: per-transaction, and a table-of-contents history graph. Sure I can send SPARQL queries across both at same time, but the results might be barely meaningful.
08:13:10 <FabGandon> sandro: the machinery will complain for instance if I use the URI of a graph to identify a person and these classes are disjoint.
08:13:59 <danbri> PatH, the triples could have semantics, but their bundling and tagging with graph URIs could lack semantics
08:14:03 <pchampin> q+ to talk about named graphs in SPARQL endpoints
08:14:10 <FabGandon> SteveH: there are many use cases where we don't want to do some logical inference on top of RDF.
08:14:53 <pchampin> +1 danbri: I write no *triple* stating that a person is a graph :-)
08:15:01 <sandro> Pat: It violates the semantics of the language to have the name of a graph also be the name of a person.
08:15:15 <FabGandon> cygri:   How does the fact of using a URI for a graph and a person raises a problem in SPARQL?
08:15:20 <AZ> A name can name several things, like in OWL 2 DL, a name can name a class and a property
08:15:38 <pgroth> could we do both? a name and a tag?
08:15:40 <AZ> and classes are disjoint from properties in OWL 2 DL
08:15:42 <FabGandon> PatH: lets not call it the names then.
08:16:43 <sandro> +1 pat
08:16:51 <FabGandon> pfps: RDF is agnostic as to the use of the same IRI to name a graph or a person.  
08:16:51 <ivan> ack pchampin 
08:16:51 <Zakim> pchampin, you wanted to talk about named graphs in SPARQL endpoints
08:17:21 <sandro> pchampin: I'm using the "graph id" as merely a "tag"
08:17:38 <FabGandon> pchampin: ok to say it’s not really a name but merely a tag.  
08:18:07 <sandro> +100000 the world here would be MUCH CLEARER if SPARQL forced you to only use graph IDs that you own!!
08:18:24 <cygri> sandro -100000
08:18:56 <pfps> sandro - so you think that you shouldn't use "anyone else's"  IRIs in a named graph?
08:19:03 <cygri> q+ to disagree with sandro -- web crawling use case
08:19:34 <FabGandon> sandro: I wish SPARQL restricted you to use only URIs that you own i.e. use graphs in a domain you control
08:20:01 <danbri> sandro, that feels to me like having the SQL spec specify that you can only store things that are true
08:20:09 <pchampin> I sure was not suggesting to restrict SPARQL... :-/
08:20:35 <pchampin> just pointing out that its flexibility allows for different practices... beyong "naming according to Pat"
08:20:41 <FabGandon> cygri: strong use case against that : when you crawl the web you want to use the URI from where you got the data.
08:21:17 <FabGandon> sandro: it may be more efficient but you create interoperability problems.
08:21:34 <sandro> Utility is at odds with Interoperability.
08:21:37 <PatH> hard to hear..
08:21:44 <sandro> Local utility vs Global utility.
08:21:53 <yvesr> another use case is ACL on quad stores
08:22:15 <FabGandon> pchampin: not suggesting restricting what SPARQL allows to do ; just advocating flexibility.
08:22:41 <cygri> q+ to talk about n3
08:22:44 <FabGandon> pgroth: I wonder if we don't need a typing mechanism.
08:22:44 <sandro> pgroth: There's "naming graph" and there's graph tags.
08:22:55 <Zakim> cygri, you wanted to talk about n3
08:23:39 <FabGandon> cygri: if you want a graph associated with a URI in N3 you need to put a predicate in-between.
08:24:09 <danbri> is this OK SPARQL? http://pastebin.com/raw.php?i=TaJVsste
08:24:19 <FabGandon> ... there is something in the middle that indicates the relation, don't restrict that because in SPARQL it is not restricted.
08:25:19 <yvesr> danbri, i guess it would - why wouldn't it?
08:25:42 <FabGandon> pfps: in RDF everything is a resources: a graph must be an resource or not ; how can we disconnect graph from that if we name them with IRI?
08:26:01 <danbri> q+ to try http://pastebin.com/raw.php?i=TaJVsste 
08:26:52 <FabGandon> Guus: we need to identify the things we do agree on.
08:26:55 <Zakim> danbri, you wanted to try http://pastebin.com/raw.php?i=TaJVsste
08:27:14 <PatH> sounds like a sparql RDF dataset is not a collection of named graphs. Which surprises me, but I can live with.
08:27:20 <FabGandon> danbri: I want to talk about this test case  http://pastebin.com/raw.php?i=TaJVsste
08:28:14 <FabGandon> ...   this is a SPARQL query querying different databases.
08:28:36 <FabGandon> ... can we name graphs with mailto:bla@bla.bla
08:28:38 <PatH> but see what pat just wrote.
08:29:08 <FabGandon> yes we can
08:29:37 <FabGandon> davidwood: some people say we should always use http://
08:29:55 <FabGandon> danbri: there is a drift from using http:// URIs
08:30:07 <FabGandon> SteveH: I don't see anything wrong with that.
08:30:25 <sandro> sandro: This is just neats vs scruffies --- the graph might be a (scruffy) tag, or might be a name of a proper RDF graph.
08:30:29 <FabGandon> danbri: what about the provenance perspective?
08:30:34 <pfps> well, a SPARQL RDF dataset is defined as potentially containing "named graphs"  as this is the first (as far as I know) W3C mention of "named graph", then SPARQL wins and SPARQL RDF datasets have named graphs
08:31:10 <pfps> the upshot of this is that the RDF WG may need a new name for what we have been calling named graphs
08:31:27 <FabGandon> pgroth: we care about pointing at a resource or at a graph talking about a resource.
08:31:37 <FabGandon> ... we need to be able to point at the content.
08:32:04 <PatH> pfps, suggest rather we keep named graphs but allow datasets to be something else.
08:32:30 <danbri> so my example lets me represent the (likely derrived from other stuff) info that Pat says Guus is the name of the holder of his homepage
08:32:52 <pfps> then we need to quickly get SPARQL not to "use up" this name - oops too late, named graphs is already in SPARQL 1.0
08:33:40 <pgroth> i like the idea of a default interpretation
08:33:47 <FabGandon> pchampin: graphs are resources they need naming and not necessarily a named attached to a SPARQL endpoint.
08:33:51 <pgroth> that the iri is the name of the graph
08:34:10 <SteveH> q+ to talk about <uri> :relation <graph>
08:34:33 <FabGandon> pfps: do RDF graphs have to be resources ?
08:34:55 <danbri> http://www.w3.org/TR/rdf-mt/#gloss ''Resource (n.)(as used in RDF)(i) An entity; anything in the universe. (ii) As a class name: the class of everything; the most inclusive category possible.''
08:35:09 <PatH> aaaargh. what are 'levels'????
08:35:16 <FabGandon> cygri: graphs are in the abstract syntax; resources are in the model theory
08:36:18 <FabGandon> pchampin: graphs must be resources
08:36:23 <sandro> pfps: We have A and Not-A   (where A=Graphs are Resources)
08:37:20 <sandro> pat: Of COURSE graphs are resources.   The model theory clearly says everything is a resource.
08:37:26 <JFB> +1 everything is a resource, if I am, why wouldn't a graph be ?
08:37:28 <FabGandon> PatH: there are no such notions of levels ; thats not the pb.
08:37:50 <pchampin> +1
08:37:54 <sandro> pat: We could say that SPARQL Datasets are about tagged graphs NOT naming.
08:37:55 <SteveH> +1
08:37:57 <sandro> +1 pat
08:37:59 <mischat> +1
08:38:00 <danbri> +1
08:38:12 <yvesr> +1
08:38:24 <danbri> q+ to suggest [eventual] best practice note on how *in practice* people are associating URIs with bundles-of-triples
08:38:34 <FabGandon> ... if we say we tag graphs and not we name then we can stop arguing 
08:39:02 <AZ> But then, how one talks about a graph in triples?
08:39:29 <FabGandon> davidwood: I need a clarification on the difference between the name and a tag.
08:39:30 <ivan> ack SteveH 
08:39:30 <Zakim> SteveH, you wanted to talk about <uri> :relation <graph>
08:40:14 <FabGandon> PatH: the difference is in the relation, tag is neutral.
08:40:16 <danbri> 'bundles'
08:40:30 <pgroth> why can't we have a default interpretation ?
08:40:48 <sandro> possible consensus: SPARQL "named graphs" are not "named" in the logical sense.
08:40:58 <cygri> +1 ivan
08:40:59 <danbri> pgroth, because there are multiple equally respectable default db management habits
08:41:27 <gavinc> FROM NAMED
08:42:01 <sandro> :'(''
08:42:20 <FabGandon> ivan: we don't have much choice, the term "named graph" is already used in the whole SPARQL community.
08:42:40 <pgroth> danbri, but default doesn't mean you have to
08:43:14 <sandro> sandro: Can we at least tell people this is a misleading name?
08:43:19 <SteveH> +1
08:43:56 <PatH> potentially misleading
08:44:02 <danbri> From a SPARQL perspective, it is legitimate to (a) tag graph-bundles with URI the triples were dereferenced from (b) to tag graph-bundles with URI for the party who made the claim (c) or a trasaction ID, eg. uuid:
08:44:13 <sandro> More Consensus: SPARQL "named graphs" are not necessarily "named" in the logical sense, or RDF graphs.
08:44:25 <sandro> FabGandon we have "tagged boxes" and we will call them "named graphs"
08:44:38 <pchampin> q+ to raise some concern about the semantics of NQuads, then
08:44:49 <Zakim> danbri, you wanted to suggest [eventual] best practice note on how *in practice* people are associating URIs with bundles-of-triples
08:44:56 <PatH> can we introduce the terminology of "sparql naming"
08:45:12 <davidwood> q+ to as about naming of RDF
08:45:26 <FabGandon> danbri: may be we should first document the current uses of "named graphs"
08:45:40 <mischat> q+ to ask about the difference in FROM NAMED and the GRAPH URI
08:45:52 <yvesr> +1
08:45:57 <sandro> +1 danbri: document the common practices for using sparql graphs names.
08:45:58 <PatH> I dont want to start policing sparql usage.
08:46:09 <FabGandon> ... I have three in mind but may be we should have a wiki page to collect them
08:46:12 <davidwood> No, we certainly don't
08:46:13 <danbri> path --- absolutely not policing, but documenting
08:46:17 <yvesr> PatH, not policing, surevying what's actually happening
08:46:18 <PatH> just keep terminology clean
08:46:22 <PatH> OK
08:46:27 <danbri>  -- so we can send SPARQL queries that use GRAPH to services managed in a certain fashion
08:46:51 <FabGandon> pchampin: NQuads is used to dump a full store
08:46:55 <danbri> eg. see http://pastebin.com/TaJVsste ... maybe you have a DB I could usefully send that query to; but maybe Ivan's SPARQL db is managed with a different GRAPH/URI policy
08:47:02 <danbri> ...so naming those deployment patterns
08:47:02 <mischat> i do think that best practices for linked data re: graphs and named graphs
08:47:03 <Zakim> davidwood, you wanted to as about naming of RDF
08:47:05 <FabGandon> ivan: NQuad is juts syntax
08:47:06 <Zakim> pchampin, you wanted to raise some concern about the semantics of NQuads, then
08:47:20 <danbri> FDR!
08:47:39 <FabGandon>  davidwood: concerned about redefining everything.
08:48:09 <FabGandon> sandro: SPARQL named graphs has little to do with named g-boxes.
08:48:13 <ivan> ack mischat 
08:48:13 <Zakim> mischat, you wanted to ask about the difference in FROM NAMED and the GRAPH URI
08:48:23 <FabGandon>  Guss: SPARQL is agnostic about.
08:49:04 <FabGandon> mischat: It is nice that SPARQL doesn’t force you to use the URL of the doc for the named graph.
08:49:23 <sandro>  steve: FROM NAMED pulls a graph from some undefined place and puts it in the set of named graphs, but... [lost]
08:50:05 <FabGandon> SteveH: the exact behavior of the default graph changes from store to store.
08:50:25 <cygri> +1 mischat
08:50:32 <yvesr> +1
08:50:42 <danbri> yup
08:50:59 <FabGandon> mischat: the best practices could be in a note and not in rec.
08:51:54 <FabGandon> davidwood: we don't want to get in the way of LOD
08:51:57 <raphael> raphael has joined #rdf-wg
08:53:06 <FabGandon> ivan: too early to phrase it as a resolution ?
08:53:11 <sandro> PROPOSED: Close ISSUE-30 saying that SPARQL Datasets and Named Graphs have no strict or formal connection to a logic of RDF "naming" of Graphs.
08:53:29 <pfps> PROPOSED the upcoming notion of multiple graphs is not necessarily the same as named graphs in SPARQL
08:53:49 <danbri> perhaps  - SPARQL quads are not the kinds of thing that can be interpreted as True vs False; RDF WG quads might or might not add more...
08:54:11 <PatH> suggest that the key point is that just because sparql uses a uri to, um, identify a graph, it does not mean that the uri can be used to refer to the graph  in an rdf triple.
08:54:52 <FabGandon> ivan: we currently have no formal connection between the name and the graph in RDF
08:54:53 <danbri> ie. we can ask if the triple "uri-for-guus :homepage http://www.cs.vu.nl/~guus/" is true or not; but we can't yet ask if the quad  "{uri-for-graph} uri-for-guus :homepage http://www.cs.vu.nl/~guus/" is true or false
08:55:32 <AZ> PatH +1
08:55:42 <danbri> (path, +1 to what?)
08:55:53 <FabGandon> Guus: who agrees with PatH ?
08:56:13 <AZ> +1
08:56:26 <FabGandon>   PatH: you can use the URI but there is no guaranty that it refers to the graph.  
08:56:27 <sandro> sandro: Pat means "refer" in a model theory sense, not a computer science sense.
08:57:05 <gavinc> So what does: SELECT ?s WHERE {GRAPH ?s { ?s ?p ?o }} end up meaning in this case?
08:57:17 <FabGandon> yvesr: we don't know what a multiple graph is and therefore can we talk about it in a resolution?
08:57:56 <zwu2> zwu2 has joined #rdf-wg
08:58:25 <FabGandon> ivan: when we have clarified notions then we can come back to that question.
08:58:28 <yvesr> we can't resolve an issue where half of the question is still undefined
08:58:56 <PatH> i like 'thruth'
08:59:07 <FabGandon> ... the issue should be postponed.
08:59:11 <danbri> quadly thruthyness 
08:59:22 <ivan> rrsagent, pointer?
08:59:22 <RRSAgent> See http://www.w3.org/2011/04/14-rdf-wg-irc#T08-59-22
08:59:22 <PatH> :-)
08:59:32 <FabGandon> Guus: we can close that issue and open and more precise one.
08:59:37 <JFB> +1 for semantics of a predicate that would capture SPARQL's behaviour, but we're not ready yet for that
08:59:54 <yvesr> issue-30 might be dependent on issue-15
09:00:36 <FabGandon> pchampin: this question is linked to issue 15 http://www.w3.org/2011/rdf-wg/track/issues/15
09:00:44 <sandro> issue-15?
09:00:44 <trackbot> ISSUE-15 -- What is the relationship between the IRI and the triples in a dataset/quad-syntax/etc -- open
09:00:44 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/15
09:00:45 <mischat> again, you could have a best practices document stating how you can use named graphs in a quad store in a truthy way, but neither rdf nor sparql mandates this, but it would be a good thing for quad store/linked data interoperability -- would be a good note for a primer 
09:02:00 <FabGandon> Guus: 30 is about alignment with SPARQL and 15 is about our internal changes to RDF.
09:02:31 <FabGandon> ... in solving issue 15 we should not conflict with SPARQL. 
09:02:37 <PatH> yes, fine
09:02:53 <PatH> yes, 
09:03:14 <PatH> sorry cant unmute but agree with what you are saying
09:03:26 <FabGandon> Guus: we should remove dataset from issue 15 this is addressed in issue 30
09:03:47 <sandro> PROPOSED: ISSUE-15 is about our internal notions of multiple graphs, while ISSUE-30 is about how that related to SPARQL's notion.  We do not expect the association of IRIs and graphs in SPARQL datasets to be RDF's identification/reference relationship.
09:04:03 <FabGandon> davidwood: etc. is not precise enough , issue 15 should be rephrased properly
09:04:48 <danbri> proposed: "While it is attractive to seek more clarity on relationship between some graph of triples and URIs they're tagged with, ... we note that SPARQL deployments have assigned URIs in a variety of ways, each of which being useful and compliant. There may be value in documenting these deployment styles (e.g. URIs for docs, abstract graphs, human sources or transaction IDs) so that SPARQL stores and serializations of URI-tagged triples can b
09:04:48 <danbri> e made more richly interoperable."
09:05:02 <FabGandon>   Guus: we should start with defining our own terminology before aligning with SPARQL.
09:05:11 <cygri> proposed: "Named Graphs in SPARQL “loosely associate” IRIs and graphs. They do not “name” graphs in the strict model-theoretic sense. A SPARQL Dataset does not establish graphs as referents of IRIs."
09:06:20 <FabGandon>  ISSUE-30: cygri proposes "Named Graphs in SPARQL “loosely associate” IRIs and graphs. They do not “name” graphs in the strict model-theoretic sense. A SPARQL Dataset does not establish graphs as referents of IRIs."
09:06:20 <trackbot> ISSUE-30 How does SPARQL's notion of RDF dataset relate our notion of multiple graphs? notes added
09:07:12 <danbri> i tried ' each of which being useful and compliant' instead of 'loosly' (above)
09:07:23 <sandro> "are simple associations"
09:07:35 <AZ>  Maybe: "Named Graphs in SPARQL associate IRIs and graphs *but* they do not “name” graphs in the strict model-theoretic sense. A SPARQL Dataset does not establish graphs as referents of IRIs."
09:07:42 <FabGandon>   PatH: don't like the word "loosely" prefer : temporary
09:08:14 <sandro> PROPOSED: Named Graphs in SPARQL associate IRIs and graphs *but* they do not “name” graphs in the strict model-theoretic sense. A SPARQL Dataset does not necessarily establish graphs as referents of IRIs
09:08:35 <AZ> I would not put the necessarily there
09:08:51 <mischat> SteveH: sparql uses the verb "graph" to talk about arbitrary graphs and the "named graphs" for graphs which which can be fetched via http, or is that just my pov?
09:09:03 <sandro> PROPOSED: Named Graphs in SPARQL associate IRIs and graphs *but* they do not necessarily "name" graphs in the strict model-theoretic sense. A SPARQL Dataset does not establish graphs as referents of IRIs
09:09:10 <sandro> +1
09:09:14 <pfps> +1
09:09:15 <cygri> +1 sandro
09:09:16 <AZ> +1
09:09:16 <mbrunati> +1
09:09:20 <pchampin> +1
09:09:23 <davidwood> +1
09:09:24 <cmatheus> +1
09:09:26 <yvesr> +1
09:09:27 <danbri> +1
09:09:32 <zwu2> +0
09:09:33 <NickH> +1
09:09:38 <SteveH> +1
09:09:51 <mischat> +1
09:10:04 <mischat> any objections for this being added as a note to issue-30 ?
09:10:04 <FabGandon>  ISSUE-30: Proposed WG position : Named Graphs in SPARQL associate IRIs and graphs *but* they do not necessarily “name” graphs in the strict model-theoretic sense. A SPARQL Dataset does not establish graphs as referents of IRIs.
09:10:04 <trackbot> ISSUE-30 How does SPARQL's notion of RDF dataset relate our notion of multiple graphs? notes added
09:10:07 <sandro> RESOLVED: Named Graphs in SPARQL associate IRIs and graphs *but* they do not necessarily "name" graphs in the strict model-theoretic sense. A SPARQL Dataset does not establish graphs as referents of IRIs (relevant to ISSUE-30)
09:10:31 <cygri> ISSUE-15?
09:10:31 <FabGandon> subtopic: link between the name and the triples of the graph.
09:10:31 <trackbot> ISSUE-15 -- What is the relationship between the IRI and the triples in a dataset/quad-syntax/etc -- open
09:10:31 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/15
09:10:56 <PatH> +1 also my vote
09:11:11 <FabGandon> davidwood: moving to ISSUE 15 ; let's try to rephrase it.
09:11:41 <AZ> AZ: isn't it implicitly asking "how" one can associate a URI to a g-* ?
09:12:00 <PatH> propose, uri always refers to g-box, but some boxes are immutable.
09:12:12 <pgroth> agree with pat
09:12:16 <FabGandon> sandro: g-boxes, g-snap, g-text could be named
09:12:48 <PatH> because a snap is always a state (of a box) rather than a resource in its own right.
09:12:48 <FabGandon> ivan: can we have a predicate to say this IRI identifies this g-box ?
09:13:15 <pgroth> although i need to refer to a g-snap
09:13:51 <pchampin> PatH: can't a number have a URI ??
09:14:06 <FabGandon> pgroth: would that prevent you to refer to a particular state of a box ?
09:14:22 <PatH> dont think it can be done just using a predicate unless we endow that predicate with spoecial semantic force.
09:14:37 <danbri> (around foaf/webid/foaf+ssl and so on, we'll start seeing people identifying concrete sets of well known triples by hash of their encoding, eg. the triples W3C served for the RDF ns for the last 5 years)
09:15:00 <FabGandon> ivan: the snap vs. box is exactly about mutability
09:15:03 <pchampin> PatH??: <someuri> owl:sameas 42
09:15:57 <PatH> sure, that is ok, but states are transient.
09:16:28 <FabGandon> davidwood: if a g-box is a resource than we can talk about it.
09:16:49 <sandro> q+ to say the difference
09:16:59 <FabGandon> pgroth: so what is a snap then if not an immutable box ?
09:17:29 <FabGandon> sandro: another difference is equality.
09:17:45 <gavinc> The NAME is not part of the g-snap
09:17:54 <danbri> sandro, does that work ok w/ bnodes? do we have samegraphness defined adequately for graphs w/ bnodes?
09:18:14 <FabGandon> davidwood: two g-snaps may have the same content and still be different snaps.
09:18:27 <FabGandon> ... we haven't decided on that yet.
09:18:50 <sandro> danbri, yes, but you also have to allow bnodes to be shared between graphs.
09:18:51 <FabGandon> ... it depends on how we resolve issue 15
09:18:53 <SteveH> q+ to ask Sandro about why two g-boxes can't be equal [unless I got the wrong end of the stick]
09:19:16 <gavinc> ... I don't think g-snaps had names?
09:19:42 <PatH> stephen, two anythings cannot be equal. 
09:19:54 <davidwood> ack sandro
09:19:54 <Zakim> sandro, you wanted to say the difference
09:19:55 <sandro> ack sandro
09:19:57 <ivan> ack sandro 
09:19:58 <davidwood> ack PatH
09:20:03 <danbri> (sandro, eg. if there is an rdf/xml file bundled with Jena that is packaged old version of DC schema; and the similar-but-different triples we get from a DCMI namespace URI fetch ... )
09:20:10 <FabGandon> subtopic: REST and named graphs.
09:20:39 <FabGandon> PatH: The guiding abstraction should be the REST model
09:21:54 <FabGandon> davidwood: reprensentations are not resources by default
09:22:04 <davidwood> ack pchampin
09:22:08 <ivan> ack PatH 
09:22:13 <sandro> it's the g-text that's the representation, not the g-snap.
09:22:29 <FabGandon> sandro: the representation is the g-text, a string
09:22:33 <danbri> PatH, does "is not a resource" there mean "not a Web/http resource" rather than "is not a resource-considered-as-synonym-for-thing"?
09:22:46 <danbri> (if you can channel for timbl...)
09:22:46 <FabGandon> pchampin: the g-snap is the state of the resource
09:22:51 <yvesr> g-box - resource ; g-snap - state ; g-text : representation
09:22:58 <pgroth> g-box = resource, g-snap = content negotiation, g-text = state serlization
09:22:58 <PatH> sorry, sandro is right. but the snap is an abstraction/parsing of the text.
09:23:01 <mischat> g-snap is information resource at time T ?
09:23:10 <davidwood> ack pgroth
09:23:15 <ivan> ack pgroth 
09:23:30 <PatH> and so is similarly unidentifiable.
09:23:36 <JFB>  g-snap: state of the resource or state of the representation ?
09:23:48 <PatH> yes, sandro is right.
09:23:54 <yvesr> pgroth: i don't agree - g-snap != content-negotiation
09:23:54 <pchampin> @JFB: state of the resource 
09:24:06 <yvesr> s/pgroth:/pgroth,/
09:24:17 <FabGandon> cygri: you can't talk about the representation.
09:24:49 <sandro> q?
09:24:56 <PatH> danbri, i want those to be the same sense of resource
09:25:15 <FabGandon> davidwood: a representation is not a resource but with an additional step you can choose to make an identifier for that representation and talk about it.
09:25:28 <pchampin>  data: URIs ?
09:25:34 <pchampin> I mean "data colon URIs"
09:25:38 <davidwood> ack SteveH
09:25:38 <Zakim> SteveH, you wanted to ask Sandro about why two g-boxes can't be equal [unless I got the wrong end of the stick]
09:27:18 <sandro> sandro: Two g-boxes remain distinct even though their contents/state might happen to be the same at some point in time.
09:27:42 <FabGandon> q?
09:27:51 <PatH> sandro, sorry to introduce extra confusion.
09:28:33 <PatH> +1 to pfps
09:28:37 <sandro> q+ to talk about use cases
09:28:54 <FabGandon> pfps: We could say we don’t change the semantics, Quads are syntax
09:29:34 <mischat> i like the idea that RDF semantics not changing, and using quads as syntax, +1 to pfps 
09:29:44 <PatH> i think there are now also quints, sexts, etc..
09:29:45 <danbri> I can't understand how the same meeting can, 30 mins ago, accept resources=all things in the universe, yet 5 mins ago, deny that the stuff you get back from an HTTP request is a resource. Ug.
09:30:01 <sandro> pchampin, you're right, I think, that data: URIs give us identifiers for representations / g-texts.
09:30:25 <danbri> (even without handy URIs they're still things and therefore Resources in rdfsemantics sense)
09:30:27 <FabGandon>   ... RDF semantics defines the meaning of the underlying data structure but not augmented with a semantics for datasets.
09:30:48 <sandro> danbri, we didn't agree with that -- it was just claimed and ignored.  :-)
09:31:47 <pfps> so, after all the stuff that I said, I still remain agnostic as to which direction to go
09:32:00 <FabGandon> subtopic: defining Graph primitives in RDF semantics.
09:32:34 <FabGandon> ivan: if we have predicates to link IRI and g-* we need to define them in the RDF semantics
09:33:14 <PatH> yes, we do. so the semantics will have to deal with the *-ideas.
09:33:36 <PatH> yes, exactly.
09:33:47 <FabGandon> pfps: if you want to talk about this inside the RDF voc you have to define it in the RDF semantics indeed.
09:33:59 <PatH> +1
09:34:06 <pfps> from an OWL perspective, the "don't change the semantics view" is very seductive
09:34:25 <SteveH> also from the DB implementors view
09:34:42 <PatH> extend does not imply change, hoever.
09:34:45 <sandro> ISSUE: Should there be an rdf:Graph construct, or something like that?
09:34:46 <trackbot> Created ISSUE-35 - Should there be an rdf:Graph construct, or something like that? ; please complete additional details at http://www.w3.org/2011/rdf-wg/track/issues/35/edit .
09:34:46 <FabGandon> Guus: should there be an rdf:Graph primitive ?
09:35:00 <sandro> (from Guus and David -- I don't understand the question.)
09:35:23 <Zakim> sandro, you wanted to talk about use cases
09:35:40 <FabGandon> pfps: if g-boxes just want to have fun they need to be in the semantics.
09:37:06 <FabGandon> sandro: one of the scenarios is "annotating graphs" e.g. be able to select a part of graph state things about it.
09:38:26 <FabGandon> pchampin: we need a vocabulary for the g-* e.g. just to be about to talk about them when we load them.
09:39:44 <FabGandon> PatH: if the notion of g-box is important then the semantics has to clarify that notion it does not need to be a revolution.
09:39:50 <FabGandon> subtopic: REST and Named graphs (bis).
09:39:52 <pfps> perhaps, but by this same argument, the semantics should specify what happens when you go an HTTP get on a URL
09:40:07 <mischat> i am not sure about the adoption rate of '<> rdf:type rdf:Statement.' , do people even ever use them ...
09:40:19 <PatH> not that bad, peter...
09:40:58 <sandro> PROPOSED: We aligned g-* with REST, where g-box=information resource, g-snap=state of the resource, g-text=representation of the state of the resource
09:41:07 <FabGandon> cygri: documenting the alignment with REST may be useful for us but not in the deliverables ; it is too complex and time-consuming.
09:42:02 <FabGandon> ivan: would lead to endless discussions.
09:42:18 <sandro> PROPOSED: We understand that g-* aligns with REST, with g-box=information resource, g-snap=state of the resource, g-text=representation of the state of the resource
09:42:53 <pchampin>  NB: a predicate would not state the relation between a URI and a graph, but between a resource (identified by a URI) and a graph
09:43:22 <PatH> i think we will be doing the world a disservice if we leave ambiguity and confusion. That is what the last RDF WG did, but there is a decade of practice now to guide us.
09:43:33 <mischat> sandro, perhaps s/state of the resource/state of the resource at time t/
09:43:35 <pfps> do we have a failrly coherent document that describes REST?
09:43:58 <sandro> PROPOSED: We understand that g-* aligns with REST, with g-box=information resource, g-snap=state of the resource (at time t), g-text=representation of the state of the resource (at time t)
09:44:03 <PatH> zakim, mute me
09:44:03 <Zakim> PatH should now be muted
09:44:21 <sandro> +1
09:44:22 <pfps>  NB:  I do understand that coherency is rather absent in the REST universe.
09:44:24 <davidwood> +1
09:44:26 <SteveH> +1
09:44:30 <gavinc> +1
09:44:31 <PatH> +1
09:44:33 <zwu2> +1
09:44:36 <danbri> -1
09:44:40 <AZ> +1
09:44:51 <JFB> +1
09:44:57 <mbrunati> +1
09:45:06 <ivan> 0
09:45:14 <sandro> (clarify -- this is only for the subset of IRs that can be respresented in RDF.)
09:45:18 <pfps> +.5 as I'm not exactly sure just what REST is
09:45:24 <JFB> @AZ yes, found that surprising
09:45:24 <PatH> az, that will teach you to make lumpy custard.
09:45:46 <Zakim> +AZ
09:46:02 <NickH> +1 (but agree that REST isn't very well specified)
09:46:09 <yvesr> +1
09:46:12 <FabGandon> danbri: some environments don’t have a notion of REST.
09:46:13 <pchampin> -1
09:46:43 <FabGandon> Guus: we are only considering the notions behind REST.
09:46:57 <danbri> REST is good, but it doesn't seem a 1:1 relationship to me
09:47:07 <sandro> pchampin: my concern is that we might be missing some more complicated resources whose state is not represented by a graph, because it's not just time.
09:47:16 <SteveH> +1 to danbri, but I don't think it detracts from the analogy
09:47:19 <PatH> seems to me that if its not related to restthen I dont know why we even have these distinctions ourselves.
09:47:21 <pchampin> e.g. authentication, etc
09:47:33 <SteveH> pchampin, right, or cookies for e.g.
09:47:34 <cygri> good point pchampin. language negotiation etc
09:47:43 <danbri> maybe i'm pulling Web-derrived data from a local Lucene store; from Mahout clustering, or prolog, doing stuff in code and stuffing bits into graphs with URI tags. REST is in the environment but the data flow is much more complex than fetch'n'store
09:47:46 <pchampin> yes, this too
09:48:02 <sandro> guus: two groups;  (1) json, (2) skolemization
09:48:13 <tomayac> json += tomayac
09:48:19 <PatH> will skolem have a phone link?
09:48:39 <FabGandon>  ISSUE-15: Text to be further discussed : "We understand that g-* aligns with REST, with g-box=information resource, g-snap=state of the resource (at time t), g-text=representation of the state of the resource (at time t)"
09:48:39 <trackbot> ISSUE-15 What is the relationship between the IRI and the triples in a dataset/quad-syntax/etc notes added
09:48:44 <danbri> SteveH, sure, considered as an analogy it can be instructive (and in fact I'm trying to extend REST concepts a bit more into XMPP message types)
10:09:29 <pfps> Topic: skolemization (whatever that is!)
10:09:36 <tomayac> is there a dial-in no. for json?
10:09:49 <pfps> no dialin for json yet
10:09:56 <Zakim> +zwu2
10:09:56 <davidwood> davidwood has joined #rdf-wg
10:10:00 <pfps> and there won't be one
10:10:02 <sandro> no dialin for json ever, sorry.
10:10:05 <davidwood> zakim, who is on the phone?
10:10:05 <Zakim> On the phone I see Meeting_Room, tomayac, gavinc, AZ, zwu2
10:10:09 <zwu2> zakim, mute me
10:10:09 <Zakim> zwu2 should now be muted
10:10:40 <Zakim> +PatH
10:10:52 <PatH> zakim, mute me
10:10:52 <Zakim> PatH should now be muted
10:11:02 <mischat> tomayac: do you want to be dialled in ?
10:11:12 <yvesr> scribe: yvesr
10:11:12 <danbri> so - what are we skolemising and why?
10:11:19 <mischat> do JSON people want to call in 
10:11:20 <sandro> topic: Skolemization Breakout
10:11:21 <pgroth> the skolemization has taken over this chat room
10:11:27 <pfps> The problem, as I see it, is that RDF stores hold blank nodes, but they have problems sending identifiers for these blank nodes out in response to queries and getting them back.
10:11:29 <mischat> yeah we are about to set up a voice thing 
10:11:31 <mischat> i sec 
10:11:40 <yvesr> SteveH: long-standing issue in the way bnodes are defined
10:11:49 <yvesr> SteveH: close-enough to existential variables in rdf
10:12:02 <yvesr> SteveH: most implementations turn it into an internal identifier
10:12:05 <sandro> SteveH: I have a longstanding issue who how bnodes are defined, as existential variables.  But the reality is that all the triplestores turn it into an internal identifier.
10:12:13 <yvesr> SteveH: turning them into 'skolems'
10:12:21 <cygri> (JSON breakout is happening over in the #rdf-json channel)
10:12:46 <sandro> pfps: So far, they havent' done anything wrong.
10:13:09 <Zakim> -tomayac
10:13:13 <yvesr> SteveH: 2 problems - 1) bnodes in the wild (when there shouldn't be) and 2) people deliberately writing them (i.e. FOAF)
10:13:27 <danbri> q+ to account for the foaf case
10:13:42 <PatH> there is also a strong deprtecation of bnode use in the linked data community.
10:13:44 <sandro> SteveH: But sometimes you encounter bnodes in the wild, where it would be nice to have URIs, as in foaf.   In practice it's annoying.
10:13:46 <yvesr> SteveH: in FOAF, you end up using inverse functional properties to identify individuals
10:13:54 <davidwood> Zakim, open the queue
10:13:54 <Zakim> ok, davidwood, the speaker queue is open
10:14:09 <danbri> q+ to account for the foaf case
10:14:24 <sandro> q+ to present proposal
10:14:43 <yvesr> SteveH: People are missing a feature from relational databases (not assigning an explicit primary key)
10:15:03 <yvesr> SteveH: some triple stores have internal uri schems to talk about bnodes
10:15:12 <sandro> SteveH: Folks also have internal URI schemes for talking about bnodes.   People really want this for SPARQL round-tripping.
10:15:14 <davidwood> ack danbri
10:15:14 <Zakim> danbri, you wanted to account for the foaf case
10:15:15 <yvesr> SteveH: those can surface in query results - and can be used in queries
10:15:18 <pfps> q+
10:15:28 <PatH> q+
10:15:38 <pfps> q+ to say that such RDF stores aren't really doing anything 'wrong'
10:15:48 <yvesr> danbri: There's a reason for the FOAF choice - leading to anonymous resources
10:16:02 <yvesr> danbri: no owl:sameAs, not clear what to do with resources
10:16:19 <yvesr> danbri: identifying people with properties was a pragmatic decision
10:16:44 <yvesr> davidwood: how would you do it today?
10:17:07 <yvesr> danbri: if you were in a position to assign uris for other people, then FOAF would have gone for URIs
10:17:24 <yvesr> danbri: bnodes are a pain to deal with...
10:17:44 <yvesr> q+
10:18:01 <davidwood> ack sandro
10:18:01 <Zakim> sandro, you wanted to present proposal
10:18:01 <ivan> ack sandro 
10:18:06 <sandro> steveH: The assigned URIs leak out of query interface, which is what makes them useful.
10:18:27 <zwu2> zwu2 has joined #rdf-wg
10:18:31 <danbri> original statement of the foafy smushing stuff: http://lists.xml.org/archives/xml-dev/200012/msg00597.html
10:18:44 <yvesr> sandro: Long discussion on the semantic-web list a couple of weeks ago - a proposal was done that adress everyone's requeirements 
10:19:09 <yvesr> sandro: pick one of two uri pattern  choices to skolemize bnodes 
10:19:29 <yvesr> sandro: http://... if you want to dereference, or tag:...
10:20:03 <yvesr> sandro: if you encounter one of those uris, it's machine generated
10:20:17 <yvesr> sandro: those uris can be considered as disposable
10:20:19 <danbri> so the first dozen or so FOAF files used genid: as a URI scheme, eg. http://svn.foaf-project.org/foaftown/2010/allfactoids/copies/danbri/danbri-foaf.rdf ...  about="genid:poulter" etc
10:21:00 <FabGandon> yvesr: how do you know they are machine generated?
10:21:13 <PatH> it is always valid to 'deskolemize', so we dont need to say anything about that.
10:21:20 <FabGandon> SteveH: because they have genid
10:21:39 <yvesr> danbri: reserved uri pattern - genid in the uri means that it is machine generated
10:21:42 <sandro> 1.  If you're going to Skolemize, use a URI like this:
10:21:42 <sandro>    - http://example.org/.well-known/genid/[whatever]
10:21:42 <sandro>    - tag:example.org,2011/.well-known/genid/[whatever]
10:21:42 <sandro> 2.  If you encounter one of these URIs:
10:21:42 <sandro>   
10:21:43 <sandro>    - you know it's machine generated
10:21:45 <sandro>    - consider it more disposable, more mergeable
10:22:08 <PatH> +1 to speaker. genid is better.
10:22:11 <gavinc>  eg: generate-id() in XPath/XSLT
10:22:12 <sandro> We mean LITERALLY the string "genid".
10:22:13 <yvesr> SteveH: Prefers genid over bnodes 
10:22:40 <PatH> s/speaker/stevenh
10:22:43 <yvesr> SteveH: you might want to use "genids" to identify graphs
10:22:51 <davidwood> ?
10:22:53 <davidwood> q?
10:22:57 <yvesr> sandro: Use "genid" or "gensym"?
10:23:00 <davidwood> ack pfps
10:23:00 <Zakim> pfps, you wanted to say that such RDF stores aren't really doing anything 'wrong'
10:23:05 <ivan> ack pfps 
10:23:49 <davidwood> q+ to mention the use of made-up ids as a pattern to replace bnodes
10:24:07 <yvesr> JFB: bnodes are stronger - they can never be used in another graph
10:24:18 <yvesr> SteveH: this is already dropped in sparql-update
10:24:53 <yvesr> pfps: Technically, it is not a valid entailment
10:25:24 <ivan> q+
10:25:35 <danbri> related prev discussion: sergey melnik tried to create a canonical URIs for bnode/anon resources - http://lists.w3.org/Archives/Public/www-rdf-interest/1999Dec/0046.html
10:25:59 <sandro> pfps: As long as these are fresh, you wont get any incorrect inferences.
10:26:20 <yvesr> pfps: SPARQL-update validates the leaky bnodes, what this proposal says is that graph stores are able to make that transformation
10:26:25 <sandro> pfps: This says an RDF store is entitled to change bnodes like this.
10:27:05 <davidwood> ack PatH
10:27:08 <sandro> pfps: "RDF graphs stores can, on their own recognisance, do this transformation"
10:27:37 <yvesr> PatH: the fact that such uris can leak out is a good thing
10:27:51 <yvesr> PatH: We don't have to worry about leakage
10:27:52 <sandro> q?
10:28:22 <davidwood> ack yvesr
10:28:51 <zwu2> cannot hear much
10:28:55 <PatH> zakim, mute me
10:28:55 <Zakim> PatH should now be muted
10:29:19 <PatH> sound is very patchy.
10:29:25 <PatH> better
10:31:07 <davidwood> ack davidwood
10:31:07 <Zakim> davidwood, you wanted to mention the use of made-up ids as a pattern to replace bnodes
10:31:31 <yvesr> yvesr: RDFa creates lots of bnodes in the wild
10:31:56 <yvesr> yvesr: and sometimes there are things that you can't identify, or don't want to mint a URI for (e.g. transient things)
10:32:01 <danbri> ivan, in your homepage you have     <div id="container" about="http://www.ivan-herman.net/foaf#me" typeof="foaf:Person dc:Agent">   .... that's the verbose aspect. But maybe you could use a relative URI at least?
10:32:22 <yvesr> davidwood: I don't think there is soemthing wrong with bnodes, and it's fine to skolemize them
10:32:37 <yvesr> s/soemthing/something/
10:33:04 <yvesr> davidwood: Machines should do the job, transparently
10:33:40 <sandro> q?
10:33:45 <davidwood> ack ivan
10:33:45 <sandro> q+ to draft proposal
10:33:50 <yvesr> SteveH: what you want is a bnode syntax, not a bnode semantics
10:34:14 <yvesr> ivan: I can understand that a number of people would want to derefence these things
10:34:19 <PatH> sandro, type it.
10:34:21 <yvesr> ivan: what happens when you derefence them?
10:34:24 <sandro> PROPOSAL: It's okay for systems to Skolemize bnodes, replacing them with IRIs of the form http[s]://[domain]/.well-known/genid/[locally-uniq-id] or tag:[domain],[year]/.well-known/genid/[locally-unique-id].  Such IRIs are considered more disposable.  Must be reg'd with IETF.
10:34:33 <yvesr> ivan: what advice do you give, and how are people to set it up?
10:34:57 <yvesr> ivan: the first uri pattern is an http:// uri, and needs to be dereferencable - what does it do?
10:34:58 <PatH> should be fine for these to give 404s.
10:35:03 <davidwood> SteveH: Yes, I want the usefulness of bnode semantics with a simple, automated bnode syntax assistance.
10:35:29 <yvesr> ivan: do we want to get this reflected in various syntaxes?
10:35:48 <davidwood> q?
10:36:20 <yvesr> SteveH: what we would do in 4store would be to generate bnode skolems based on a prefix
10:36:32 <yvesr> SteveH: prefix is defined in configuration
10:36:52 <yvesr> SteveH: accessible as any other identifier in the store
10:37:30 <yvesr> ivan: you're using your SPARQL engine as a tool - the W3C needs to provide a global mechanism for what happens when you derefence a http://...genid... uri
10:37:35 <PatH> sandro, if these are supposed to refer to non-information resources, then according to http-range-14, they ought to give a 303 redirect. Can they have a # ending to remove this requirement?
10:38:22 <yvesr> q+
10:38:58 <yvesr> ivan: Linked Data people don't want to have bnodes in their graph
10:39:19 <yvesr> pfps: there's no way to make them happy
10:39:35 <yvesr> ivan: there is a way to set up a simple service somewhere that would do the job
10:39:41 <sandro> PatH, how about if it's http[s]://[domain]/.well-known/genid/[locally-uniq-id]#
10:40:13 <PatH> fine with me, as long as doesnt require a 303 mechanism
10:40:18 <davidwood> q+ to discuss broadness of skolemization (stores, validation, services, etc)
10:40:23 <yvesr> SteveH: if you dereference a bnode, one thing you could do is to just say 'this is a bnode'
10:40:42 <davidwood> ack sandro
10:40:42 <Zakim> sandro, you wanted to draft proposal
10:40:56 <sandro> PROPOSAL: It's okay for systems to Skolemize bnodes, replacing them with IRIs of the form http[s]://[domain]/.well-known/genid/[locally-uniq-id]# or tag:[domain],[year]/.well-known/genid/[locally-unique-id].  Such IRIs are considered more disposable.  Must be reg'd with IETF.
10:41:00 <danbri> q+ to express risk of single point of failure / keeping a bnode-description-service secure is nontrivial, costly work
10:41:38 <yvesr> sandro: the hash is to stay clear of httpRange-14
10:41:52 <gavinc> Annoyed but not strong/formal objection to using tag: --0?
10:41:58 <yvesr> sandro:
10:42:02 <PatH> +1 danbri, should not presume a service of any kind.
10:42:07 <yvesr> SteveH: i can think of lots of reasons not to do that
10:42:15 <sandro> gavinc, why does the tag bother you?   what would you prefer?
10:42:40 <yvesr> davidwood: uri lookups cost time and money
10:42:50 <gavinc> tag was designed specificly for HUMAN generated uniqueness 
10:42:50 <davidwood> ack yvesr
10:43:04 <gavinc> q+
10:43:05 <danbri> (re bit.ly / tinyurl analogy, ... it's taking us a month of HTTP requests to bit.ly to expand otherwise mysterious shortlinks from a twitter crawl, ... they only allow 2 lookups / second ... single points of control worrying)
10:44:22 <pchampin> shouldn't we  add "fresh IRI" in Sandro's proposal?
10:44:41 <sandro> yvesr: I don't like Skolem ids leaking out.
10:44:54 <danbri> LOD community have established the convention than any party can invent HTTP URIs freely, for anything and anyone; so why not just generate LOD URIs or uuid: URIs? I don't see this proposal adding value to those options
10:44:56 <FabGandon> WRT the service approach, beyond the risk of single point of failure it is a point of centralization in the model and in general centralization is not good for web arch IMHO  
10:44:58 <PatH> all specifically RDF uses dont require dereferencing. Seems like main purpose of these being recognizable is to AVOID dereferencing them.
10:45:37 <davidwood> ack gavinc
10:45:39 <zwu2> q+
10:45:42 <ivan> ack gavinc 
10:45:45 <sandro> sandro: Maybe "*if* you're going to skolemize, you SHOULD use one of these two forms"
10:46:23 <PatH> disagree. should be free to skolemize any way you like, as long as it is 'frtesh'
10:46:24 <yvesr> gavinc: seems very wrong to use tag uris
10:46:29 <PatH> fresh
10:46:50 <yvesr> gavinc: is UUID terrible?
10:47:16 <yvesr> SteveH: minting a new UUID for all bnodes is not very affordable
10:47:27 <yvesr> gavinc: we got rid of all bnodes at o'reilly because of that
10:47:28 <davidwood> Sandro thinks yes, UUIDs doesn't allow you to use genie
10:47:40 <davidwood> s/genie/genid/
10:47:49 <yvesr> q?
10:48:27 <yvesr> ivan: is it true that the tag: scheme says 'it is for humans'?
10:48:51 <yvesr> gavinc: the generation mechanism needs to happen by humans
10:48:58 <davidwood> ack davidwood
10:48:58 <Zakim> davidwood, you wanted to discuss broadness of skolemization (stores, validation, services, etc)
10:49:11 <zwu2> zakim, unmute me
10:49:11 <Zakim> zwu2 should no longer be muted
10:49:25 <yvesr> davidwood: There is opportunity to use skolemisation in quite a lot of places, not only in stores
10:49:50 <yvesr> davidwood: input, output, validation process, skolemization services
10:49:52 <pchampin> q+ to talk about the fresh URIs and them leaking from the store
10:50:14 <sandro> PROPOSAL: If systems are going to reveal Skolemized bnodes, they SHOULD use URIs of the form http[s]://[domain]/.well-known/genid/[locally-uniq-id]# or tag:[domain],[year]/.well-known/genid/[locally-unique-id].  Such IRIs are considered more disposable.  "genid" to be reg'd with IETF.
10:50:14 <davidwood> q?
10:50:15 <yvesr> davidwood: if you're doing skolemization, you SHOULD do it in the way we're defining
10:50:22 <danbri> ack danbri
10:50:22 <Zakim> danbri, you wanted to express risk of single point of failure / keeping a bnode-description-service secure is nontrivial, costly work
10:50:22 <davidwood> ack danbri
10:50:35 <davidwood> zakim, close the queue 
10:50:35 <Zakim> ok, davidwood, the speaker queue is closed
10:50:44 <PatH> prposal. it is permissible to replace bnodes by URIs provided that the URIs are 'fresh', ie not used in any other rdf graph. It is recommended to include a string /genid/. one way is sandro's prposal.
10:50:59 <danbri> q-
10:51:04 <yvesr> ivan: Would that effect any of the syntaxes, and how?
10:51:07 <PatH> q+
10:51:07 <yvesr> SteveH: it wouldn't
10:51:08 <danbri> I defer; question withdrawn
10:51:15 <yvesr> SteveH: it wouldn't be the parser's job to do it
10:51:22 <yvesr> SteveH: it doesn't have enough information
10:51:33 <yvesr> ivan: for RDFa, it would make sense - and it might make sense for Turtle files too
10:51:38 <mischat_> mischat_ has joined #rdf-wg
10:51:49 <yvesr> ivan: many people use the square brackets - lazyness
10:51:50 <danbri> ( I assume args for the skolem function is not just the textual input, but also the base URI...)
10:52:06 <yvesr> ivan: i should be able to tell the parser to mint me some URIs for those
10:52:23 <sandro> PROPOSAL: If systems are going to reveal Skolemized bnodes, they SHOULD use fresh URIs of the form http[s]://[domain]/.well-known/genid/[locally-uniq-id][#] or tag:[domain],[year]/.well-known/genid/[locally-unique-id].  Such IRIs are considered more disposable.  "genid" to be reg'd with IETF.
10:52:24 <davidwood> +1 to PatH's proposal
10:52:32 <davidwood> ack zwu
10:52:39 <yvesr> SteveH: reverse transformation - output documents *with* bnodes
10:53:08 <mischat_> Webr3 about?
10:53:12 <yvesr> zwu2: if you have one triple in a store, :john :friendOf _:a
10:53:16 <PatH> steveh, it is always valid to 'deskolemize' with bnodes.
10:53:24 <yvesr> zwu2: you would get back a skolemized bnode
10:53:31 <mischat_> webr3, if you are about join #rdf-json
10:53:36 <yvesr> zwu2: if we're using that skolemized bnode as a query
10:53:44 <yvesr> are we supposed to return :john or not?
10:53:49 <yvesr> zwu2: are we supposed to return :john or not?
10:53:52 <yvesr> SteveH: yes
10:54:08 <PatH> yes. once it is a uri, you can do this.
10:54:09 <yvesr> davidwood: if identifiers leak out to the outside world, it maintains validity
10:54:31 <yvesr> ivan: if i use the bnode filter operation in a SPARQL query, what happens?
10:54:37 <yvesr> ivan: does it match the skolemized bnode?
10:54:47 <yvesr> SteveH: that's an issue for us
10:54:49 <PatH> zakim, unmute me.
10:54:49 <Zakim> PatH should no longer be muted
10:54:56 <yvesr> SteveH: we need to define if they count as bnodes or not
10:55:12 <yvesr> ivan: as a user, who doesn't understand this stuff, i would expect the bnode function to work
10:55:21 <yvesr> SteveH: in 4store, it would answer true
10:55:39 <yvesr> SteveH: it only gets skolemized on the export
10:55:47 <yvesr> SteveH: internal consistency
10:55:47 <ivan> q?
10:55:48 <davidwood> ack pchampin
10:55:49 <Zakim> pchampin, you wanted to talk about the fresh URIs and them leaking from the store
10:55:53 <ivan> ack pchampin 
10:56:34 <yvesr> pchampin: We shoudl specify what is ok for the system to do
10:56:39 <PatH> az, no problem
10:56:43 <yvesr> pchampin: We should specify what the system would return
10:56:44 <SteveH> AZ, that wouldn't be legal RDF syntax, though you could write it by hand
10:56:57 <davidwood> PatH, can you please resend your proposal?
10:56:58 <yvesr> pfps: Troubles finding the SPARQL bnode definition
10:57:25 <danbri> pat hayes
10:57:40 <SteveH> http://www.w3.org/TR/rdf-sparql-query/#func-isBlank
10:57:49 <SteveH> ...the BNODE() function actually mints bNodes
10:57:50 <yvesr> PatH: genid SHOULD be in the URI but not absolutely required
10:57:58 <SteveH> but I think it was understood what was being discussed
10:58:07 <yvesr> PatH: it should be possible for people to invent URIs and use them
10:58:15 <yvesr> PatH: they could use software to do that automatically
10:59:08 <yvesr> PatH: We should not allow skolems that are specific to a single query
10:59:24 <sandro> PatH: Note that Skolemization is not valid in an antecedent (eg query). 
10:59:31 <sandro> SteveH: that's fine.
10:59:40 <PatH> prposal. it is permissible to replace bnodes by URIs provided that the URIs are 'fresh', ie not used in any other rdf graph. It is recommended to include a string /genid/. one way is sandro's prposal.
10:59:46 <yvesr> SteveH: the skolemization process has to be stable
11:00:00 <yvesr> davidwood: Can we get consensus around this proposal?
11:00:19 <yvesr> davidwood: are there concerns around sandro's mandated use?
11:00:43 <yvesr> davidwood: if you're going to skolemize, you need to use a globally unique URI
11:00:49 <sandro> freshness is iffy -- since you want stability....
11:00:52 <yvesr> davidwood: and we encourage you to do it in a way
11:01:46 <danbri> -1 where did 'allowed' enter the rdf universe?
11:01:49 <zwu2> as long as generated uri is fresh to the triple store, it is good enough
11:01:54 <yvesr> -1 as well
11:02:01 <danbri> -> say what it means, not what people can/can't do
11:02:22 <PatH> must be fresh, should include /genid/
11:02:47 <yvesr> sandro: MAY is you're allowed to
11:02:58 <yvesr> pfps: SHOULD is you should do it, unless there's a very good reason not to
11:03:16 <PatH> sandro, why is freshness "iffy"
11:03:37 <danbri> proposed: "A graph transformed such that each bnode is replaced with a fresh bnode [meeting some constraints], ... then that new graph is true under the same conditions of the original."
11:03:40 <danbri> q+ to propose
11:04:10 <danbri> we are not the SPARQL WG
11:04:12 <yvesr> davidwood: if systems are going to leak bnodes, they must use fresh uris
11:04:52 <yvesr> SteveH: consistent mapping between internal representation and external id
11:05:02 <zwu2> so we can reuse "fresh" uris 
11:05:11 <sandro> PROPOSAL: If systems are going to reveal Skolemized bnodes, they MUST use fresh URI (per bnode) and SHOULD follow the form http[s]://[domain]/.well-known/genid/[locally-uniq-id][#] or tag:[domain],[year]/.well-known/genid/[locally-unique-id].  Such IRIs are considered more disposable.  "genid" to be reg'd with IETF.
11:05:20 <yvesr> danbri: we're not the SPARQL working group - so I think this language inappropriate
11:05:33 <yvesr> danbri: we should instead say something about graph structures
11:06:11 <yvesr> ivan: current RDF documents already talk about skolemization
11:06:31 <yvesr> ivan: the only thing we're saying here is that if it is used, you should use this pattern
11:06:52 <danbri> http://www.w3.org/TR/rdf-mt/#prf
11:06:54 <yvesr> pfps: RDF Semantics talk about skolemization
11:07:51 <yvesr> sandro: you need a web service to do the skolemization
11:08:00 <PatH> wha?
11:08:05 <yvesr> ???
11:08:18 <danbri> madness!!!
11:08:18 <yvesr> SteveH: you can't guarantee uniqueness
11:08:30 <danbri> (that's a technical term, no disrespect intended)
11:09:12 <PatH> call it 'bnode purging' and people will love it.
11:09:16 <yvesr> sandro: tag: skolemized bnode are more horrible than bnode
11:09:35 <danbri> PatH, can it be couched more declaratively? this 'should' stuff worries me
11:09:40 <JFB> RDF Semantics talks about Skolemization in Appendix A. Its notion of freshness is "fresh in the current graph"
11:09:42 <yvesr> ivan: the R2RML folks are fighting with the same problem
11:09:46 <PatH> danbri, yes. 
11:10:01 <yvesr> ivan: what happens when the DB doesn't have a (publicly exposable) primary key
11:10:13 <PatH> jfb, no, that is not what was intended.
11:10:14 <pchampin> s/the DB/a table in the DB/
11:10:19 <sandro> PatH, in "you need a web service to do the skolemization" , I mean to be particularly useful, and make people happy you did the Skolemization....
11:10:45 <danbri> sandro, what are you seeing as the args to the skolemisation function? not just a document + base_uri?
11:10:49 <yvesr> ivan: if we come up with this note, we need to send it to the R2RML group - potential first users
11:11:17 <sandro> PROPOSAL: If systems are going to reveal Skolemized bnodes, they MUST use fresh URI (per bnode) and SHOULD follow the form http[s]://[domain]/.well-known/genid/[locally-uniq-id][#] or tag:[domain],[year]/.well-known/genid/[locally-unique-id].  Such IRIs are considered more disposable.  "genid" to be reg'd with IETF.
11:11:37 <sandro> PROPOSAL: If systems are going to reveal Skolemized bnodes, they MUST use a fresh URI (per bnode) and SHOULD follow the form http[s]://[domain]/.well-known/genid/[locally-uniq-id][#] or tag:[domain],[year]/.well-known/genid/[locally-unique-id].  Such IRIs are considered more disposable.  "genid" to be reg'd with IETF.
11:11:44 <sandro> objections from danbri and yves.
11:11:49 <PatH> unhappy with 'disposable'
11:12:13 <yvesr> danbri: very short URIs are important to me
11:12:19 <yvesr> danbri: don't force me to use this long pattern
11:12:25 <sandro> danbri: short URIs are important to me.   don't force me to do it this way.
11:12:41 <yvesr> SteveH: uri pattern is quite verbose
11:12:45 <PatH> and would prefer to just say 'SHOULD include string /genid/'
11:12:49 <danbri> sorry - am sounding grumpier than I am. This could be a useful pattern for some.
11:12:50 <sandro> SteveH: for the non-deref form I prefer something smaller.
11:13:08 <zwu2> how about genid:local_unique_id
11:13:14 <yvesr> danbri: if we cut the proposal to the first MUST, any objections?
11:13:35 <PatH> and sandro's particular form offered as an offtheshelf solution.
11:13:39 <yvesr>  all: what does disposable mean?
11:13:44 <yvesr> pfps: all pragmatics from here
11:13:54 <PatH> +1
11:14:20 <yvesr> sandro: you can skolemize, at some cost
11:14:33 <danbri> when you said "You're changing the data", that's in the right direction pfps
11:14:56 <PatH> you always can skolemize. It is not valid, but it preserves satisfiability.
11:15:02 <yvesr> sandro: proposition restrcited to MUST is actually stronger - want to expose the fact that it has been skolemized
11:15:36 <yvesr> sandro: genid:... would be good, but needs to be pushed through the IETF
11:15:54 <yvesr> ivan: this is a pain
11:16:11 <yvesr> sandro: don't want to be stuck in the IETF
11:16:24 <zwu2> you guys are not hungry, are you?
11:16:25 <danbri> the crux seems to be 'is it still in some appropriate equivalence class of graphs from the original? or has it been inappropriately interfered with..."
11:16:43 <PatH> why do we need to involve the IETF???
11:17:00 <gavinc> scheme registration :(
11:17:03 <yvesr> PatH, for a potential new uri scheme for those skolems
11:17:09 <pchampin> PatH: if we want a genid: URI scheme
11:17:11 <pfps> if we want to use URIs of the form genid:... we need to get approval
11:17:20 <PatH> screw a new scheme. they are just uris.
11:17:42 <yvesr> SteveH: are the two graphs the same? the skolemized and the original one?
11:17:53 <ivan> Pat, the issue is that the proposed URI-s are ugly and long...
11:18:01 <PatH> we need pertmission to include some text inside a URI??
11:18:30 <sandro> we need permission to say that all URIs containing certain text have a certain meaning, Pat.
11:18:34 <PatH> ivan, that is another issue.
11:18:35 <yvesr> you can't project from skolemized to original, but you can the other way around
11:18:52 <yvesr> FabGandon: you can't project from skolemized to original, but you can the other way around
11:18:59 <PatH> we artent saying anything about meaning, sandro.
11:19:17 <PatH> we are just making them recognizable.
11:19:58 <PatH> dawn is breaking here. 
11:20:04 <yvesr> davidwood: if we're close to a solution, let's keep on on that
11:21:04 <sandro> PROPOSAL: If systems are going to reveal Skolemized bnodes, without doing damage to the graph, they MUST use a fresh URI (per bnode) and SHOULD follow the form http[s]://[domain]/.well-known/genid/[locally-uniq-id][#] or tag:[domain],[year]/.well-known/genid/[locally-unique-id] (or, someday, genid:...).  Such IRIs are considered more disposable.  "genid" to be reg'd with IETF.
11:21:31 <FabGandon> yvesr: still not happy with the SHOULD part
11:21:40 <PatH> -1 to that. way too restricting. overkill.
11:21:53 <FabGandon> ... not confortable with specifying a URI parttern.
11:22:00 <pchampin> still uncomfortable with the "disposable" part; I don't know what that means
11:22:05 <zwu2> +0
11:22:13 <FabGandon> ivan: happier with IETF pattern
11:22:15 <PatH> agree with fabgandon
11:22:45 <FabGandon> Fabien happier with genid:
11:23:07 <PatH> we do not need to get IETF involved.
11:23:35 <pchampin> PatH: if we want genid: URIs, we do
11:23:39 <Zakim> -zwu2
11:23:42 <PatH> have a good lunch, guys.
11:23:55 <Zakim> -PatH
11:23:59 <AZ> enjoy your meal
11:24:04 <Zakim> -AZ
11:24:18 <PatH> pchampin: I do not neeed he IETF t put 'gnid' into a URI name.
11:24:41 <PatH> Anyway, back to email :-)
11:25:09 <gavinc>  about:, irc:, javascript:, jar:, rsync:, ssh:, ... need the IETF is a nice idea, the world doesn't exactly agree ;)
11:25:33 <gavinc> heck, if WHATWG has its way with the IETF ... no comment
11:25:54 <Zakim> -gavinc
11:31:13 <mischat__> mischat__ has joined #rdf-wg
11:58:16 <cmatheus> cmatheus has joined #rdf-wg
12:02:18 <mbrunati> mbrunati has joined #rdf-wg
12:02:23 <Guus> Guus has joined #rdf-wg
12:02:29 <ivan> -> http://www.w3.org/mid/4DA6A6AD.70205@deri.org -> Antoine's objection to yesterday's resolution
12:02:55 <ivan> http://lists.w3.org/Archives/Public/public-rdf-wg/2011Apr/0307.html instead
12:03:00 <cygri> cygri has joined #rdf-wg
12:03:02 <danbri> 404
12:03:04 <danbri> ah
12:03:19 <ivan> -> http://lists.w3.org/Archives/Public/public-rdf-wg/2011Apr/0309.html Lee's reply
12:03:38 <AlexHall> AlexHall has joined #rdf-wg
12:05:51 <gavinc> zakim, code?
12:05:51 <Zakim> the conference code is 26631 (tel:+1.617.761.6200 tel:+33.4.26.46.79.03 tel:+44.203.318.0479), gavinc
12:06:18 <danbri> zakim, who is on the phone?
12:06:18 <Zakim> On the phone I see Meeting_Room
12:06:19 <mischat> can people here the room ?
12:06:19 <sandro> zakim, who is on the call?
12:06:19 <Zakim> On the phone I see Meeting_Room
12:06:23 <mischat> s/here/hear/
12:06:27 <Zakim> +gavinc
12:06:53 <sandro> topic: Debrief Breakouts
12:07:03 <sandro> subtopic: JSON Breakout Debrief
12:07:34 <cmatheus> scribe:cmatheus
12:07:34 <cmatheus> cygri: talked about note to enumerate problem JSON space
12:07:51 <cmatheus> three examples; linked data, BBC, NYT
12:08:01 <Zakim> + +1.443.212.aabb
12:08:16 <ivan> q+
12:08:25 <cmatheus> part of problem: data always connected to some api
12:08:31 <AlexHall> zakim, +1.443.212.aabb is me
12:08:31 <Zakim> +AlexHall; got it
12:08:47 <cmatheus> linked data approach provides tools but its complicated
12:09:30 <cmatheus> talked about focusing on simple actions a json developer might want to take: enumerate instances, describe instance
12:10:21 <cmatheus> mischat: will also enlist help form rdfa TF
12:10:26 <ivan> q+
12:10:35 <ivan> zakim, open queue
12:10:35 <Zakim> ok, ivan, the speaker queue is open
12:10:39 <ivan> q+
12:10:48 <ivan> ack
12:10:49 <Guus> q?
12:10:54 <davidwood> ack ivan
12:11:37 <Zakim> +??P18
12:11:48 <cmatheus> ivan: discussion with Sandro about rdf web app working group (rdfa wg)
12:11:58 <webr3> Zakim, I am ??P18
12:11:58 <Zakim> +webr3; got it
12:12:30 <cmatheus> ivan: their intention is for low level things to be hidden from JS user
12:12:53 <cmatheus> whatever comes out of that group should be coordinated
12:13:04 <cmatheus> need to keep groups in sync
12:13:33 <cmatheus> guus: does this mean our use case numbver one is being done by rdfs wg?
12:13:43 <cmatheus> ivan: it's in the bin
12:13:56 <danbri> 'in the bin?' = trash?
12:14:13 <webr3> next week..
12:14:26 <cmatheus> according to plan rdfa api will be published next week
12:14:41 <cmatheus> this group should look at that document
12:14:56 <Steven> Steven has joined #rdf-wg
12:15:05 <cmatheus> guus: reporting of second breakout?
12:15:22 <sandro> subtopic: Report of Skolemization Breakout
12:15:40 <cmatheus> steveh: problem is if you have bnodes and you want to run a query to get them out there's no way to do that.
12:15:58 <cmatheus> plan is to provide a standard skolemize method to let you get them out
12:16:16 <cmatheus> everyone agreed this was good
12:16:35 <sandro> SteveH: If you query a sparql store and get bnodes out, there's no way to ask about them.    We'd like to stdize a way to allow those bnodes to be given lables (be IRI nodes) so you can ask more.    The sticky part is about indicating which nodes started out live as bnodes.
12:16:39 <LeeF> LeeF has joined #rdf-wg
12:16:44 <cmatheus> sticky part whether it's desirable to have a way to tell that these started out as bnodes.
12:17:19 <Zakim> +LeeF
12:18:02 <cmatheus> guus: is there consensus that you should be able to tell that they were blank nodes?
12:18:44 <Zakim> +AZ
12:18:46 <Steven> -> http://www.w3.org/2011/04/14-rdf-json-minutes.html Minutes of JSON breakout
12:18:53 <cmatheus> davidwood: core issue: how are people external to the skolem process able to tell they were bnodes. 
12:18:57 <danbri> (@cygri, I made a twitter list with rdfwg members, from your post - https://twitter.com/#!/danbri/rdfwg )
12:19:45 <cmatheus> question to peter: do you object to there being a way to be able to tell that these are bnodes?
12:19:53 <sandro> davidwood: Peter, do you object to there being a mechanism for indicating skolem nodes?
12:20:07 <sandro> Peter: I object to it being mandated.
12:20:16 <cmatheus> peter: against it being manditory
12:20:34 <cmatheus> as a consum I don't need to know whether someone skolemized.
12:20:40 <sandro> peter: As a consumer, I don't need to know, in all cases, whether Skolemization was done.  It would be nice to know, but it's not even a should.
12:20:58 <gavinc> +q to ask if isBlank() behavior should stay the same with skolemized or non skolemized?
12:20:59 <cmatheus> it's nice if we all did it or all agreed on doing it.
12:21:18 <danbri> so was this skolemised? http://data.linkedmdb.org/page/film/2014 ... who cares!
12:21:24 <sandro> SteveH: I want to be able to mint URIs that are skolem constants for bnodes such that when I get them back I can tell they were bnodes?
12:21:55 <cmatheus> steveh: if the producer gets the bnodes back should they be able to tell if they were created as bnodes?  different from having any user being able to tell.
12:22:20 <cmatheus> davidwood: in short, we were not able to get consensus
12:22:23 <gavinc> -q
12:22:31 <cmatheus> guus: will leave it open for the moment
12:22:38 <sandro> danbri, there are several practical situations when I would care, yes.
12:23:07 <cmatheus> guus: turning to clean up
12:23:15 <SteveH> danbri, if someone does INSERT DATA { <http://data.linkedmdb.org/page/film/2014> ... } and it's ont of my bNodes, I really need to be able to tell
12:23:24 <SteveH> otherwise it will screw up the data
12:23:58 <cmatheus> sandro: yesterday issue 10: deprecated, will use archaic
12:24:13 <cmatheus> issues on xs:string, containers
12:24:57 <cmatheus> next item for today: reification
12:25:04 <cmatheus> this is issue-25
12:25:35 <cmatheus> propse that we leave this until after we have a replacement for it
12:26:08 <cmatheus>  issue-26: trivial, rdfxml syntax has two ways to state subject: rdf:about and rdf:id
12:26:08 <trackbot> ISSUE-26 Should we deprecate rdf:ID on RDF/XML node elements? (use rdf:about instead) notes added
12:26:26 <cmatheus> proposal to mark idea as archaic
12:26:47 <cmatheus> Steveh: it can be usefull to use rdf:id to ensure you don't reuse an id
12:26:56 <sandro> SteveH: rdf:ID can be useful to find times when you accidentally use it twice....
12:26:59 <cmatheus> (since rdf:id's must be unique)
12:27:08 <AlexHall> do most rdf/xml parsers enforce the uniqueness of rdf:ID?
12:27:08 <cmatheus> guus: no objection to marking archaic
12:27:40 <cmatheus> cygri: I would argue against it.  it's a minor issue.  fixes a minor problem among the many rdf has. 
12:27:51 <cmatheus> if this is the only change let's not go there
12:28:00 <gavinc> Googling for rdf:ID lists documents which give conflicting advice on using it vs. rdf:about
12:28:17 <cmatheus> sandro:  wouldn't suggest that we go to much lenght to fix, but would recommend author's not to suggest using rdf:id
12:28:52 <danbri> http://www.w3.org/TR/rdf-syntax-grammar/#section-Syntax-ID-xml-base
12:28:58 <cmatheus> guus: there is a cost involved to learning to use rdf:id vs. rdf:about
12:29:03 <danbri> "So for example if rdf:ID="name", that would be equivalent to rdf:about="#name". rdf:ID provides an additional check since the same name can only appear once in the scope of an xml:base value (or document, if none is given), so is useful for defining a set of distinct, related terms relative to the same RDF URI reference."
12:29:32 <cmatheus> danbri: rdf:node_id are for bnodes
12:29:34 <danbri> q+
12:30:25 <cmatheus> sandro:  no body advocating rdf:id is a good thing just that it's not worth doing much about it
12:30:53 <sandro> PROPOSED: We don't think people should be using rdf:ID, but maybe it's not worth expressing this sentiment in any documents.
12:31:28 <webr3> so why not just deprecate it?
12:31:35 <cmatheus> guus: no one arguing for keeping it
12:31:42 <sandro> webr3, lots of people just gave their reasons.
12:31:46 <sandro> q?
12:31:47 <davidwood> davidwood has joined #rdf-wg
12:31:54 <davidwood> q?
12:31:59 <cmatheus> ivan: I would not touch rdf/xml
12:32:10 <pchampin> @web3: we deprecated the term 'deprecate' yesterday :)
12:32:13 <SteveH> http://www.google.com/search?q=%22rdf%3AID%22 suggests we should keep it
12:32:17 <cmatheus> if we begin to do something with it we will have to do a serious job
12:32:56 <cmatheus> danbri: rdf spec grammar, rdf:id can be used to check name reuse
12:33:12 <sandro> danbri: By saying anything, we complicated the RDF environment.
12:33:16 <cmatheus> if we say anything at all we add complexity to rdf environment.
12:33:24 <pfps> q+
12:33:35 <cmatheus> guus: propose we do not change
12:33:40 <ivan> ack danbri 
12:33:42 <ivan> ack pfps 
12:33:46 <sandro> PROPOSED: Close ISSUE-26 doing nothing.
12:33:49 <cmatheus> pfps: because it is being used we should do something about it
12:33:57 <LeeF> ISSUE-26?
12:33:57 <trackbot> ISSUE-26 -- Should we deprecate rdf:ID on RDF/XML node elements? (use rdf:about instead) -- open
12:33:57 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/26
12:34:07 <gavinc> I think my objection to rdf:ID is what happens if your xml:base ends with a / ;)
12:34:29 <gavinc> the issue is "appending the attribute value to the result of appending "#""
12:34:38 <NickH> Why is getting rid of rdf:ID more effort than getting rid of XMLLiteral / xsd:String etc?
12:34:42 <cmatheus> davidwood: why if it caused confusion and we agree we shouldn't use it, why should we continue to accept it?
12:34:49 <danbri> q+ to propose that we replace rdf:about and rdf:resource with rdf:uri, i.e. <foaf:Person rdf:uri="#me"><foaf:homepage rdf:uri="/"></foaf:Person>
12:34:55 <cmatheus> marking it archaic is not removing it
12:35:11 <sandro> PROPOSED: Close ISSUE-26 doing nothing.
12:35:12 <NickH>  sorry for the inaccuracy
12:35:18 <danbri> q-
12:35:36 <ivan> +1
12:35:38 <cygri> +1
12:35:39 <SteveH> +1
12:35:40 <danbri> +1
12:35:41 <pfps> +0
12:35:41 <AZ> +1
12:35:42 <pchampin> +1
12:35:42 <mbrunati> 1
12:35:43 <gavinc> -0 
12:35:43 <cmatheus>cmatheus::+1
12:35:44 <sandro> +0 (I understand)
12:35:44 <webr3> +0
12:35:47 <JFB> +1/3
12:35:51 <davidwood> +0
12:35:57 <mischat> +1
12:36:00 <NickH> Why is marking rdf:ID as archaic more effort than marking XMLLiteral / xsd:String etc archaic?
12:36:05 <FabGandon> +2/3
12:36:07 <sandro> RESOLVED: Close ISSUE-26 doing nothing.
12:36:33 <davidwood> NickH: Because marking rdf:ID as archaic would require a change to the RDF/XML document.
12:36:34 <cmatheus> sandro: rdf:value
12:36:49 <cmatheus> all I can say, mark it as archaic
12:36:51 <danbri> NickH - because those are *vocabulary* constructs which affect the entire ecosystem - rdfa, turtle, json, sparql, owl...
12:37:01 <sandro> SteveH: I like rdf:value
12:37:05 <sandro> Guus: I like it too!
12:37:07 <cmatheus> FabGandon: it's in a best practice note
12:37:26 <LeeF> SCOVO uses rdf:value (for better or for worse)
12:37:26 <NickH> danbri / davidwood thanks
12:37:33 <webr3> I like rdf:value just wish it was defined more clearly
12:37:39 <LeeF> (http://sw.joanneum.at/scovo/schema.html)
12:37:53 <sandro> Guus: In representation of museum data, we annotate with a bnode structure and then use a rdf:value for what's really pointed to.
12:37:54 <cmatheus> guus: example of its use: have things about values such as its dimension
12:38:13 <gavinc> +q Dublin Core also uses it
12:38:13 <danbri>  rdf:value was partly from reification, and partly for n-ary -> http://lists.w3.org/Archives/Public/semantic-web/2010Jul/0252.html
12:38:26 <gavinc> +q to talk mention that Dublin Core also uses it
12:38:29 <sandro> guus: Lots of people use this pattern, effectively.
12:38:41 <danbri> it's a bit like toString()
12:38:45 <FabGandon> Note 3 in SWBPWG http://www.w3.org/TR/swbp-n-aryRelations/#sec-notes
12:38:46 <cmatheus> guus: this is a property that points to the value
12:38:54 <cmatheus> it's highly deployed in some communities
12:39:39 <LeeF> Even if it was the most hated thing in the spec, I don't think we ought to deprecate it if it's as widely in use as it appears.
12:39:53 <danbri> re weights-and-measures, http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/ uses it for exactly that -- search for       <n:units rdf:resource="http://www.nist.gov/units/Pounds"/> 
12:39:54 <cmatheus> Steveh: done work with numeric data, want to be able to lterals as subjects in a sense
12:40:00 <yvesr> SteveH, was it signal processign related stuff?
12:40:09 <yvesr> SteveH, had to do the same for this kind of things
12:40:10 <cmatheus> ivan: when you need to add a unit to a value this is perhaps the best way to do it
12:40:16 <sandro> PROPOSED: Close ISSUE-27 doing nothing (not marking rdf:value as archaic).
12:40:20 <gavinc> -q
12:40:21 <pfps> -1
12:40:21 <webr3> +1
12:40:22 <SteveH> yvesr, no, demographics
12:40:23 <cmatheus> danbri: was in the original recommendation for that purpose
12:40:23 <LeeF> +1
12:40:24 <ivan> +1
12:40:26 <gavinc> +1
12:40:30 <AZ> +0
12:40:33 <SteveH> yvesr, but I think it might also be used in LV2
12:40:35 <pchampin> q?
12:40:37 <gavinc> +q to talk mention that Dublin Core also uses it
12:40:39 <davidwood> +1
12:40:40 <cmatheus> cygri: would like evidence on its deployment
12:40:42 <mbrunati> +1
12:40:43 <SteveH> yvesr, for presets and defaults
12:40:55 <FabGandon> +1/2
12:40:58 <cmatheus> pfps: I've seen it.  always badly.
12:41:03 <sandro> pfps: Every single case where I've seen it used, it's used badly.
12:41:05 <cmatheus> danbri: how could you tell?
12:41:27 <cmatheus> pfps: there's always a back handed agreement for how it is used
12:41:30 <sandro> pfps: ... where there is a backhanded agreement about what it really means, and where the meaning is really different in every case.
12:41:39 <cmatheus> ivan: this can be done because it is an open ended property
12:41:48 <cmatheus> pfps: destroys the utility of rdf
12:42:00 <cmatheus>  rdf:value is used as a local property
12:42:06 <webr3> +1 pfps
12:42:15 <cmatheus> cygri: where used they should have defined a local property
12:42:21 <cmatheus> guus: that's not true
12:42:22 <webr3> it's centered on out of band knowledge about the data
12:42:22 <AZ> +1 cygri
12:42:30 <sandro> cygri: I would argue that every time it's used, a local property should be defined for that.
12:42:37 <cmatheus>  rdf:value is for something where we don't have a solution
12:42:56 <cmatheus> steveh: like rdfs:label -- it's a handy thing to have around
12:43:00 <webr3>  rdfs:label is a typed link, rdf:value is untyped
12:43:05 <sandro> issue-27
12:43:09 <sandro> issue-27?
12:43:10 <trackbot> ISSUE-27 -- Should we deprecate rdf:value? -- open
12:43:10 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/27
12:43:31 <sandro> http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#rdfvalue
12:43:36 <cmatheus> guus: rdf:label points to a string instead of name and rdf:value points to the value
12:43:48 <cmatheus> same kind of function as rdf:label
12:43:51 <mischat> ?q
12:43:56 <danbri> ±0
12:44:16 <danbri> http://www.w3.org/TR/rdf-schema/#ch_value "rdf:value has no meaning on its own. It is provided as a piece of vocabulary that may be used in idioms such as illustrated in example 16 of the RDF primer [RDF-PRIMER]. Despite the lack of formal specification of the meaning of this property, there is value in defining it to encourage the use of a common idiom in examples of this kind."
12:44:18 <cmatheus> pfps:  don't mark it as archaic but realize you're making a bad mistake
12:44:20 <LeeF> Can we put an action to address this in the updated primer?
12:44:22 <danbri> ie. RDFS current encourages its use
12:44:33 <cmatheus> sandro: do you want document to say something about it?
12:44:42 <gavinc> Does Dublin Core do it wrong? http://dublincore.org/documents/dc-rdf-notes/
12:44:54 <cmatheus> pfps: no.  every time it's been used its been used badly.
12:45:05 <webr3> pfps +1
12:45:10 <sandro> pfps: Every time I've seen rdf:value it's been bad practice, destroying the "beauty" of RDF.
12:45:19 <webr3> it's like <a href="boo">, untyped
12:45:19 <pchampin> @sandro the example in the RDF primer is a bad one :-( (weight)
12:45:30 <cmatheus> pfps: rdf:value is the same as rdf:thispropertydoesn'tmeana*?/thing
12:45:35 <davidwood> davidwood has joined #rdf-wg
12:45:38 <cmatheus> sandro:  is this resolved?
12:45:47 <sandro> pfps: I'm not formally objecting to this proposal.
12:45:59 <Zakim> -Meeting_Room
12:46:00 <webr3> should it a couple of new properties be defined for common uses of rdf:value ..
12:46:03 <gavinc> ah
12:46:08 <gavinc> and there goes the phone
12:46:09 <Steven> zakim, who is noisy?
12:46:10 <cmatheus> cygri:  is there some text on good use of rdf:value?
12:46:11 <danbri> q+ to note a bug in RDFS spec; it references Primer example 16 -- an example that doesn't even use rdf:value.
12:46:17 <sandro> Guus: I disagree with Peter's characterization
12:46:22 <Zakim> Steven, listening for 10 seconds I heard sound from the following: gavinc (4%)
12:46:23 <sandro> davidwood: As do I.
12:46:42 <cmatheus> I would disagree with some of the things in the Primer
12:46:45 <sandro> cygri: The use for units of measure is extremely questionable.
12:47:06 <Steven> zakim, code?
12:47:06 <Zakim> the conference code is 26631 (tel:+1.617.761.6200 tel:+33.4.26.46.79.03 tel:+44.203.318.0479), Steven
12:47:08 <cmatheus> there's a lot of work on how to measure units of measure, they come up with different solutions
12:47:13 <gavinc> No, I can not hear.
12:47:35 <cmatheus> Sandro: meeting room got hung up on
12:47:53 <sandro> s/Sandor/Sandro/
12:48:12 <Zakim> +Meeting_Room
12:48:50 <cmatheus> cygri: if you just use rdf:value and have addition properties hanging off of value telling you what the value means, that's bad
12:49:48 <yvesr> :fft rdf:value "..."
12:50:03 <cmatheus> the Primer leads people into bad modeling and we should do something about it
12:50:11 <sandro> cygri: The primer gives bad modeling advice, and I don't like that.
12:50:14 <pchampin> +1 cygri
12:50:16 <yvesr> :fft :derived_from :signal .
12:50:20 <yvesr> all good practice, imho
12:50:21 <cmatheus> guus:  we can close this and open a new issue about the Primer
12:50:25 <NickH> yvesr: so avoid repeating very large literal values?
12:50:30 <cmatheus> cygri: okay
12:50:37 <yvesr> NickH, yep
12:50:49 <gavinc> -q
12:50:53 <yvesr> s/yvesr:/yvesr,/
12:51:19 <davidwood> davidwood has joined #rdf-wg
12:51:22 <sandro> PROPOSED: Close ISSUE-27, not marking rdf:value as archaic, but with the understand that the modeling advice in RDF Primer will be revisited.
12:51:26 <yvesr> +1
12:51:28 <ivan> +1
12:51:37 <danbri> q?
12:51:39 <danbri> ack danbri
12:51:39 <Zakim> danbri, you wanted to note a bug in RDFS spec; it references Primer example 16 -- an example that doesn't even use rdf:value.
12:51:44 <gavinc> +1
12:51:47 <danbri> ahh, i forgot already
12:51:49 <cygri> -0
12:51:59 <davidwood> Dublin Core uses rdf:value in the same manner as the examples in the RDF spec.  I think it is therefore compliant.
12:52:00 <AZ> +0
12:52:00 <danbri> action danbri danbri, you wanted to note a bug in RDFS spec; it references Primer example 16 -- an example that doesn't even use rdf:value.
12:52:00 <trackbot> Created ACTION-33 - Danbri, you wanted to note a bug in RDFS spec; it references Primer example 16 -- an example that doesn't even use rdf:value. [on Dan Brickley - due 2011-04-21].
12:52:05 <pchampin> +1
12:52:27 <cmatheus> sandro: can put an Action on Richard to review primer
12:52:58 <cmatheus> cygri:  I think there is a technical issue about a bug in the rdf Primer about advice on use of rdf:value
12:53:23 <cmatheus> guus: could result in Primer ignoring rdf:value
12:53:33 <sandro> RESOLVED: Close ISSUE-27, not marking rdf:value as archaic, but with the understand that the modeling advice in RDF Primer will be revisited.
12:54:17 <cmatheus> sandro:  only plan to spend another 35 minutes here
12:54:28 <cmatheus> those were all the ones marked as Archic
12:54:43 <cmatheus> s/Archic/Archaic/
12:54:43 <FabGandon> issue-6?
12:54:43 <trackbot> ISSUE-6 -- Handling RDF Errata -- open
12:54:43 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/6
12:55:03 <FabGandon> issue-7?
12:55:04 <trackbot> ISSUE-7 -- Leftover issues from the RDF Core WG -- open
12:55:04 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/7
12:55:12 <cmatheus> ivan:  issue 6: handling of Errata
12:55:14 <mischat> http://www.w3.org/2001/sw/RDFCore/errata
12:55:29 <cmatheus> we have to have a mechanism not to forget these
12:55:30 <davidwood> davidwood has joined #rdf-wg
12:55:38 <mischat> this related to danbri's suggestion of going through the archives 
12:55:46 <mischat> s/related/relates/
12:56:01 <cmatheus> nothing earthshakingly major
12:56:24 <cmatheus>  issue-7: some issues left open from previous working group 
12:56:24 <trackbot> ISSUE-7 Leftover issues from the RDF Core WG notes added
12:56:45 <mischat> http://www.w3.org/2000/03/rdf-tracking/#/%23futures
12:56:53 <cmatheus> danbri:  brief comment on list
12:57:07 <cmatheus> some were engineering hacks, left for next group
12:57:20 <webr3> +1
12:57:21 <cmatheus> ivan: we still need to go through them 
12:57:34 <cmatheus> davidwood: propose a telecom to discuss these
12:57:40 <yvesr> http://www.w3.org/2000/03/rdf-tracking/#rdfms-literalsubjects :)
12:57:47 <cmatheus> pfps: someone should go through them ahead of time
12:57:59 <cmatheus> davidwood: I volunteer to do that
12:58:17 <cmatheus> ivan: IRI versus URI story
12:58:18 <sandro> ACTION: wood prepare resolutions to dispose of each of the leftover items, http://www.w3.org/2000/03/rdf-tracking/#/%23futures
12:58:18 <trackbot> Created ACTION-34 - Prepare resolutions to dispose of each of the leftover items, http://www.w3.org/2000/03/rdf-tracking/#/%23futures [on David Wood - due 2011-04-21].
12:58:25 <cmatheus> frankly I am lost with the details
12:58:53 <gavinc> Jeremy had something on what needed to be updated with the IRIs, but I seem to have miss placed it.
12:58:54 <cmatheus> Andy and Eric know a lot about that
12:58:59 <FabGandon> issue-8?
12:58:59 <trackbot> ISSUE-8 -- Incorporate IRI-s into the RDF documents -- open
12:58:59 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/8
12:59:40 <cmatheus> sandro:  we want to look at every where we say something about URI and replace it with IRI
12:59:53 <ivan> The IRI Spec[1] is from 2005, and it may be necessary to retrofit it to RDF. Eg, what is the relationship between "http://xn--rsum-bpad.example.org/" and "http://xn--rsum-bpad.example.org/"? Are they the same resource or not? Note that SPARQL has something on that[2]...
13:00:39 <gavinc> Jeremy thought there were a few when we spoke about it. But again, I've missplaced the record of that conversation
13:00:51 <sandro> "http://résumé.example.org" and "http://xn--rsum-bpad.example.org"? 
13:01:03 <cmatheus> ivan:  (showing on the screen an issue with url's in irc)
13:01:37 <cmatheus> are the displayed iri's refereing to same resource or not?
13:02:10 <cmatheus> cygri:  two iri's are identifcal if the characters are the same, except in a number of cases...
13:02:24 <cmatheus> s/identifcal/identical/
13:02:25 <davidwood> q+
13:02:58 <cmatheus> the one uri can be normalized into the other
13:03:25 <cmatheus> guus: if it's a problem we can flag it but's it's not in the realm of where we should go
13:03:44 <mischat> http://www.w3.org/TR/sparql11-query/#syntaxTerms
13:03:47 <cmatheus> mischat: if we go this way we will need to have best practise note on this
13:03:53 <cmatheus> sandro: example?
13:03:55 <sandro> mischat: back-tick is valid in URI-References but not IRIs.
13:04:08 <cmatheus> mischat: a back tick.  caused our app to go down.
13:04:25 <cmatheus> davidwood: I've seen issues with that, I think it was with back tick.
13:04:36 <gavinc> for reference, IRI spec: http://www.ietf.org/rfc/rfc3987
13:04:46 <cmatheus> guus: objet to description of issues -- it's outside of scope
13:05:11 <pchampin> from the charter (required section): Clarify the usage of IRI references for RDF resources
13:05:18 <cmatheus> mischat: rdf group was guessing at what iris would look like
13:05:32 <cmatheus> davidwood: issue from implementation standdpoint
13:05:50 <ivan> q+
13:06:00 <cmatheus> when trying to index rdf, if you have to do a lot of checking, implementers will screem, Talis for one.
13:06:00 <ivan> ack davidwood 
13:06:27 <cmatheus> if we said an iri and uri were equivalent that would cause serious practical problems
13:06:43 <cmatheus> steveH: I understand what you're saying but don't understand the technical problem
13:07:04 <gavinc> +q
13:07:15 <cmatheus> davidwood: when ingesting rdf you must say whether this uri is equivalent to some other uri's in your system
13:07:15 <sandro> SteveH: Every triplestore I know just uses utf-8, so the question is which chars are allowed.
13:07:29 <cmatheus> steveh: it just changes your grammar
13:07:35 <cmatheus> davidwood: you may be right
13:07:42 <cmatheus> SteveH: I'm pretty sure I am
13:07:43 <ivan> ack davidwood 
13:07:47 <sandro> SteveH: SPARQL says they have to be the same normalized utf-8 byte string.
13:07:50 <mischat> q+
13:07:54 <cmatheus> davidwood: I'm talking about in SPARQL
13:08:00 <cmatheus> the specs say different things
13:08:07 <cmatheus> cygri:  I don't think they do
13:08:23 <cmatheus> in RDF world things are conistent
13:08:37 <cmatheus> s/sconistent/consistent/
13:08:51 <mischat> i don't think they are consistent, you can a SPARQL INSERT triples which you cant CONSTRUCT as valid RDF/XML
13:08:55 <cmatheus> there's no way you can align this with the rest of the web architecture
13:09:08 <SteveH> mischat, no you cant
13:09:08 <cmatheus> but can give recommendations.
13:09:16 <SteveH> mischat, oh, wait, not maybe that's right
13:09:18 <sandro> cygri: We can (and should) give recommendations to publishers about how to mint URIs to avoid these problems, like don't say :80 and dont use uppercase URI scheme or host names.
13:09:22 <mischat> it is right SteveH 
13:09:26 <cmatheus> if you avoid certain things then you will get same result
13:09:32 <davidwood>  correction:  I was *not* talking about SPARQL, but Turtle or other forms of ingesting into a store, and then only in the case where we decided that a given IRI was equivalent to a different character string URI.
13:09:35 <cmatheus> worth writing up as an aid to users of rdf
13:09:51 <davidwood> q?
13:09:52 <cmatheus> ivan: this discussion went beyond what I intended
13:09:57 <davidwood> ack ivan
13:10:38 <cmatheus> but look what happend when we just but the same iri's through two different systems and got very different results
13:10:48 <cmatheus> this is something we need to address
13:10:49 <gavinc> I think the section in question is: http://www.w3.org/TR/rdf-concepts/#section-Graph-URIref
13:10:56 <cmatheus> guus: this is not something we're going to solve
13:11:12 <mischat> this is the IRI RFC http://www.ietf.org/rfc/rfc3987.txt
13:11:19 <gavinc> The RFC lists a set of normalization methods http://www.ietf.org/rfc/rfc3987 
13:11:29 <cmatheus> ivan: why?  there is a document that says how to implement a system that will do the right thing
13:11:45 <Guus> q?
13:11:46 <cmatheus> davidwood: what is the sate of iri's in the standard (RC)
13:11:58 <cmatheus> cygri: it's implemented in all browsers
13:12:19 <davidwood> ack gavinc
13:12:24 <cmatheus> davidwood: that's different from the state of the standard
13:13:01 <cmatheus> gavinc: we went through this a month ago but I can't find the work we did -- not sure if it got lost in the shuffle
13:13:15 <cmatheus> we didn't think the spec was as brioken as some of the people are saying
13:13:22 <cmatheus> sorry, I don't remember the details
13:13:36 <sandro> davidwood, it's a PROPOSED STANDARD, per http://www.rfc-editor.org/rfcxx00.html#STDbySTD
13:13:48 <sandro> (like almost everything)
13:14:17 <cmatheus> mischat: the issue I have is I can issert certain triples, with content with a back tick, and then retrive it and I get something different.
13:14:50 <cmatheus> ivan: there are cetrtain charcters that you cannot put into a xml doc, but in turtle it would not be a problem
13:14:54 <sandro> (although URI  RFC-3986 is actually a "STANDARD" STD-66 )
13:15:05 <cmatheus> pfps: turtle is currently stuck at uri's
13:15:45 <Guus> q?
13:15:54 <cmatheus> gavinc: I don't think turtle is cemented to uris
13:16:03 <davidwood> IRIs seem to be an IETF standards-track (but not standard) RFC (3987), which does not expire.  There is a newer proposal, which will expire in Sep 2011 (https://datatracker.ietf.org/doc/draft-ietf-iri-3987bis/)
13:16:07 <cmatheus> gramar refers to iris
13:16:08 <Guus> ack mischat
13:16:37 <cmatheus> sandor: we should revisit this when Eric and Andy (perhaps Jeremy) are around
13:16:43 <cmatheus> ivan: issue 9
13:16:54 <sandro> s/sandor/sandro/
13:17:01 <cmatheus> small thing for Pat and Peter from der Horst
13:17:04 <cygri> davidwood: that's the same as the URI RFC
13:17:18 <cmatheus> an obvious thing that the editor has to take care of
13:17:30 <cmatheus> issue 11, more complicated
13:17:40 <davidwood> davidwood has joined #rdf-wg
13:18:19 <cmatheus> docs published by other wg's that extended the rdf semantics or contained elements related to rdf semantics
13:18:45 <cmatheus> implementors focusing on rdf have to visit all docs
13:19:07 <cmatheus> rdf plain literal added vocabulary
13:19:32 <cmatheus> POWDER likewise
13:19:46 <FabGandon> issue-11?
13:19:46 <trackbot> ISSUE-11 -- Reconciliation of various, semantics-oriented documents with the core RDF ones -- open
13:19:46 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/11
13:20:14 <cmatheus> SPARQL 1.1 has Entailment Regimes
13:20:25 <cmatheus> something we should look at
13:20:36 <cmatheus> guus: is there anything we need to do now
13:20:36 <danbri> ( @davidwood, i made a first cut at suggesting closure of the old RDFCore issues: http://lists.w3.org/Archives/Public/public-rdf-wg/2011Apr/0317.html )
13:20:42 <cmatheus> ivan: probably not
13:20:56 <cmatheus> guus: let's leave this open but ensure it gets resolved
13:21:07 <cmatheus> ivan: string literals handled
13:21:31 <cmatheus> xml literals discussed and still open
13:21:36 <cmatheus> that's all
13:23:31 <cmatheus> ivan: (discussion about POWDER extension to rdf schema...)
13:24:10 <cmatheus> guus: bad idea that there are many different groups dealing with these issues
13:25:22 <cmatheus> ivan:  not proposing to do any extra work -- need to make references to the other sources of relevant information
13:25:45 <cmatheus> guus: if we need to do more than references than this needs to be handled at a higher organizational level
13:26:16 <cmatheus> guus: suggest 20 minute break
13:26:20 <davidwood> davidwood has joined #rdf-wg
13:26:40 <cmatheus> in final session. short planning round for next F2F
13:26:52 <cmatheus> will come back and discuss document set
13:27:11 <cmatheus> and candidate docs
13:27:13 <davidwood> danbri: Thanks.  That list is very helpful.  I'll start with your list and see if I have any different ideas.  I plan to add that discussion to the agenda for next Wed.
13:27:21 <Zakim> -webr3
13:27:38 <gavinc> ?
13:27:42 <gavinc> I heard my name?
13:28:00 <Zakim> -AlexHall
13:28:07 <gavinc> or not ;)
13:33:58 <manu> manu has joined #rdf-wg
13:36:25 <mischat> this is the excerpt from the IRI rfc which highlights my issue with roundtripping RDF 
13:36:26 <mischat> http://pastebin.com/ZiQHQ2ab
13:39:42 <Zakim> +zwu2
13:40:07 <zwu2> zwu2 has joined #rdf-wg
13:42:26 <zwu2> zwu2 has joined #rdf-wg
13:48:11 <Zakim> + +1.443.212.aacc
13:48:18 <FabGandon> I wonder if it wouldn't be an easyer position to consider that every IRI loaded in a triple store is first turned into its ASCII version and then treated as the URI before including the character by character comparison.
13:48:50 <AlexHall> zakim, +1.443.212.aacc is me
13:48:50 <Zakim> +AlexHall; got it
13:49:25 <gavinc> No, the spec is already clear that URIs are unicode
13:49:44 <gavinc> "A URI reference within an RDF graph (an RDF URI reference) is a Unicode string"
13:50:40 <mbrunati> mbrunati has joined #rdf-wg
13:50:46 <cygri> scribe: cygri
13:50:51 <cygri> scribenick: cygri
13:50:53 <FabGandon> still we could have the transformation before and always work on the transformed version, no?
13:51:04 <zwu2> zakim, mute me
13:51:04 <Zakim> zwu2 should now be muted
13:51:24 <cygri> Topic: Next F2F meeting
13:52:08 <cygri> guus: there's pressure towards balance between european and north american locations
13:52:01 <cygri> LeeF: I'd recommend considering the sort of 2-site w/ video conference F2F that has been successful for SPARQL WG.
13:52:15 <cygri> ... The problem is that for time zones that only really works for US East Coast + UK (or so)
13:52:23 <cygri> ivan: W3C will have technical plenary week
13:52:33 <cygri> ... where several WGs meet
13:52:32 <cygri> ... http://www.w3.org/2011/11/TPAC/
13:52:45 <cygri> ... Santa Clara Marriott, Santa Clara, California, (Silicon Valley) USA  31 October to 4 November 2011
13:52:48 <Souri> Souri has joined #rdf-wg
13:53:10 <cygri> ... I try to convince the RDF apps WG to have their F2F there
13:53:38 <cygri> ... downside is that it's the week after ISWC
13:54:09 <cygri> davidwood: we might want to have the F2F meetings earlier rather than later
13:54:47 <cygri> ivan: july/august not a good time for europeans
13:54:54 <MacTed> MacTed has joined #rdf-wg
13:56:31 <cygri> guus: suppose we would do it at TPAC, for whom would that be an obstacle?
13:57:17 <cygri> SteveH: time difference is a problem
13:58:09 <cygri> davidwood: I question whether we should have a west coast f2f
13:57:47 <gavinc> Sigh.
13:58:11 <cygri> zwu2: CA in US sounds great
13:58:26 <cygri> sandro: how about right before ISWC?
13:59:03 <Zakim> + +1.603.897.aadd
13:59:31 <Souri> zakim, aadd is me
13:59:31 <Zakim> +Souri; got it
13:59:57 <cygri> ivan: other WGs: sparql, rdb2rdf, provenance, government linked data
14:00:05 <zwu2_> zwu2_ has joined #rdf-wg
14:00:38 <cygri> steveh: east coast much easier than west coast
14:00:54 <cygri> sandro: i'm happy to host at W3C, if i can find a room
14:01:02 <cygri> s/W3C/MIT/
14:01:17 <cygri> pfps: happy to host at bell labs
14:01:56 <cygri> guus: so, east coast location, 1st half of october?
14:02:21 <cygri> pfps: better earlier, end of september (more distance to tpac)
14:02:44 <cygri> guus: week of 26th september?
14:02:54 <cygri> SteveH: clash with SemTech London
14:03:11 <cygri> FabGandon: week of 12th of september?
14:04:03 <cygri> SteveH: we could host at Garlik
14:04:16 <cygri> pfps: find someone at oxford?
14:06:11 <cygri> guus: week of 3rd october, boston?
14:06:33 <cygri> sandro: remote participants, are you likely to be able to make this?
14:04:18 <cygri> gavinc: MIT sounds better then Europe
14:06:16 <cygri> ... TPAC sounds the best still
14:06:57 <cygri> ... I can travel if it's in the US; europe less likely
14:06:25 <danbri> (I don't know what I can attend nor where, but prefer east coast as most plausible)
14:07:04 <sandro> zakim, who is on the call?
14:07:04 <Zakim> On the phone I see gavinc, LeeF, AZ, Meeting_Room, zwu2 (muted), AlexHall, Souri
14:07:12 <cygri> LeeF: Yes
14:07:44 <cygri> ... Possibly if it were scheduled with our input :)
14:07:57 <cygri> ... The challenge this time was the date being picked without input, and hving existingcommitments
14:07:13 <cygri> Souri: East Coast is the best for me. Europe is doubtful.
14:07:19 <zwu2_> zakim, unmute me
14:07:19 <Zakim> sorry, zwu2_, I do not know which phone connection belongs to you
14:07:20 <davidwood> davidwood has joined #rdf-wg
14:07:58 <cygri> davidwood: to the remote americans: would you be able to come to a f2f in europe in the future?
14:08:00 <cygri> zwu2: CA is fine. East coast will do too
14:08:06 <cygri> AlexHall: No, I don't anticipate being able to travel to Europe
14:08:17 <cygri> souri: east cost is best, europe problematic
14:08:29 <cygri> AZ: I don't know if will be able to come to the US
14:08:40 <cygri> ... My situation after August is quite unclear
14:08:56 <cygri> davidwood: this tells me we should alternate meetings between europe and US
14:09:04 <cygri> ivan: tpac still best
14:09:37 <cygri> guus: i'll set up a poll
14:09:59 <cygri> Souri: We had a very good setup for SPARQL f2f last time using video connections between Cambridge/MIT and Oxford.
14:10:21 <cygri> ACTION: guus to set up poll regarding F2F date
14:10:21 <trackbot> Created ACTION-35 - Set up poll regarding F2F date [on Guus Schreiber - due 2011-04-21].
14:10:26 <cygri> gavinc: 2 video remote sites would also be excellent
14:11:59 <cygri> guus: options will be: US east cost: Boston or Murray Hill
14:12:07 <cygri> ... and TPAC
14:12:29 <zwu2_> is CA a choice at all?
14:13:00 <gavinc> CA, US ... not CA Canada 
14:12:53 <gavinc> well
14:12:43 <gavinc> TPAC is CA
14:13:11 <zwu2_> yes CA, US
14:12:40 <cygri> Topic: Scribing
14:12:53 <cygri> sandro: would be helpful if scribes could use topics and subtopics
14:12:53 <cygri> (IRC commands for scribe are “Topic: xyz” and “Subtopic: xyzxyz”)
14:13:10 <mischat> http://www.w3.org/2011/rdf-wg/meeting/2011-04-13 and http://www.w3.org/2011/rdf-wg/meeting/2011-04-14
14:14:19 <cygri> Topic: RDF document set and finding editors
14:14:29 <cygri> guus: this was on telecon agenda for a long time
14:14:43 <cygri> ... strong preference for not creating completely new set of docs
14:14:50 <cygri> ... but update the existing RDF Core documents
14:15:03 <cygri> ... have new editors and update these documents
14:15:25 <cygri> sandro: seems to depend on how big the changes are
14:15:49 <cygri> guus: for instance RDF Concepts would have to add sections on terminology and other things
14:16:04 <cygri> ... hopefully not too many changes to RDF Semantics
14:16:11 <davidwood> davidwood has joined #rdf-wg
14:16:12 <cygri> ... primer should be completely new rewritten version
14:16:19 <cygri> ... test cases we have to see
14:16:51 <cygri> ivan: test cases were REC in 2004. i don't see why they should be
14:17:16 <cygri> .. formally, would that mean we re-use the same short names?
14:17:31 <cygri> ... so would they formally be new versions of the same documents?
14:18:30 <cygri> cygri: we should use the same short names to avoid having multiple REC documents floating around
14:18:35 <cygri> ivan: what does SPARQL do?
14:18:36 <Zakim> -AZ
14:18:48 <cygri> steveh: (scribe got lost. not yet decided?)
14:18:57 <Zakim> +AZ
14:19:15 <cygri> guus: good guideline: substantial changes => new short name
14:19:28 <cygri> steveh: in SPARQL isn't decided yet
14:19:43 <cygri> sandro: OWL rewrote everything and new short names
14:19:50 <cygri> davidwood: that was not a good idea
14:20:07 <cygri> guus: i don't hear objections, so let's work on that assumption
14:20:16 <sandro> sandro: sounds like we're just talking about 2nd editions of Recs, not new Recs.
14:20:40 <cygri> Subtopic: RDF Concepts
14:20:41 <cygri> guus: these are lots of documents
14:21:01 <cygri> ... RDF Concepts. main change will be graph terminology
14:21:40 <cygri> ivan: and archaization? and XMLLiteral?
14:22:37 <cygri> cygri: i can be editor on that one
14:22:41 <cygri> davidwood: me too
14:22:41 <sandro> guus: eds, Richard and David
14:22:45 <cygri> Subtopic: RDF Semantics
14:22:48 <cygri> guus: RDF Semantics
14:23:29 <cygri> ... ideal would be pfps and PatH
14:23:35 <cygri> pfps: ok
14:23:35 <Zakim> -AZ
14:23:40 <sandro> ACTION: guus to ask Pat to be an editor of RDF Semantics
14:23:41 <trackbot> Created ACTION-36 - Ask Pat to be an editor of RDF Semantics [on Guus Schreiber - due 2011-04-21].
14:24:00 <cygri> Subtopic: RDF Schema
14:24:15 <cygri> guus: RDF Schema
14:24:29 <sandro> Guus: DanBri, will you edit RDF Vocab?
14:24:36 <cygri> danbri: ok
14:24:45 <cygri> sandro: can we change the name to "RDF Schema"?
14:24:57 <sandro> ISSUE: Should we change the title of rdf-schema to use the word "Schema" ?
14:24:57 <trackbot> Created ISSUE-36 - Should we change the title of rdf-schema to use the word "Schema" ? ; please complete additional details at http://www.w3.org/2011/rdf-wg/track/issues/36/edit .
14:25:00 <cygri> Subtopic: Turtle Syntax
14:25:31 <cygri> guus: Turtle
14:25:39 <cygri> ivan: EricP has volunteered to do that
14:26:38 <cygri> mischat: i'm willing to help but might not be able to help much with syntax/grammar
14:27:00 <cygri> ivan: amount of work on turtle might not be much
14:27:13 <cygri> gavinc: I'd be happy to provide test cases?
14:28:43 <cygri> mischat: i'll take it into consideration. if andy wants do do it, i won't feel bad
14:29:02 <cygri> guus: we need to publish FPWDs soon. turtle obvious candidate
14:29:56 <cygri> ... mid-june should be doable
14:27:19 <danbri> I guess the concept we're going for is "2nd Edition" for most of these? sandro/ivan - is that defined in http://www.w3.org/2005/07/pubrules somewhere?
14:27:45 <sandro> danbri, yes.
14:28:11 <sandro> danbri, I've never done it myself, but I've seen it.
14:30:00 <cygri> Subtopic: N-Triples Syntax
14:30:32 <cygri> guus: possible other documents: n-triples
14:31:08 <cygri> sandro: n-triples might be appendix of turtle, or appendix of test cases
14:31:15 <Steven> Steven has joined #rdf-wg
14:31:21 <cygri> guus: might be a separate piece of work anyways
14:31:29 <cygri> ... spread out the responsibilities
14:31:58 <cygri> mischat: AndyS's page http://www.w3.org/2011/rdf-wg/wiki/N-Triples-Format
14:32:01 <cygri> cygri: andy did a wiki page on n-triples
14:33:06 <zwu2_> zakim, unmute me
14:33:06 <Zakim> sorry, zwu2_, I do not know which phone connection belongs to you
14:34:00 <cygri> sandro: zwu2, can you be ed of n-triples to make sure nothing bad happens to it?
14:34:02 <cygri> zwu2: i can do that
14:34:08 <zwu2_> zakim, who is here
14:34:09 <Zakim> zwu2_, you need to end that query with '?'
14:34:14 <zwu2_> zakim, who is here?
14:34:14 <Zakim> On the phone I see gavinc, LeeF, Meeting_Room, zwu2, AlexHall, Souri
14:34:20 <sandro> sandro: does it matter to you, Zhe, whether you are credited as an editor for that work?
14:34:27 <sandro> Zhe: I'm okay either way there.
14:35:21 <cygri> Souri: I can help on the n-triples -- my org (Oracle) has heavy investment on n-triples
14:34:48 <danbri> (asking informally, I'm told that "Second Editions" typically get their own short-name in /TR/  --- but to check with the webmaster team)
14:35:22 <cygri> Subtopic: RDF/JSON
14:35:23 <cygri> guus: json
14:35:24 <cygri> davidwood: i'll take an action to ask talis about a possible editor for the json rdf-to-rdf thing
14:35:28 <ivan> zakim, who is here?
14:35:28 <Zakim> On the phone I see gavinc, LeeF, Meeting_Room, zwu2, AlexHall, Souri
14:35:43 <zwu2_> q-
14:36:01 <cygri> cygri: souri just volunteered to help on n-triples
14:36:15 <cygri> guus: anyone else for rdf/json?
14:36:33 <cygri> ivan: only other person i can think of is tomayac
14:36:47 <sandro> action: wood to ask Talis to provide an editor for JSON
14:36:47 <trackbot> Created ACTION-37 - Ask Talis to provide an editor for JSON [on David Wood - due 2011-04-21].
14:36:56 <cygri> ... asking him would  be a good idea
14:37:13 <cygri> action: ivan to ask thomas about RDF/JSON editorship
14:37:13 <trackbot> Created ACTION-38 - Ask thomas about RDF/JSON editorship [on Ivan Herman - due 2011-04-21].
14:38:00 <cygri> Subtopic: JSON Recipes Note
14:38:10 <cygri> guus: JSON recipes note
14:38:43 <cygri> ... we had some volunteers: mishat, NickH, mbrunati
14:38:50 <cygri> ... and i'll volunteer one of my postdocs
14:38:58 <cygri> yvesr: i want to contribute to that note as well
14:39:28 <cygri> s/mishat/mischat/
14:39:35 <cygri> Subtopic: RDF Primer
14:39:37 <cygri> guus: rdf primer
14:39:42 <cygri> ... i volunteer
14:39:54 <cygri> LeeF: I would like to devote time to the rdf primer, though not necessarily as an editor.
14:39:59 <cygri> FabGandon: me
14:40:05 <cygri> pchampin: me
14:40:18 <cygri> cmatheus: me
14:40:56 <cygri> ivan: we need one, max two people to lead it, and perhaps a larger number of contributors
14:43:03 <mischat> :)
14:43:27 <davidwood> davidwood: Guus and Fabian to edit the Primer, with many contributors expected.
14:43:39 <cygri> cygri: so primer will have guus, FabGandon as lead editors, with possibly many contributors
14:44:00 <cygri> Subtopic: TriG/N-Quads Syntax
14:45:45 <cygri> cygri: on TriG/N-Quads, probably not a new doc but part of turtle ... i can help there
14:46:00 <cygri> Subtopic: RDF/XML Syntax
14:46:16 <cygri> ivan: RDF/XML ... we may not touch it at all, but might want to check with henry
14:47:33 <cygri> sandro: henry made clear that he won't do the RDF/XML work himself
14:47:48 <cygri> ... are there errata against RDF/XML?
14:48:24 <cygri> FabGandon: i'm happy to apply the errata
14:46:18 <zwu2_> I don't hate rdf/xml at all
14:46:52 <zwu2_> I just don't write manually in rdf/xml much 
14:46:59 <mischat> i am a bit of a fan, it has the most robust tooling 
14:47:10 <mischat> i dont like writing any rdf by hand
14:47:27 <sandro> I happily misread that, mischat, as the most robust trolling.
14:47:42 <AlexHall> the problem with rdf/xml is when newcomers confuse the xml syntax with the rdf semantics
14:47:48 <danbri> (btw re Turtle, http://www.w3.org/DesignIssues/N3Alternatives might be interesting)
14:49:44 <yvesr> AlexHall, and people using xpath on rdf/xml
14:49:52 <yvesr> caused us so much problems at the BBC
14:50:06 <yvesr> you change serialiser, and you end up breaking applications
14:50:09 <zwu2_> tricky to use xpath I guess
14:50:32 <yvesr> maybe an xpath-able version of rdf/xml would be in order? don't know though...
14:50:33 <gavinc> zwu, tricky is an understatement
14:50:40 <zwu2_> :)
14:51:38 <AlexHall> yvesr, it's in the charter as a time-permitting feature
14:49:00 <cygri> Subtopic: Tools for editors
14:49:56 <davidwood> q?
14:50:23 <cygri> danbri: practicalities around CVS access? use mercurial?
14:50:58 <cygri> sandro: four options: 1. edit xhtml in cvs; 2. use xmlspec
14:51:10 <danbri> w3c mercurial repo: https://dvcs.w3.org/hg/
14:51:48 <cygri> ... 3. respec (an html5 and js thing)
14:50:48 <danbri> danbri: http://dev.w3.org/2009/dap/ReSpec.js/documentation.html
14:52:28 <cygri> ivan: respec works well for me
14:53:21 <cygri> ... only downside: we have to transform old docs into respec. initial price.
14:53:34 <pchampin> pchampin: the Media Annotation WG uses respec for the API document
14:53:41 <pchampin> pchampin: http://dev.w3.org/2008/video/mediaann/mediaont-api-1.0/mediaont-api-1.0.html
14:53:53 <cygri> sandro: 4th option: use the wiki. there's a script to put stuff from xhtml into the wiki, and another for the way back
14:54:12 <danbri> I was thinking more about the testcases repository (as a consensus documentation tool / decision record) -> should that be w3c cvs datespace again, or mercurial?
14:55:21 <cygri> ivan: (more respec advocacy)
14:55:51 <cygri> sandro: if we don't use my code, i won't do the pubs
14:55:59 <cygri> FabGandon: upside of using the wiki: no cvs
14:56:11 <cygri> ivan: downside is that ppl hate wiki markup
14:56:34 <cygri> sandro: i should look at respec and look at how it handles [something]
14:56:38 <sandro> ACTION: sandro look at respec's handling of references
14:56:38 <trackbot> Created ACTION-39 - Look at respec's handling of references [on Sandro Hawke - due 2011-04-21].
14:57:05 <cygri> SteveH: don't use xmlspec
14:57:36 <cygri> ... especially if only small changes, just do them in xht�ml
14:58:10 <mischat> mischat: votes for a distributed version control system instead of a centralised one 
14:59:17 <Souri> Souri: based upon my R2RML editing experience: +1 for option 1 (edit xhtml in cvs); +0.5 for option 4 (wiki)
14:57:35 <danbri> so should RDFS spec be in HTML/RDFa? if so, which vocabulary terms should it include RDF claims about? rdf+rdfs?
14:59:19 <danbri> http://www.w3.org/blog/systeam/2010/06/16/why_we_chose_mercurial_as_our_dvcs/
14:59:20 <cygri> Topic: AOB
14:59:59 <sandro> sandro: (discussion of whether emacs can reify skolemized bnodes....)
15:00:03 <yvesr> yvesr: (in rdf/xml...)
15:02:01 <Zakim> -gavinc
15:02:02 <sandro> Bye remote folks!
15:02:06 <zwu2_> bye and have a safe trip home!
15:02:17 <manu> Have a safe trip back home to everyone there - :)
15:02:31 <Zakim> -zwu2
15:02:38 <AlexHall> AlexHall has left #rdf-wg
15:02:39 <Zakim> -AlexHall
15:02:46 <cygri> guus: adjourned
15:02:57 <cygri> trackbot, generate minutes
15:02:57 <trackbot> Sorry, cygri, I don't understand 'trackbot, generate minutes'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
15:03:11 <cygri> RRSAgent, generate minutes
15:03:11 <RRSAgent> I have made the request to generate http://www.w3.org/2011/04/14-rdf-wg-minutes.html cygri
15:03:14 <Zakim> -Souri
15:03:54 <Zakim> -LeeF
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00001723