06:39:50 RRSAgent has joined #json-ld 06:39:50 logging to https://www.w3.org/2018/10/26-json-ld-irc 06:39:56 zakim, this is json-ld 06:39:56 got it, azaroth 06:40:11 Chair: Rob_Sanderson, Benjamin_Young 06:40:15 Meeting: JSON-LD 06:40:28 Date: 2018-10-26 06:41:08 ajs6f has joined #json-ld 06:41:31 scribenick: azaroth 06:41:38 TOPIC: Issues 06:41:50 SUBTOPIC: blank node ids for graphs 06:41:54 link: https://github.com/w3c/json-ld-api/issues/26 06:43:28 present+ 06:43:30 present+ Rob_Sanderson 06:43:36 present+ Benjamin_Young 06:43:47 regrets+ pchampin 06:43:49 gkellogg has joined #json-ld 06:43:58 regrets+ workergnome 06:44:07 ericP has joined #json-ld 06:44:09 present+ Gregg_Kellogg 06:45:10 -> https://github.com/w3c/json-ld-api/issues/26 https://github.com/w3c/json-ld-api/issues/26 06:47:14 present+ 06:49:56 ivan has joined #json-ld 06:50:02 white board from this morning https://usercontent.irccloud-cdn.com/file/v79LwpJr/IMG_20181026_084912464.jpg 06:50:04 ericP: the issue to talk about api#26 ... 06:50:07 ivan has left #json-ld 06:50:27 ivan: Logistics? 06:50:31 Rob: Yep, done :) 06:50:41 present+ 06:50:52 guest+ Eric_Prud'hommeaux 06:51:01 guests+ Eric_Prud'hommeaux 06:51:08 ericP: ... Gregg wrote it up. The issue is for @container @graph -- this property creates a blank node that ends up being a graph name for the mebedded triples. 06:51:33 ... so if we look at something without @graph, and we have a tree like [...], we could access it like var.input.value 06:51:58 ... In triples it turns into a graph b0 foo:input b1 ; b1 foo:value "x" 06:52:12 ... We could get that with a graph path similar to the code 06:52:46 ... Which is the same as the sparql ?a foo:input ?b ; ?b foo:value ?v 06:53:17 ... In my proposal, If you create a graph it still ends up traversable 06:53:55 ... but currently we end up with b0 input b1 ; b2:value "x" -- it's disconnected 06:54:10 ... The things we normally use to get around don't work 06:54:19 ivan has joined #json-ld 06:54:20 ajs6f: We need to make the bnodes the same? 06:54:32 ericP: Yes. We would otherwise need higher level logic to merge them 06:54:39 guests+ Eric_Prud'hommeaux 06:54:45 jyrossi_ has joined #json-ld 06:54:46 ... but we could just reuse the bnode 06:54:48 present+ 06:55:31 ... this was used for verifiable claims. The bit that was in the input was only a tiny bit of stuff. So warlking around in a large graph looking for a triple was easy as the wrapper was very small, but that isn't always the case 06:55:53 ... you would also otherwise need application level logic, or you can't query 06:55:54 scribejs, set yrossi Jean-Yves Rossi 06:56:05 arln has joined #json-ld 06:56:05 ... to traverse the data, you need to know it's valid 06:56:13 ajs6f: And hence ShEX issues 06:56:21 ericP: Yes, or SPARQL queries. 06:56:26 present+ Antoine_Roulin 06:56:52 ericP: The downside is that the blank node is the name of the graph, and a node in the outer graph 06:57:12 ... this could be the default behavior. There might be other ways to connect them n the future 06:57:29 rrsagent, draft minutes 06:57:29 I have made the request to generate https://www.w3.org/2018/10/26-json-ld-minutes.html ivan 06:57:56 ... need to get the same level of access in the RDF as in the JSON 06:58:32 ... one more thing, the way to connect the nodes with more configuration and more of a pain, one construct is to say that b1 has a focus of b2 06:58:44 ... that has a lot of reuse, but would mean writing into the rdf namespace 06:59:06 rrsagent, set log public 06:59:07 ... e.g. in clinical data. Here's a pairing of a graph name and a focus node 06:59:26 rrsagent, draft minutes 06:59:26 I have made the request to generate https://www.w3.org/2018/10/26-json-ld-minutes.html ivan 07:00:05 ericP: Objection is typically that if there's a property, is it about the graph or about the node 07:00:17 gkellogg: implies the name of the graph has meaning 07:00:22 ericP: Yes, but it's a blank node 07:00:44 ... but what happens if it has @id? I think the answer there is both a node name and a graph name 07:01:18 azaroth: What's the range of foo:input? 07:01:30 ericP: union of named graph and the graph node class 07:01:39 ... which doesn't bother logicians, but does bug engineers 07:01:53 hsolbrig has joined #json-ld 07:01:55 gkellogg: Not the use of every graph container 07:02:15 ... where the graph appears with the value of a statement and doesn't have their own declarative statement 07:02:23 ... should we just use the graph name as the subject in that case 07:02:29 ... which would allow for the follow your nose 07:02:43 ericP: everything inside the input, all of those triples have the same subject 07:03:02 ajs6f: Trying to think of situations where I would want either way 07:03:08 gkellogg: You could just declare the subject 07:03:30 bigbluehat: That maps cleanly to the expection when used -- once typed out I expect it to work like that 07:03:51 ... to end up detached would be bad. 07:04:12 present+ hsolbrig 07:04:40 ... it breaks round tripping. 07:04:46 scribejs, set arln Antoine Roulin 07:04:53 guests+ arln 07:05:00 ... there's times when you use @graph like a packaging format 07:05:05 ... here's a bundle of stuff 07:05:16 ajs6f: as Gregg says in that case put in an explicit subject 07:05:29 bigbluehat: In @container @graph the implication is that they're connected 07:05:41 ... once you lose that, you'd just stay in JSON 07:06:40 azaroth: so the proposal is that for @container @graph, when the subject is not explicitly set, then the default is to reuse the blank node 07:07:19 ivan: A more general uncomfortable feeling. We introduce another micro-rule. they all make sense by themselves, but when you pile them up you get a language that's idfficult to understand 07:07:31 ... we don't take a simpler approach 07:08:00 ericP: It seems the argument is more persuasive in the other direction 07:08:23 ivan: I don't go into the particular issue, but that we just got as a proposal -- if this and that and that, then ... 07:08:32 ... this is the proposal, it's not a straight forward thing 07:08:35 ... this is what I don't like 07:08:46 ... we pile up lots of these things and end up very complex. 07:09:20 ... We should talk about URI resolution. e.g. with vocab and this and that. 90% of the people on the call didn't follow what Gregg was explaining 07:09:41 ... not anything wrong with what Gregg says, the reasoning steps are all okay by themsevles, it's the overall thing that becomes complicated 07:10:00 ... the containers in 1.0 were used only for one thing, now we add a lot more 07:10:03 +q 07:10:22 ... we continue to do that. Don't want to get to the technical details for this issue, just at the overall pattern 07:10:40 ericP: I think the argument here is that the status quo is harder to explain, more surprising 07:10:55 bigbluehat: Current situation is accidental. 07:11:01 ... this proposal seems more natural 07:11:30 ajs6f: there's some tension between avoiding surprise and keeping things easy to learn. In this case there is complexity, but its less surprising 07:11:51 ivan: As a zero level question, why do we need the container graph? 07:12:06 ... Some community needs something, so we add a new quirk 07:12:21 bigbluehat: @graph gets everyone's hackles up. So we got @container @graph 07:12:38 ... from a JSON developer's perspective, they need tools to get from the tree to the graph structure 07:12:58 ... need to not annoy both groups 07:13:10 ... this one to me resolves an issue from the RDF side 07:13:16 q? 07:13:23 ack simonstey 07:13:40 https://w3c.github.io/json-ld-syntax/#ex-85-implicitly-named-graph 07:13:46 simonstey: Going through the spec, in example 85, for graph ontainers. I wasn't sure about the original sample 07:14:18 ... it shows two graph objects, but if you look at the statements in the playground, it's not what the original version has. They don't match the expanded version in the spec 07:14:27 ... the playground already does this reuse 07:15:10 ajs6f: People might be reliant on the feature? 07:15:43 azaroth: what does the spec say now? 07:15:52 gregg: it makes you create a new blank node 07:16:24 ivan: I repeat what I said :) From a point of view of consistent view of hwo JSON-LD behaves, what is done today is the right thing to do 07:17:08 ... the various things that a container contains is pieces of graphs. Inside is different nodes. So reusing the same bnode internally and for the graph, I understand it's handy, but it does not fit the model for the JSON-LD world 07:17:34 ... we could hack it around with a micro-rule, but from a JSON-LD consistency PoV it's not right 07:17:47 ... not a formal objection but I disagree 07:18:07 ajs6f: There's a lot of opportunities -- there's other ways to do it 07:18:25 ericP: If you could parameterize the behavior and let the user decide whether they get this behavior or the other 07:19:06 ivan: We have the syntax in the example. We can name the bnode explicitly 07:19:39 gregg: what does container: graph mean? You're putting a box around some of the information so that it's part of a separate graph. 07:20:17 ... but it means that input has a value that is a named graph. 07:20:22 ivan: That's what it means 07:20:49 ajs6f: You're right, but eric is not asking to uniformly conflate them 07:21:03 ivan: then a separate syntax? 07:21:23 ... we would have two types of containers, one graph container behaves as it should, and another that does something extra 07:21:31 ... it pulls in the name into the internals of the graph 07:21:37 ajs6f: It's a very common idiom 07:22:03 ivan: I understand. The problem is that we always follow perfectly valid rules, but we need to look at the overall result 07:22:15 ... for many people JSON-LD is very scary because it's so complicated 07:22:30 ericP: But has better adoption 07:23:12 ivan: we do something very strange - and mayve we need to acknowledge it -- we work with people from all corners of JSON usage and try to push them into the linked data world 07:23:25 ... so you might lose the LD people as JSON-LD becomes an incredible mess 07:23:54 ... you have people working with patterns of usage, but if I come from the LD world and just want to use JSON-LD as a serialization, and I know what I'm doing, then for me the usage is very complicated 07:24:05 ... I don't think in the fixed patterns, I just want to put a graph and get unexpected results 07:24:27 ericP: In this case you have a disconnected graph, and you can do that with the expanded form 07:26:04 [... more similar discussion ...] 07:28:33 azaroth: So the alternate would be to have an explicit link. Would that be automatic, or put into the data? 07:28:52 gkellogg: I don't think you can have the named graph in the source and the graph? 07:29:07 ... within the named graph you have a triple whose subject is the graph 07:29:36 ... can create a statement with a blank node, and the meaning lies with the predicate 07:29:42 ... would not want to automatically introduce it 07:29:51 ericP: When you have a graph that has two of those, what does it mean? 07:30:05 ... it's attractive, and I've done it but was an interim measure 07:30:29 gkellogg: if we keep the status quo, and the name of the graph is not visible, the implications for writing a shape for trying to match things 07:30:32 s/attractive/unattractive 07:31:01 ericP: THere's a step where you collect things. But when you get to the internal graph you've already collected it. You'd need to do cycles of gathering and validating 07:31:16 ... without some predictable connection, there isn't a way to do it without a procedural language 07:31:24 ajs6f: You have to assume validity in order to validate it 07:31:42 ericP: Can do various things 07:31:48 ajs6f: But it's application level knowledge 07:31:56 ericP: Yes, you'd have to customize a lot of stuff 07:32:05 ... here you do an unbound sparql query 07:32:14 ... which is considerably more expensive 07:32:25 ajs6f: you still might need to apply application knowledge 07:32:58 ericP: Could find nodes that don't have inbound links, but you can't assume that's always the case with inverse properties etc 07:35:54 azaroth: (restates problem) 07:36:23 ivan: It comes from container: graph. As a value, I have an object whose keys refer to something specific 07:36:30 ... a language refers to the language of the string 07:37:03 ... but the graphs are very different beasts. They must have an identifier, or we generate them one 07:37:16 ... it's different from language, so maybe the container model is not fit for that purpose 07:37:25 ... we must talk about identifiers and how they're used elsewhere 07:37:27 q+ 07:37:36 ... when I use the container for a language, it's simple 07:37:44 ... it's by the natural language 07:38:20 ... container is a way to categorize certain things, and they become keys 07:38:32 ... I have a bunch of strings with a category, the language 07:38:42 ... I create an object that uses the category as a term 07:38:54 ajs6f: Containers as maps 07:39:00 gkellogg: Not all though 07:39:08 ivan: Yes, @container list is a very different animal 07:39:21 ericP: Not that it's a graph, just the container 07:39:34 ... if you want to build a named graph then have a different construct 07:39:43 gkellogg: Can have a map of graphs with @id 07:39:50 ... an array of keys 07:40:02 ivan: should take a step back to look at containers and mapping 07:40:12 ... is it possible to have a clearer model and separate the two things 07:40:24 ... and then come back to it if there's a more natural way to model it 07:40:36 ... if it's a blank ndoe, then I can assign and reuse 07:40:50 ... user has the choice to reuse. 07:41:01 gkellogg: If you use a graph id map, then they have to name them explicitly 07:41:19 ... VC and WoT are in a similar situation, I think 07:41:36 ivan: Yes, but do we now add another special quirk?? 07:41:46 ajs6f: Depends how many people are interested in it 07:41:55 ivan: Then we need a template language 07:42:34 hsolbrig has joined #json-ld 07:44:50 ... Propose to leave this alone for a little and look at containers in general 07:45:06 ajs6f: And path is in here too now, for things people are asking for 07:45:19 ivan: Could use different term, they're not containers like list or set 07:45:40 gkellogg: Could introduce @map 07:45:59 ivan: and then add in obsolete terms for indexing 07:46:15 ajs6f: Seeing patterns, and then clarifying how to get them into the syntax 07:46:26 ... hence microrules 07:46:34 gkellogg: Also about the interpretation of the value space 07:48:00 azaroth: Exactly equivalent to https://github.com/w3c/json-ld-syntax/issues/77 07:48:35 gkellogg: raising warnings :( and makes algorithms harder 07:48:48 azaroth: priority of constituencies puts algorithms very close to the bottom 07:49:00 ivan: Can have a raise warning or not flag in the API 07:49:18 ... algorithms will be slightly more complicated, but only affect 5 or 6 people 07:49:25 ajs6f: And we probably know most of them 07:49:50 ericP: Regardless of how you construct the syntax, need to deal with nesting in JSON 07:49:59 gkellogg: There's the expectation of connectivity 07:50:22 ericP: Rleatively simplisitic user, but that's typical. If it's more nuanced, I want the default to not produce pathological graphs 07:50:57 gkellogg: If we created a new @map thing and put graph / id maps in there, so would have a reducced use case for @container, and we're back to the same issue 07:51:16 ... container is a graph, and you're in an implicitly named graph. Now where are the rest of the things? 07:51:31 dlongley has joined #json-ld 07:52:19 ajs6f: syntactic mechanism. If containers were minimized, could be nicer. If we could add metadata to containers, we could maybe add the information. But would need very strong notion of containers 07:52:29 ericP: That's a step in teh right direction 07:52:58 ...trying to deal with existing sem web ... two camps. People who abuse the node to be the graph name. And then there's people who keep them separate. 07:53:06 ... but theres a mechanism to connect them 07:53:28 ... trick is normally HTTP fragments. Use the # and then HTTP connects them 07:53:38 ... those two camps are not going to come together 07:53:48 ... at least half the people are going to be miffed 07:54:02 ... so putting in controls will help 07:54:30 ivan: more inclined to look at someting more complicated, but long term more pwoerful, and accept that we need a transformation / template language 07:54:36 everyone: ... 07:54:59 ivan: We see a user community that uses a template as that's how they think. We try to come up with syntactic quirks so the templates fit in the model 07:55:27 ... that's where we get in trouble. If we had some transformation language, it could help. 07:55:49 ... not sure it's realistic, and not familiar with framing details 07:56:04 ... can that be added to framing model? Not a rec, so don't have backward compatibility restriction 07:56:15 ... if we do something there, that would mean a cleaner separation 07:56:53 ... if this is taken up by a frame and uses the same bnode. Can express it in JSON-LD. It's all doable already. 07:57:29 ericP: have about 100 hours thinking on this in ShEX. Both dealing with a case where there's an algorithmic mapping between a graph node and a node in the graph 07:57:33 ... need to get from one to the other 07:57:52 ... expressivity we discovered we needed was at a minimum to chop off or add a hash based identifier 07:57:57 ... for the range 14 folks 07:58:01 ... ability to say it's the same 07:58:22 ... and then as you work down into the people who have pipeline techniques, you end up with regexps 07:58:34 ... that lets you use node identifiers that are relative to the base 07:58:42 ... two nodes that are different but related 07:58:52 ... regexs look at the graph labels 07:58:57 ... to deal with existing data 07:59:33 ... question is how much you want RDF data to drive this. 07:59:56 ajs6f: And the other extreme is JSON devs who are told they have to do something. Some things don't make any sense at one or the other end of the spectrum 08:02:08 IRC and phone-call folks, I'm going to type out the examples EricP just mentioned, because they're just triples, and this way they will be instantly in the minutes. 08:02:25 First: the nodes are disconnected: 08:03:57 q? 08:03:58 ack azaroth 08:04:28 hangon, change of plan for the examples-- we're going to get a link to a picture in here, because the examples are graphically very concise and more useful as pictures. 08:04:33 getting that done now 08:08:56 Topic: Disambiguate uses of @type #77 08:10:10 link: https://github.com/w3c/json-ld-syntax/issues/77 08:14:14 PROPOSAL: add a feature at risk that the implicitly identified graphs will share the bnode with the unidentified member of the graph, on the grounds that the user community most in need of this would expect it, and the community that would be horrified by it better understands the solution of explicit naming 08:14:17 +1 08:14:42 +0.0000001 08:14:50 +1 08:15:25 +1 08:16:01 +1 08:16:04 RESOLVED: add a feature at risk that the implicitly identified graphs will share the bnode with the unidentified member of the graph, on the grounds that the user community most in need of this would expect it, and the community that would be horrified by it better understands the solution of explicit naming 08:16:15 Assuming +1s from Adam and Benjamin 08:17:30 +1 08:22:39 scribenick: ajs6f 08:23:00 ivan: can @container be used with @type to separate string, dates, etc. 08:23:16 ... if so that is again an argument to deconflate all the meanings of @container 08:23:35 gkellogg: might make sense but isn't very useful 08:23:56 ... the datatype for all variations would be rdf:HTML, so you wouldn't be able to also work by languages 08:24:33 ivan: right. but even gkellogg had to think about whether you _can_ use @type with @container, which tells us that we need to simplify 08:25:03 ... a container-mapping for @dataype-- it's not clear whether it would be useful 08:25:26 azaroth: if rdf:Literal is the datatype... 08:25:39 ... if you had some HTML, some strings, maybe you can sort it out then 08:25:53 ivan: so mapping via datatype is questionable 08:26:30 gkellogg: I understand the proposal to be a new keyword @datatype to be used in contexts to signal datatypes, as @type does today 08:26:47 ... letting us mark that usage of @type as obsolete 08:26:59 ivan: even today, you could use it via aliasing. 08:27:19 gkellog: comapction wouldn't do what you want if you did that 08:27:53 ivan: we have an example from Publishing WG where the alias would be useful 08:28:55 PROPOSAL: add @datatype for use with value nodes that would be a synonym only in those situations for @type 08:28:59 +1 08:29:00 +1 08:29:02 +1 08:29:18 +0 08:29:41 +1 08:29:58 +0.5 08:30:05 Assuming bigbluehat is +1 08:30:08 RESOLVED: add @datatype for use with value nodes that would be a synonym only in those situations for @type 08:32:24 dmitriz has joined #json-ld 08:33:03 dlongley has joined #json-ld 08:35:36 Adjourn until top of the hour 08:35:41 (11:00 CET) 09:00:30 We (by which I mean I) messed up the agenda 09:00:48 The joint meeting is actually at 1:30 local time, not 11 09:01:00 So we're still doing our own thing for the next 90 minutes 09:07:51 arln has joined #json-ld 09:08:12 link: https://github.com/w3c/json-ld-syntax/issues/72 09:08:13 scribenick:ajs6f 09:08:20 laudrain has joined #json-ld 09:08:25 TOPIC: allow relative IRIs for @vocab 09:08:26 present+ 09:10:13 gkellogg: in JSON-LD, vocab-realtive and document-relative IRIs are resolved differently. we've already looked at this problem 09:10:25 ... and offered the ability to set @vocab="" 09:10:38 ... which allows vocab to be resoved against the document base 09:11:06 ... motivated at least in part because in other RDF formats, that distinction doesn't exist 09:11:18 ... so there was a parity issue against other serializations 09:11:44 ... this issue goes further, and lets @vocab get set to any relative URI, which would then be evaluated against the document base 09:13:47 ... the proposal includes that if a @vocab is already set and a new relative @vocab comes along, one simply string-appends the new one to the old one 09:13:58 jyrossi_ has joined #json-ld 09:14:04 present+ 09:14:32 azaroth: in the case of a base that came from HTTP with a # on the end, that would get lost 09:15:33 gkellogg: this also adresses the problem that Manu raised inthe context of blank-node-properties. 09:16:49 azaroth: if you set vocab to ../# and you had example.org/ns then you get example.org/ns../# 09:16:51 @vocab: 09:17:19 @vocab: "../#" and base is "http://example.org/ns" then you get "http://example.org/ns../#" 09:18:53 ivan: as an editorial matter we must make very clear that this is string concatencation, not IRI concatenation 09:19:10 rob: are there good rules for determing relativve vs. absolute IRIs? 09:19:16 ivan: Look for the scheme 09:20:11 ivan: I am almost sure that the URI spec defines that very clearly 09:22:04 azaroth: but this could be a security problem if a malicious actor sets a CURI prefix of "http" to some malicious address 09:22:13 ivan: also the same thing with base 09:22:38 gkellogg: We can't really know 09:22:51 azaroth: we can just advise people of the security concerns 09:22:56 ACTION: azaroth to make a security consideration issue re relative IRI concatenation 09:23:07 ivan: do we check for acceptible scheme 09:23:16 ACTION: azaroth to create security consideration re javascript URIs and relative IRIs 09:23:18 ... ? what about Javascript URIs (bookmaarklets) 09:23:30 gkellogg: we don't now check for defined schemes 09:23:32 "@vocab": "javascript:" 09:24:47 bigbluehat: it's the responsibility of the document loader to worry abot this 09:25:03 ... it could just choose not to resolve troubling URIs 09:25:23 ivan: so you put together a URI from the JSON-LD (could happen in many ways). 09:25:34 ... at that level, do we add a securiyt check? 09:25:48 bigbluehat: that's the job of the person using the URI 09:25:53 Or rather "@vocab": "javascript:document.alert('hi!');" 09:26:37 bigbluehat: this isn't a job for th syntax 09:26:48 ... e.g. data: can hide _anything_ 09:26:59 ... data: URIs 09:27:20 gkellogg: this could be used for maliciousness, but it's on the users of the URIs to be careful 09:28:14 azaroth: we don't do path expansion, we're doing string concat here. so we won't catch a lot of stuff 09:28:49 bigbluehat: but the advantage of string concat is that it supports non-pathy URIs 09:29:49 gkellogg: @vocab is used only for properties 09:30:34 several: and generally people don't dereference properties, and nothing in our algorithms says that they should 09:31:09 gkellogg: we can modify the API to return only URIs of some form. 09:32:19 bigbluehat: we can say "we never use these URIs, so there's no concern w/i JSON-LD, but if users chooose to use them, the usual concerns about URIs from the wild apply" 09:33:36 gkellogg: we might consider softening the current restrictions in 3.6.3 09:34:22 ... to use IRI explansion and not string concatenation 09:34:33 ivan: I'm a visual type! 09:34:49 "@vocab": "http://example.org/ns/" and then "@vocab": "/" 09:35:32 currently you get "http://example.org/ns//" which is unexpected for relative IRIs 09:35:45 And the expectation would be "http://example.org/" 09:36:31 ivan: are we making the distinction between the two kinds of resolution disappear? 09:36:52 gkellegg: still the issue of concatenation vs. IRI resolution 09:37:15 gkellogg: how do I establish @vocab, vs. how do I use it? 09:37:37 ivan: if we are in @vocab we do string concat, it's clean 09:37:50 ... and users just have to know about that 09:38:13 ... let's don't mingle concatenation and IRI resolution 09:38:32 gkellogg: we're only interested in resolving @vocab when it is relative, that's all 09:38:42 ivan: You're right, but that's about implementing the system 09:38:54 ... I'm talking about end users 09:39:11 ... if we just have string concat for @vocab, that's clean, I understand that 09:39:20 ... even if we do IRI resolution instead over here 09:39:55 ... somewhere else. but any problems with doubled slashes, etc., are users problems to deal with 09:40:31 azaroth: if we went all the way to have @vocab itself computed and vocab terms resolved via IRI resolution, it breaks things 09:40:44 ... so lets stick cleanly to string concatentaiton 09:40:55 gkellogg: Ok, but these are different use cases. 09:43:51 ivan: there is an actual regexp to recognize absolute IRIs, so we can rely on that 09:44:08 hsolvig: doesn't the CURI spec speak to this? 09:44:16 gkellogg: we don't use CURIs, tho 09:44:23 hsolvig: why are we using something else? 09:44:58 gkellogg: every RDF serialization uses its own way to discuss short URIs 09:45:14 ... gkellogg then names more than you would think he could off the top of his head 09:45:52 azaroth: we can't necessairly construct all legit IRIs, but most of what we can't is unusual enough not to be problemtatic 09:46:37 ... if we stick with string concat, we avoid this 09:47:05 ... if you construct stupid @vocabs, that's your problem 09:47:30 PROPOSAL: Allow IRIs to be constructed by string concatenation with multiple @vocabs 09:47:36 bigbluehat quotes Chaucer 09:48:02 PROPOSAL: Allow IRIs to be constructed by string concatenation with multiple @vocabs, with appropriate security consideration section 09:48:05 +12 09:48:07 +0.9 09:48:07 +1 09:48:12 +1 09:48:13 +1 09:48:14 +1 09:48:36 +1 09:48:41 RESOLVED: Allow IRIs to be constructed by string concatenation with multiple @vocabs, with appropriate security consideration section 09:48:44 +1 09:49:01 the Chaucer quote fwiw https://english.stackexchange.com/questions/139073/meaning-of-if-gold-rust-what-shall-the-iron-do 09:49:16 TOPIC: expanding @vocab properties consistently 09:49:19 link: https://github.com/w3c/json-ld-syntax/issues/56 09:49:59 gkellogg: the concern is that the same term expands differently in doifferent places 09:50:44 ... gkellogg then descirbes the example in the issue 09:53:05 azaroth: the example has two triples in it: 09:54:07 triples from the playground from the first example in #56 09:54:11 "the sidekick" . 09:54:11 _:b0 . 09:54:11 _:b0 . 09:55:46