.... that's the verbose aspect. But maybe you could use a relative URI at least? 10:32:22 davidwood: I don't think there is soemthing wrong with bnodes, and it's fine to skolemize them 10:32:37 s/soemthing/something/ 10:33:04 davidwood: Machines should do the job, transparently 10:33:40 q? 10:33:45 ack ivan 10:33:45 q+ to draft proposal 10:33:50 SteveH: what you want is a bnode syntax, not a bnode semantics 10:34:14 ivan: I can understand that a number of people would want to derefence these things 10:34:19 sandro, type it. 10:34:21 ivan: what happens when you derefence them? 10:34:24 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 ivan: what advice do you give, and how are people to set it up? 10:34:57 ivan: the first uri pattern is an http:// uri, and needs to be dereferencable - what does it do? 10:34:58 should be fine for these to give 404s. 10:35:03 SteveH: Yes, I want the usefulness of bnode semantics with a simple, automated bnode syntax assistance. 10:35:29 ivan: do we want to get this reflected in various syntaxes? 10:35:48 q? 10:36:20 SteveH: what we would do in 4store would be to generate bnode skolems based on a prefix 10:36:32 SteveH: prefix is defined in configuration 10:36:52 SteveH: accessible as any other identifier in the store 10:37:30 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 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 q+ 10:38:58 ivan: Linked Data people don't want to have bnodes in their graph 10:39:19 pfps: there's no way to make them happy 10:39:35 ivan: there is a way to set up a simple service somewhere that would do the job 10:39:41 PatH, how about if it's http[s]://[domain]/.well-known/genid/[locally-uniq-id]# 10:40:13 fine with me, as long as doesnt require a 303 mechanism 10:40:18 q+ to discuss broadness of skolemization (stores, validation, services, etc) 10:40:23 SteveH: if you dereference a bnode, one thing you could do is to just say 'this is a bnode' 10:40:42 ack sandro 10:40:42 sandro, you wanted to draft proposal 10:40:56 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 q+ to express risk of single point of failure / keeping a bnode-description-service secure is nontrivial, costly work 10:41:38 sandro: the hash is to stay clear of httpRange-14 10:41:52 Annoyed but not strong/formal objection to using tag: --0? 10:41:58 sandro: 10:42:02 +1 danbri, should not presume a service of any kind. 10:42:07 SteveH: i can think of lots of reasons not to do that 10:42:15 gavinc, why does the tag bother you? what would you prefer? 10:42:40 davidwood: uri lookups cost time and money 10:42:50 tag was designed specificly for HUMAN generated uniqueness 10:42:50 ack yvesr 10:43:04 q+ 10:43:05 (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 shouldn't we add "fresh IRI" in Sandro's proposal? 10:44:41 yvesr: I don't like Skolem ids leaking out. 10:44:54 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 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 all specifically RDF uses dont require dereferencing. Seems like main purpose of these being recognizable is to AVOID dereferencing them. 10:45:37 ack gavinc 10:45:39 q+ 10:45:42 ack gavinc 10:45:45 sandro: Maybe "*if* you're going to skolemize, you SHOULD use one of these two forms" 10:46:23 disagree. should be free to skolemize any way you like, as long as it is 'frtesh' 10:46:24 gavinc: seems very wrong to use tag uris 10:46:29 fresh 10:46:50 gavinc: is UUID terrible? 10:47:16 SteveH: minting a new UUID for all bnodes is not very affordable 10:47:27 gavinc: we got rid of all bnodes at o'reilly because of that 10:47:28 Sandro thinks yes, UUIDs doesn't allow you to use genie 10:47:40 s/genie/genid/ 10:47:49 q? 10:48:27 ivan: is it true that the tag: scheme says 'it is for humans'? 10:48:51 gavinc: the generation mechanism needs to happen by humans 10:48:58 ack davidwood 10:48:58 davidwood, you wanted to discuss broadness of skolemization (stores, validation, services, etc) 10:49:11 zakim, unmute me 10:49:11 zwu2 should no longer be muted 10:49:25 davidwood: There is opportunity to use skolemisation in quite a lot of places, not only in stores 10:49:50 davidwood: input, output, validation process, skolemization services 10:49:52 q+ to talk about the fresh URIs and them leaking from the store 10:50:14 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 q? 10:50:15 davidwood: if you're doing skolemization, you SHOULD do it in the way we're defining 10:50:22 ack danbri 10:50:22 danbri, you wanted to express risk of single point of failure / keeping a bnode-description-service secure is nontrivial, costly work 10:50:22 ack danbri 10:50:35 zakim, close the queue 10:50:35 ok, davidwood, the speaker queue is closed 10:50:44 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 q- 10:51:04 ivan: Would that effect any of the syntaxes, and how? 10:51:07 q+ 10:51:07 SteveH: it wouldn't 10:51:08 I defer; question withdrawn 10:51:15 SteveH: it wouldn't be the parser's job to do it 10:51:22 SteveH: it doesn't have enough information 10:51:33 ivan: for RDFa, it would make sense - and it might make sense for Turtle files too 10:51:38 mischat_ has joined #rdf-wg 10:51:49 ivan: many people use the square brackets - lazyness 10:51:50 ( I assume args for the skolem function is not just the textual input, but also the base URI...) 10:52:06 ivan: i should be able to tell the parser to mint me some URIs for those 10:52:23 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 +1 to PatH's proposal 10:52:32 ack zwu 10:52:39 SteveH: reverse transformation - output documents *with* bnodes 10:53:08 Webr3 about? 10:53:12 zwu2: if you have one triple in a store, :john :friendOf _:a 10:53:16 steveh, it is always valid to 'deskolemize' with bnodes. 10:53:24 zwu2: you would get back a skolemized bnode 10:53:31 webr3, if you are about join #rdf-json 10:53:36 zwu2: if we're using that skolemized bnode as a query 10:53:44 are we supposed to return :john or not? 10:53:49 zwu2: are we supposed to return :john or not? 10:53:52 SteveH: yes 10:54:08 yes. once it is a uri, you can do this. 10:54:09 davidwood: if identifiers leak out to the outside world, it maintains validity 10:54:31 ivan: if i use the bnode filter operation in a SPARQL query, what happens? 10:54:37 ivan: does it match the skolemized bnode? 10:54:47 SteveH: that's an issue for us 10:54:49 zakim, unmute me. 10:54:49 PatH should no longer be muted 10:54:56 SteveH: we need to define if they count as bnodes or not 10:55:12 ivan: as a user, who doesn't understand this stuff, i would expect the bnode function to work 10:55:21 SteveH: in 4store, it would answer true 10:55:39 SteveH: it only gets skolemized on the export 10:55:47 SteveH: internal consistency 10:55:47 q? 10:55:48 ack pchampin 10:55:49 pchampin, you wanted to talk about the fresh URIs and them leaking from the store 10:55:53 ack pchampin 10:56:34 pchampin: We shoudl specify what is ok for the system to do 10:56:39 az, no problem 10:56:43 pchampin: We should specify what the system would return 10:56:44 AZ, that wouldn't be legal RDF syntax, though you could write it by hand 10:56:57 PatH, can you please resend your proposal? 10:56:58 pfps: Troubles finding the SPARQL bnode definition 10:57:25 pat hayes 10:57:40 http://www.w3.org/TR/rdf-sparql-query/#func-isBlank 10:57:49 ...the BNODE() function actually mints bNodes 10:57:50 PatH: genid SHOULD be in the URI but not absolutely required 10:57:58 but I think it was understood what was being discussed 10:58:07 PatH: it should be possible for people to invent URIs and use them 10:58:15 PatH: they could use software to do that automatically 10:59:08 PatH: We should not allow skolems that are specific to a single query 10:59:24 PatH: Note that Skolemization is not valid in an antecedent (eg query). 10:59:31 SteveH: that's fine. 10:59:40 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 SteveH: the skolemization process has to be stable 11:00:00 davidwood: Can we get consensus around this proposal? 11:00:19 davidwood: are there concerns around sandro's mandated use? 11:00:43 davidwood: if you're going to skolemize, you need to use a globally unique URI 11:00:49 freshness is iffy -- since you want stability.... 11:00:52 davidwood: and we encourage you to do it in a way 11:01:46 -1 where did 'allowed' enter the rdf universe? 11:01:49 as long as generated uri is fresh to the triple store, it is good enough 11:01:54 -1 as well 11:02:01 -> say what it means, not what people can/can't do 11:02:22 must be fresh, should include /genid/ 11:02:47 sandro: MAY is you're allowed to 11:02:58 pfps: SHOULD is you should do it, unless there's a very good reason not to 11:03:16 sandro, why is freshness "iffy" 11:03:37 propose: "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 q+ to propose 11:04:10 we are not the SPARQL WG 11:04:12 davidwood: if systems are going to leak bnodes, they must use fresh uris 11:04:52 SteveH: consistent mapping between internal representation and external id 11:05:02 so we can reuse "fresh" uris 11:05:11 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 danbri: we're not the SPARQL working group - so I think this language inappropriate 11:05:33 danbri: we should instead say something about graph structures 11:06:11 ivan: current RDF documents already talk about skolemization 11:06:31 ivan: the only thing we're saying here is that if it is used, you should use this pattern 11:06:52 http://www.w3.org/TR/rdf-mt/#prf 11:06:54 pfps: RDF Semantics talk about skolemization 11:07:51 sandro: you need a web service to do the skolemization 11:08:00 wha? 11:08:05 ??? 11:08:18 madness!!! 11:08:18 SteveH: you can't guarantee uniqueness 11:08:30 (that's a technical term, no disrespect intended) 11:09:12 call it 'bnode purging' and people will love it. 11:09:16 sandro: tag: skolemized bnode are more horrible than bnode 11:09:35 PatH, can it be couched more declaratively? this 'should' stuff worries me 11:09:40 RDF Semantics talks about Skolemization in Appendix A. Its notion of freshness is "fresh in the current graph" 11:09:42 ivan: the R2RML folks are fighting with the same problem 11:09:46 danbri, yes. 11:10:01 ivan: what happens when the DB doesn't have a (publicly exposable) primary key 11:10:13 jfb, no, that is not what was intended. 11:10:14 s/the DB/a table in the DB/ 11:10:19 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 sandro, what are you seeing as the args to the skolemisation function? not just a document + base_uri? 11:10:49 ivan: if we come up with this note, we need to send it to the R2RML group - potential first users 11:11:17 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 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 objections from danbri and yves. 11:11:49 unhappy with 'disposable' 11:12:13 danbri: very short URIs are important to me 11:12:19 danbri: don't force me to use this long pattern 11:12:25 danbri: short URIs are important to me. don't force me to do it this way. 11:12:41 SteveH: uri pattern is quite verbose 11:12:45 and would prefer to just say 'SHOULD include string /genid/' 11:12:49 sorry - am sounding grumpier than I am. This could be a useful pattern for some. 11:12:50 SteveH: for the non-deref form I prefer something smaller. 11:13:08 how about genid:local_unique_id 11:13:14 danbri: if we cut the proposal to the first MUST, any objections? 11:13:35 and sandro's particular form offered as an offtheshelf solution. 11:13:39 all: what does disposable mean? 11:13:44 pfps: all pragmatics from here 11:13:54 +1 11:14:20 sandro: you can skolemize, at some cost 11:14:33 when you said "You're changing the data", that's in the right direction pfps 11:14:56 you always can skolemize. It is not valid, but it preserves satisfiability. 11:15:02 sandro: proposition restrcited to MUST is actually stronger - want to expose the fact that it has been skolemized 11:15:36 sandro: genid:... would be good, but needs to be pushed through the IETF 11:15:54 ivan: this is a pain 11:16:11 sandro: don't want to be stuck in the IETF 11:16:24 you guys are not hungry, are you? 11:16:25 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 why do we need to involve the IETF??? 11:17:00 scheme registration :( 11:17:03 PatH, for a potential new uri scheme for those skolems 11:17:09 PatH: if we want a genid: URI scheme 11:17:11 if we want to use URIs of the form genid:... we need to get approval 11:17:20 screw a new scheme. they are just uris. 11:17:42 SteveH: are the two graphs the same? the skolemized and the original one? 11:17:53 Pat, the issue is that the proposed URI-s are ugly and long... 11:18:01 we need pertmission to include some text inside a URI?? 11:18:30 we need permission to say that all URIs containing certain text have a certain meaning, Pat. 11:18:34 ivan, that is another issue. 11:18:35 you can't project from skolemized to original, but you can the other way around 11:18:52 FabGandon: you can't project from skolemized to original, but you can the other way around 11:18:59 we artent saying anything about meaning, sandro. 11:19:17 we are just making them recognizable. 11:19:58 dawn is breaking here. 11:20:04 davidwood: if we're close to a solution, let's keep on on that 11:21:04 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 yvesr: still not happy with the SHOULD part 11:21:40 -1 to that. way too restricting. overkill. 11:21:53 ... not confortable with specifying a URI parttern. 11:22:00 still uncomfortable with the "disposable" part; I don't know what that means 11:22:05 +0 11:22:13 ivan: happier with IETF pattern 11:22:15 agree with fabgandon 11:22:45 Fabien happier with genid: 11:23:07 we do not need to get IETF involved. 11:23:35 PatH: if we want genid: URIs, we do 11:23:39 -zwu2 11:23:42 have a good lunch, guys. 11:23:55 -PatH 11:23:59 enjoy your meal 11:24:04 -AZ 11:24:18 pahmpin: I do not neeed he IETF t put 'gnid' into a URI name. 11:24:41 Anyway, back to email :-) 11:25:09 about:, irc:, javascript:, jar:, rsync:, ssh:, ... need the IETF is a nice idea, the world doesn't exactly agree ;) 11:25:33 heck, if WHATWG has its way with the IETF ... no comment 11:25:54 -gavinc 11:31:13 mischat__ has joined #rdf-wg 11:58:16 cmatheus has joined #rdf-wg 12:02:18 mbrunati has joined #rdf-wg 12:02:23 Guus has joined #rdf-wg 12:02:29 -> http://www.w3.org/mid/4DA6A6AD.70205@deri.org -> Antoine's objection to yesterday's resolution 12:02:55 http://lists.w3.org/Archives/Public/public-rdf-wg/2011Apr/0307.html instead 12:03:00 cygri has joined #rdf-wg 12:03:02 404 12:03:04 ah 12:03:19 -> http://lists.w3.org/Archives/Public/public-rdf-wg/2011Apr/0309.html Lee's reply 12:03:38 AlexHall has joined #rdf-wg 12:05:51 zakim, code? 12:05:51 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 zakim, who is on the phone? 12:06:18 On the phone I see Meeting_Room 12:06:19 can people here the room ? 12:06:19 zakim, who is on the call? 12:06:19 On the phone I see Meeting_Room 12:06:23 s/here/hear/ 12:06:27 +gavinc 12:06:53 topic: Debrief Breakouts 12:07:03 subtopic: JSON Breakout Debrief 12:07:34 crgri: talked about note to enumerate problem JSON space 12:07:51 three examples; linked data, BBC, NYT 12:08:01 + +1.443.212.aabb 12:08:16 q+ 12:08:25 part of problem: data always connected to some api 12:08:31 zakim, +1.443.212.aabb is me 12:08:31 +AlexHall; got it 12:08:47 linked data approach provides tools but its complicated 12:09:30 talked about focusing on simple actions a json developer might want to take: enumerate instances, describe instance 12:10:21 mischat: will also enlist help form rdfa TF 12:10:26 q+ 12:10:35 zakim, open queue 12:10:35 ok, ivan, the speaker queue is open 12:10:39 q+ 12:10:48 ack 12:10:49 q? 12:10:54 ack ivan 12:11:37 +??P18 12:11:48 ivan: discussion with Sandro about rdf web app working group (rdfa wg) 12:11:58 Zakim, I am ??P18 12:11:58 +webr3; got it 12:12:30 ivan: their intention is for low level things to be hidden from JS user 12:12:53 whatever comes out of that group should be coordinated 12:13:04 need to keep groups in sync 12:13:33 guus: does this mean our use case numbver one is being done by rdfs wg? 12:13:43 ivan: it's in the bin 12:13:56 'in the bin?' = trash? 12:14:13 next week.. 12:14:26 according to plan rdfa api will be published next week 12:14:41 this group should look at that document 12:14:56 Steven has joined #rdf-wg 12:15:05 guus: reporting of second breakout? 12:15:22 subtopic: Report of Skolemization Breakout 12:15:40 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 plan is to provide a standard skolemize method to let you get them out 12:16:16 everyone agreed this was good 12:16:35 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 has joined #rdf-wg 12:16:44 sticky part whether it's desirable to have a way to tell that these started out as bnodes. 12:17:19 +LeeF 12:18:02 guus: is there consensus that you should be able to tell that they were blank nodes? 12:18:44 +AZ 12:18:46 -> http://www.w3.org/2011/04/14-rdf-json-minutes.html Minutes of JSON breakout 12:18:53 davidwood: core issue: how are people external to the skolem process able to tell they were bnodes. 12:18:57 (@cygri, I made a twitter list with rdfwg members, from your post - https://twitter.com/#!/danbri/rdfwg ) 12:19:45 question to peter: do you object to there being a way to be able to tell that these are bnodes? 12:19:53 davidwood: Peter, do you object to there being a mechanism for indicating skolem nodes? 12:20:07 Peter: I object to it being mandated. 12:20:16 peter: against it being manditory 12:20:34 as a consum I don't need to know whether someone skolemized. 12:20:40 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 +q to ask if isBlank() behavior should stay the same with skolemized or non skolemized? 12:20:59 it's nice if we all did it or all agreed on doing it. 12:21:18 so was this skolemised? http://data.linkedmdb.org/page/film/2014 ... who cares! 12:21:24 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 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 davidwood: in short, we were not able to get consensus 12:22:23 -q 12:22:31 guus: will leave it open for the moment 12:22:38 danbri, there are several practical situations when I would care, yes. 12:23:07 guus: turning to clean up 12:23:15 danbri, if someone does INSERT DATA { ... } and it's ont of my bNodes, I really need to be able to tell 12:23:24 otherwise it will screw up the data 12:23:58 sandro: yesterday issue 10: deprecated, will use archaic 12:24:13 issues on xs:string, containers 12:24:57 next item for today: reification 12:25:04 this is issue-25 12:25:35 propse that we leave this until after we have a replacement for it 12:26:08 issue-26: trivial, rdfxml syntax has two ways to state subject: rdf:about and rdf:id 12:26:08 ISSUE-26 Should we deprecate rdf:ID on RDF/XML node elements? (use rdf:about instead) notes added 12:26:26 proposal to mark idea as archaic 12:26:47 Steveh: it can be usefull to use rdf:id to ensure you don't reuse an id 12:26:56 SteveH: rdf:ID can be useful to find times when you accidentally use it twice.... 12:26:59 (since rdf:id's must be unique) 12:27:08 do most rdf/xml parsers enforce the uniqueness of rdf:ID? 12:27:08 guus: no objection to marking archaic 12:27:40 cygri: I would argue against it. it's a minor issue. fixes a minor problem among the many rdf has. 12:27:51 if this is the only change let's not go there 12:28:00 Googling for rdf:ID lists documents which give conflicting advice on using it vs. rdf:about 12:28:17 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 http://www.w3.org/TR/rdf-syntax-grammar/#section-Syntax-ID-xml-base 12:28:58 guus: there is a cost involved to learning to use rdf:id vs. rdf:about 12:29:03 "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 danbri: rdf:node_id are for bnodes 12:29:34 q+ 12:30:25 sandro: no body advocating rdf:id is a good thing just that it's not worth doing much about it 12:30:53 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 so why not just deprecate it? 12:31:35 guus: no one arguing for keeping it 12:31:42 webr3, lots of people just gave their reasons. 12:31:46 q? 12:31:47 davidwood has joined #rdf-wg 12:31:54 q? 12:31:59 ivan: I would not touch rdf/xml 12:32:10 @web3: we deprecated the term 'deprecate' yesterday :) 12:32:13 http://www.google.com/search?q=%22rdf%3AID%22 suggests we should keep it 12:32:17 if we begin to do something with it we will have to do a serious job 12:32:56 danbri: rdf spec grammar, rdf:id can be used to check name reuse 12:33:12 danbri: By saying anything, we complicated the RDF environment. 12:33:16 if we say anything at all we add complexity to rdf environment. 12:33:24 q+ 12:33:35 guus: propose we do not change 12:33:40 ack danbri 12:33:42 ack pfps 12:33:46 PROPOSED: Close ISSUE-26 doing nothing. 12:33:49 pfps: because it is being used we should do something about it 12:33:57 ISSUE-26? 12:33:57 ISSUE-26 -- Should we deprecate rdf:ID on RDF/XML node elements? (use rdf:about instead) -- open 12:33:57 http://www.w3.org/2011/rdf-wg/track/issues/26 12:34:07 I think my objection to rdf:ID is what happens if your xml:base ends with a / ;) 12:34:29 the issue is "appending the attribute value to the result of appending "#"" 12:34:38 Why is getting rid of rdf:ID more effort than getting rid of XMLLiteral / xsd:String etc? 12:34:42 davidwood: why if it caused confusion and we agree we should use it why should continue to accept it? 12:34:49 q+ to propose that we replace rdf:about and rdf:resource with rdf:uri, i.e. 12:34:55 marking it archaic is not removing it 12:35:11 PROPOSED: Close ISSUE-26 doing nothing. 12:35:12 cmatheus: sorry for the inaccuracy 12:35:18 q- 12:35:36 +1 12:35:38 +1 12:35:39 +1 12:35:40 +1 12:35:41 +0 12:35:41 +1 12:35:42 +1 12:35:42 1 12:35:43 -0 12:35:43 +1 12:35:44 +0 (I understand) 12:35:44