15:53:54 RRSAgent has joined #rdf-star 15:53:59 logging to https://www.w3.org/2024/02/15-rdf-star-irc 15:54:15 Agenda: https://www.w3.org/events/meetings/5ecc5c5f-5cd2-410c-b97c-6b13c6b843f1/20240215T110000/ 15:54:16 clear agenda 15:54:16 agenda+ Choosing between the options #1, #2 and #3 in [1], as decided in [2] 15:54:16 https://github.com/w3c/rdf-star-wg/issues/1 -> CLOSED Issue 1 No activity (nor even README) since WG approval in August (by TallTed) 15:54:16 https://github.com/w3c/rdf-star-wg/issues/3 -> CLOSED Issue 3 Convert SPARQL specs to ReSpec (by afs) [complete] 15:54:16 https://github.com/w3c/rdf-star-wg/issues/2 -> Issue 2 RDF* in CBOR? (by ChristopherA) 15:55:20 TallTed has joined #rdf-star 15:56:11 AndyS has joined #rdf-star 15:56:45 pfps has joined #rdf-star 15:58:04 niklasl has joined #rdf-star 15:58:06 zakim, this will be rdf-star 15:58:06 ok, AndyS 15:58:09 rubensworks has joined #rdf-star 15:58:31 TallTed has changed the topic to: RDF Star WG - 2024-02-15 agenda: https://www.w3.org/events/meetings/5ecc5c5f-5cd2-410c-b97c-6b13c6b843f1/20240215T110000/ 15:58:51 tl has joined #rdf-star 15:58:57 RRSAgent, pointer? 15:58:57 See https://www.w3.org/2024/02/15-rdf-star-irc#T15-58-57 15:59:36 RRSAgent, draft minutes 15:59:37 I have made the request to generate https://www.w3.org/2024/02/15-rdf-star-minutes.html TallTed 15:59:40 RRSAgent, make logs public 16:00:43 present+ 16:00:46 present+ 16:00:56 present+ 16:01:01 olaf has joined #rdf-star 16:01:08 present+ 16:01:15 s|https://github.com/w3c/rdf-star-wg/issues/1 -> CLOSED Issue 1 No activity (nor even README) since WG approval in August (by TallTed)|| 16:01:17 s|https://github.com/w3c/rdf-star-wg/issues/3 -> CLOSED Issue 3 Convert SPARQL specs to ReSpec (by afs) [complete]|| 16:01:19 s|https://github.com/w3c/rdf-star-wg/issues/2 -> Issue 2 RDF* in CBOR? (by ChristopherA)|| 16:01:19 present+ 16:01:29 RRSAgent, draft minutes 16:01:30 I have made the request to generate https://www.w3.org/2024/02/15-rdf-star-minutes.html TallTed 16:01:37 present+ 16:01:37 eBremer has joined #rdf-star 16:01:37 present+ 16:01:38 ora has joined #rdf-star 16:01:53 present+ 16:01:53 present+ 16:01:54 present+ 16:01:57 present+ 16:02:12 chair: ora 16:02:12 present+ 16:02:13 gkellogg has joined #rdf-star 16:02:15 scribe: Tpt 16:02:24 present+ 16:02:29 present+ 16:02:38 present+ 16:03:02 RRSAgent, draft minutes 16:03:03 I have made the request to generate https://www.w3.org/2024/02/15-rdf-star-minutes.html Tpt 16:03:36 i|agenda+ Choosing|scribe: Tpt 16:03:49 draggett has joined #rdf-star 16:03:50 RRSAgent, draft minutes 16:03:51 I have made the request to generate https://www.w3.org/2024/02/15-rdf-star-minutes.html TallTed 16:04:03 present+ 16:05:25 fsasaki has joined #rdf-star 16:05:40 ora: the way I see it now is that option 2 seems to have a lot of support and personally I hesitate between option 2 and 3. Peter might have convinced me I support option 2. 16:06:07 ora: I would like to see if proponent of option 1 and 3 can be convinced to support option 2 to reach concensus 16:06:18 enrico has joined #rdf-star 16:06:22 ora: I would like to use the first half of this meeting for that 16:06:23 present+ 16:06:23 doerthe has joined #rdf-star 16:06:36 present+ 16:06:38 q+ 16:06:38 topic: the story so far, setting the stage to consider options 1, 2, and 3 of https://github.com/w3c/rdf-star-wg/blob/main/docs/seeking-consensus-2024-01.md 16:06:43 ora: and maybe vote in the second hour 16:07:06 ack pfps 16:07:27 s|topic: the story so far, setting the stage to consider options 1, 2, and 3 of https://github.com/w3c/rdf-star-wg/blob/main/docs/seeking-consensus-2024-01.md|| 16:07:27 i|the way I see it now| topic: the story so far, setting the stage to consider options 1, 2, and 3 of https://github.com/w3c/rdf-star-wg/blob/main/docs/seeking-consensus-2024-01.md 16:07:54 pfps: I think option 1 has no uniqueness requirements but some people supports it has 16:08:00 RRSAgent, draft minutes 16:08:02 I have made the request to generate https://www.w3.org/2024/02/15-rdf-star-minutes.html TallTed 16:08:19 pfps: uniqueness requirement: their can only be a single subject/predicate/object for each rdf:Statement 16:09:04 enrico: The fact is that that uniqueness in option 1 implies opacity. 16:09:12 that is, in option 2 <> and <> produces only one reification node 16:10:11 q+ 16:10:30 enrico: There are too much implicit understanding, to me 1 and 2 are assembly way of trying stuff but not all assembly make sense so we need for some of well-formeness 16:10:38 enrico: It's why I prefer option 3 16:11:02 ora: Question 1: how strongly are you in favor of option 3 or is there an option to move you from 3 camp to 2 camp 16:11:32 enrico: yes, the 2 camp allows a lot of freedom, we need to write a big best practices section to explain well-formness 16:11:41 enrico: it requires a lot of explanations 16:11:41 q+ 16:11:52 q+ 16:11:54 enrico: option 3 is self-explanable/error-free 16:12:16 ora: Question 2: if we have these two variants of option 2, can we identify pros and cons of these variants? 16:12:18 AZ has joined #rdf-star 16:12:23 ack tl 16:12:23 present+ 16:13:12 tl: If we go for formalizing occurrences, has it to go to the core or RDF or can we get by the concrete syntaxes we defined? 16:13:38 tl: In this perspective I am for a semantic extension and not extend the core 16:14:16 meeting: RDF-star WG biweekly long meeting 16:14:16 next meeting: https://www.w3.org/2024/02/16-rdf-star-minutes.html 16:14:16 previous meeting: https://www.w3.org/2024/02/09-rdf-star-minutes.html 16:14:22 tl: I highlighted in my email that some extension of option 1 can bring a lot of features 16:15:13 tl: we decided that the use cases are about occurences and we extended the syntax to talk about occurences but the types came back again. 16:15:23 RRSAgent, draft minutes 16:15:24 I have made the request to generate https://www.w3.org/2024/02/15-rdf-star-minutes.html TallTed 16:15:31 q+ 16:15:40 q+ 16:15:50 tl: thinking about it, we are missing an equivalent of option 1 as an extension to the model. 16:16:02 ack pchampin 16:16:05 tl: we don't need the intermediate blank node in option 2, it adds complexity 16:16:44 pchampin: one thing: well-formeness is not a semantic extension, it has to do with syntax 16:17:03 pchampin: my main argument against option 1 is peter's wording of "Frankenstein reification" 16:17:41 My worry about Option 1 is summed up in the problems with the seminal example. That these problems were in the motivation for RDF* and that they lasted for so long is, to me, strong evidence that any solution should make it hard to create this sort of bad modelling. 16:17:41 pchampin: the benefit of extending the abstract syntax is to have something stronger than "well-formeness" 16:18:04 q+ to discuss a way a parser might deal with the unlean graph issue with option 2 16:18:13 pchampin: My understanding is that this tread-off is not good enough for all parties 16:18:27 pchampin: if I have to pick a side, I prefer to extend the abstract syntax 16:19:03 pchampin: last point: I have a proposal: if we go for option 2, I have some ideas about ensuring the unicity constraint in practical way that might help with well formeness 16:19:07 ack doerthe 16:20:01 doerthe: I fear there 3 versions of option 2: "as syntaxic thing", "with well formeness" and "with well formness and unique blank nodes" 16:20:11 ack AndyS 16:20:15 doerthe: my question: why is well formness so important? 16:21:34 q+ 16:21:42 AndyS: I prefer option 3 because it makes decision on what well-formness is and allows to prevent some graph algorithm to make sense of the data 16:21:42 ack enrico 16:21:48 ack AndyS 16:22:03 AndyS: We should reflect on why RDF reification is not a success 16:22:18 q+ to talk about triple size and optimizing querying 16:22:36 enrico: Frankenstein example: as soon as we do inference we don't know what the original s/p/o are 16:23:12 s/inference/expansion 16:23:18 enrico: This is not backward compatible because upgrading to RDF 1.2 means they suddenly have to comply with RDF 1.2 constraints 16:23:38 Problem with Turtle predicate object lists : non-unique reification https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Feb/0005.html ("Case: Turtle predicate-object lists") 16:23:53 enrico: option 1: if people only use the macro then everything is ok, it fully compatible 16:24:10 gb has joined #rdf-star 16:24:10 enrico makes a good point: with option 1, people CAN create ill-formed graphs by using ONLY the syntactic sugar (the "frankenstein reification" case) 16:24:28 enrico: I believe we need some sort of unicity constraint, otherwise I can not give any meaning to the blank node. 16:24:50 q? 16:25:01 q+ 16:25:04 enrico: you can write that have no sense and don't map to any meaningful reification. We need to rule out these things or at least note them in the best practices 16:25:10 ack gkellogg 16:25:10 gkellogg, you wanted to discuss a way a parser might deal with the unlean graph issue with option 2 16:25:18 enrico: option 3 has not these problems, and it's why I prefer slightly option 3 16:26:01 q+ 16:26:37 gkellogg: about option 2 and parsers: the problem can be mitigated by collapsing blank node 16:27:10 ack pfps 16:27:10 pfps, you wanted to talk about triple size and optimizing querying 16:27:36 q+ 16:28:08 pfps: About the number of extra triples: I don't think it's a valid concern: either there won't be many quoted triples or there will be a lot and SPARQL implementation will add specific structures to manage them at any reasonable speed 16:28:16 as far as I have seen in RDF/SPARQL implementations, what consumes space is not the triples themselves but the supporting structures to allow fast querying. If there are a lot of quoted triples then quick querying will have to index the quoted triples somehow, probably ending up with about same amount of storage. 16:28:34 ack tl 16:28:40 pfps: ... and if there are a few triples it does not matter 16:29:49 tl: It's an advantage if implementations can use triples because they can still work with it. Number of triples is not something we should focus on. 16:30:11 tl: I expect people to work with the annotation syntax and it's what is important to me 16:30:34 q- 16:30:56 tl: we have to deal with the existing reification syntax anyway 16:30:58 present+ 16:32:07 ack AndyS 16:32:08 q+ 16:33:14 q+ 16:33:35 AndyS: On triple counts: what is a strength of RDF is that SPARQL is properly defined. Counts are important 16:34:19 AndyS: we need to define RDF-merge. This is the ability to take 2 graphs together without worrying. If we merge to valid graphs and can get an invalid one we miss something 16:34:31 AndyS: 2 and 3 are semantically equivalent because they use the same semantic 16:34:47 ack enrico 16:34:54 ora: I find that graph merging is the thing that moves customer to use RDF and not property graphs 16:35:06 :e rdf:subject :s1 . :e rdf:predicate :p1 . :e rdf:object :o1 . 16:35:14 enrico: About the Frankestein example: 16:35:20 :e rdf:subject :s2 . :e rdf:predicate :p2 . :e rdf:object :o2 . 16:35:32 Souri has joined #rdf-star 16:35:37 present+ 16:35:42 :e rdf:nameOf _:b1 _:b1 rdf:subject :s1 . _:b1 rdf:predicate :p1 . _:b1 rdf:object :o1 . 16:35:47 :e rdf:nameOf _:b2 _:b2 rdf:subject :s2 . _:b2 rdf:predicate :p2 . _:b2 rdf:object :o2 . 16:35:51 Take these 6 triples you can mix them up and can't go back to understand what is the first triple 16:35:58 RRSAgent, draft minutes 16:35:59 I have made the request to generate https://www.w3.org/2024/02/15-rdf-star-minutes.html TallTed 16:36:09 Opposite to option 2 when you keep the two triples 16:36:30 enrico: In option 1 you mix all subject/predicate/object of the same occurence of the reification. 16:36:58 s/Take these 6 triples/... Take these 6 triples/ 16:37:04 w.r.t. merging: last friday the discussion seemed to show that in option 2 the reification name (blank node) needs different merging rules, i.e. it's not a normal blank node, and no standard merge/union rules apply 16:37:32 q+ 16:37:40 ack pchampin 16:38:05 s/Take these 6 triples/... Take these 6 triples/ 16:38:05 s/Opposite to/... Opposite to/ 16:38:23 RRSAgent, draft minutes 16:38:24 I have made the request to generate https://www.w3.org/2024/02/15-rdf-star-minutes.html TallTed 16:38:30 w.r.t. enrico's point: there's always a way to mess up compound triple structures. 16:38:44 pchampin: my problem with Frankenstein reification: the syntaxic sugar does not prevent creating invalid graphs 16:38:53 pchampin: This does not play well for option 1 16:39:44 pchampin: the syntaxic sugar can be defined: whenever the 3 terms in the edge are bounds (IRI or literal)s we can generate a URI via some rules. 16:39:46 s|s/Take these 6 triples/... Take these 6 triples/|| 16:40:00 pchampin: every parser would generate the same IRI, the same node 16:40:21 RRSAgent, draft minutes 16:40:23 I have made the request to generate https://www.w3.org/2024/02/15-rdf-star-minutes.html TallTed 16:40:34 pchampin: whenever there is a blank node, parsers are supposed to generate the exact same blank node 16:41:10 pchampin: so, I believe this would restrict the proliferation of blank node and would merge as one would expect and generate the same numbers in SPARQL 16:41:32 q+ 16:41:33 pchampin: I am not a big fan but serves some purpuses 16:41:41 ack doerthe 16:42:15 q+ 16:42:19 doerthe: to come back to enrico example, it's not bad if we imply that s1 = s2, p1 = p2 and o1 = o2 16:42:57 ack AndyS 16:43:07 doerthe: I think the syntactic conditions somehow clashes with semantic conditions 16:43:14 s/... ... Take these 6 triples/... Take these 6 triples/ 16:43:14 ack enrico 16:43:15 q+ 16:43:28 RRSAgent, draft minutes 16:43:30 I have made the request to generate https://www.w3.org/2024/02/15-rdf-star-minutes.html TallTed 16:44:04 enrico: If you think in term of the semantic web stack, well-formness is based on unicity, and unicity in the ground of what? 16:44:26 q+ 16:45:06 doerthe, the fact that semantics "interferes" with well-formed-ness is indeed one of the concerns that I now have with well-formed-ness 16:46:02 enrico: the merging with a language with equality, pchampin trick would not work anymore 16:46:24 enrico: my trick would work: it concerns with the intermediate node, not with the subject of rdf:nameOf 16:46:26 ack AndyS 16:46:31 enrico: because sameAs elements in triples would lead to different triples 16:46:34 but I still prefer option 3, mind you :) 16:47:31 AndyS: Adding a deterministic URI would get round some issues on merge but compared to the looses, we can't get back to the subject/predicate/object 16:47:50 ack tl 16:48:17 q+ 16:48:21 tl: option 3 is supposed to have a mapping to triples, all problems with option 2 are also in option 3 16:48:33 q+ 16:48:35 tl: is someone arguing we don't need a mapping to legacy triples? 16:49:17 q- 16:49:21 tl: I can make strange case about option 2 because there is an other node and people can do a lot of things with it 16:50:38 tl: Option 1 is reduced to the core, the syntaxic sugar: << e | s p o >> 16:50:46 tl: everything else if for people to define 16:51:10 tl: this certainly enough to model property graphs 16:51:52 q+ 16:51:58 ora: 1. we have syntaxic sugar that gives us a graph that is well formed. If you go out bad things could happen. Let's ignore that and talk only about things that are well formed 16:52:06 ack AndyS 16:52:09 s/1./about option 1:/ 16:52:37 AndyS: to tl's option 3 vs option 2. If we pick option 3 we would define a mapping to RDF 1.1 as an entailment regime 16:52:50 AndyS: ... subject to what happens on merge 16:52:59 q+ 16:53:21 AndyS: SPARQL would define what the counts are and answer sets. 16:54:07 ack pchampin 16:54:53 pchampin: The point raised by doerthe is very valid: under some entailment regime a wellformed graph may entail a not wellformed graph 16:55:20 pchampin: saying that all bets are off if you do some entailments on your nice graph is concerning 16:55:21 ack enrico 16:55:25 pchampin: this makes things trickier 16:55:58 enrico: about the mapping option 3 into option 2 we can propose an implementation on option 3 by expending to things on option 2 like the CG report 16:56:14 <<:e|:s :p :o>> :b :c. :s owl:sameAs :s2. entails: :e :nameOf _:x. _:x :subject :s, :s2; :predicate :p; :object :o. The latter is ill-formed. 16:56:23 enrico: this mapping would only work in RDF. If you start adding equality and stuff this does not work anymore 16:56:56 ora: what is the option that everybody prefers? 16:57:16 ora: let's vote 16:57:26 3 16:57:28 3 16:57:29 3 16:57:29 still option 1 16:57:30 3 16:57:32 3 16:57:32 ora: put the number you prefer 16:57:34 Prefer option 3, can live with option 2 16:57:36 3 16:57:40 2 but can live with 3 16:57:40 option 3, with mapping for RDF 1.1 16:57:48 1 or 3 16:57:49 3, but could live with 2 16:57:50 1 16:57:54 q+ 16:58:02 3 > 2 > 1 > 4 ... still 16:58:03 Slightly in favour of 3 over 2, since it support many-to-many, and merges well. Needs mapping to 2 for RDF 1.1 support (ideally with PA:s gen-IRI-thing) 16:58:05 3 (2 without well-formedness would maybe work for me as well) 16:58:07 can live with 2 and 3 16:58:14 choice 3 (also I like the auto-naming idea if I understood it correctly) 16:58:19 3 16:58:39 ack ktk 16:59:21 ktk: I get tl's argument on I don't want to touch on RDF 1.1 but still have syntaxic sugar 16:59:48 ktk: I get AndyS on the safety 16:59:58 q+ 17:00:19 Alan_Snyder has joined #rdf-star 17:00:34 q- 17:01:12 ora: I see considerable support on option 3 now. I would like to see if we can reach out a consensus 17:02:46 Alan_Snyder: interested in using RDF with AI systems and also use ontologies, in relation with cryptocurrencies 17:02:50 scribe: AZ 17:03:09 RRSAgent, draft minutes 17:03:10 I have made the request to generate https://www.w3.org/2024/02/15-rdf-star-minutes.html Tpt 17:03:19 ... I had criticism towards RDF related to the complexities 17:03:37 ... but there are RDF success stories 17:03:55 ... and RDF-star can fill a gap for property graphs 17:04:17 ... I am located in Connecticut 17:04:30 does NYC still have a heart? 17:04:37 oh cool - where abouts in CT AZ? 17:04:59 ora: I see a lot of supports for option 3 17:05:10 ... but what about supporters of option 3 17:05:14 q+ 17:05:31 haha -- sorry just realized AZ is transcribing :) 17:05:41 s/supporters of option 3/supporters of option 1/ 17:06:18 tl: I think we only need syntactic sugar with the existing stuff 17:06:49 ... we don't need the extra things in the model, just in the concrete syntax 17:07:38 thomas, I think I could also live with option 1 without well-formedness, I am just really against well-formedness in its current form 17:07:39 ack AZ 17:07:47 scribe+ 17:08:20 AZ: I have not followed all the email discussions in the past few weeks, a lot of text to read 17:08:33 ... maybe I don't understand everything 17:08:56 ... In the 'seeking consensus' table, I'm not sure what the <( ...)> notation really means 17:09:27 ... I'm not certain that there is a consensus that my semantics, referenced by the table, is agreed on 17:09:44 ... Option 3 introduces something new which has not been tested or implemented. 17:09:45 q+ 17:10:06 ... Similar experience with RDF 1.1; inventions of the WG that were not implemented before do not work well. 17:10:30 ... My problem with option 2 is is the meaning of the 'rdf:nameOf'? Why not another predicate? 17:10:53 q+ 17:11:02 ... Probably the connection between the name (:e in the table) and the triple depends on everybody's interpretation. 17:11:30 ... The name rdf:nameOf seems to imply that it *identifies* the triple, so why not just identify the triple. 17:11:46 ... I see many reason for people to be not satisfied by this. 17:12:04 +1 for nameOf implying identification ("same as") 17:12:15 ... I think there is a way of doing option 2 with something like option 1 ; 17:12:49 ... if we stick with the original concrete syntax << :s :p :o >> (without the "e: |" part) 17:13:06 ... we can still put the ":e" outside of the << .. >> . 17:13:17 q- 17:13:28 ora: how unhappy would you be with option 3? 17:13:52 AZ: I like ktk's proposal of providing a way to consider this as pure syntactic sugar. 17:14:12 ... This would be consistent with the idea of having RDF basic and RDF full. 17:14:32 ack ktk 17:14:38 ... You could have RDF basic + syntactic sugar. May be that would be an acceptable middle ground for me. 17:14:57 ktk: AZ, what do you mean by "it has not been tested"? 17:15:23 ... Triple terms were implemented by some people, even if others waited. 17:15:40 AZ: implementations that we have seen implemented the CG proposal, which was not option 3. 17:15:41 q+ 17:15:48 ack tl 17:16:00 scribe- 17:16:14 tl: implementations of RFD-star preceded the CG report 17:16:19 q+ 17:16:22 q+ 17:16:33 ack pchampin 17:16:41 ... I would argue that implementations are closer to option 1 than anything 17:17:14 pchampin: yes, implementations are according to the CG proposal 17:17:37 ack ora 17:17:52 ... CG-conformant implem are very close to what option 3 says 17:18:05 +1 to have a basic+sugar profile 17:18:16 ora: it seems that option 3 is really the winner 17:18:25 q+ 17:18:47 ... there hasn't been this much agreement so far 17:18:59 ack enrico 17:19:12 q+ 17:19:25 q+ 17:19:32 enrico: I can write a document that's a cariant of what Andy proposed 17:20:00 ... with a better formalisation and we can discuss it 17:20:00 s/cariant/variant/ 17:20:18 ora: let us have a tentative vote 17:20:31 ack pchampin 17:20:50 pchampin: responding to AZ 17:21:06 ... the semantics is still to be discussed but this is on agreeing on the abstract syntax 17:21:43 ... and related to rdf:nameOf, I agree that it is not a good name 17:22:24 ... it has to be a very generic relation 17:22:24 ack niklasl 17:22:31 ora: pchampin can you find a wording for this vote 17:22:36 pchampin: ok 17:23:16 niklasl: option 3 solves my problems 17:23:39 proposed STRAWPOLL: the WG will pursue with the abstract syntax proposed in option 3, considering 'rdf:nameOf' as a working title 17:23:49 ... it satisfies my neds 17:23:55 s/ned/needs/ 17:24:03 would a basic profile be just with the syntactic sugar? ergo (close to) option 1? 17:24:53 I interpret basic profile to now mean option 2 (possibly with generated IRI:s för the edge nodes)? 17:25:04 ktk: we have to consider that option 3 is not fully designed, this is a vote to go forward 17:25:20 STRAWPOLL: the WG will pursue with the abstract syntax proposed in option 3, considering 'rdf:nameOf' as a working title 17:25:22 tl: that was my idea at least 17:25:27 +1 17:25:27 +1 17:25:30 +1 17:25:30 +1 17:25:31 +1 17:25:32 +1 17:25:35 +1 17:25:36 +1 17:25:36 +1 17:25:39 +1 17:25:40 +1 17:25:43 +1 17:25:48 +1 17:25:53 +1 17:25:58 -1 17:26:04 +1 17:26:06 +0 -- tentatively in support, but have some questions on option 3 I still need to work through 17:26:07 >+1 17:26:17 my vote, not as scribe, is that we can go with option 3 given the quasi consensus, even if I am not really satisfied with it 17:26:37 Alan_Snyder has left #rdf-star 17:26:39 +1 17:26:55 AlanSnyder has joined #rdf-star 17:27:09 q+ 17:27:43 ora: enrico, can you estimate how long it will take to have a revised proposal ready 17:27:48 ack gkellogg 17:28:13 gkellogg: we have a nomenclature issue because the one we used before is obsolete 17:28:14 RRSAgent, draft minutes 17:28:15 I have made the request to generate https://www.w3.org/2024/02/15-rdf-star-minutes.html TallTed 17:28:29 ... we need a notion of a triple descriptor 17:28:53 ... the "<< ... >>" does not appear in the abstract syntax 17:29:18 ... we need to figure out how these descriptors can be used within the abstract syntax 17:29:28 ice-cream? 17:29:30 ... replace rdf:nameOf with ... rdf:triple ? 17:30:05 q+ 17:30:14 ack enrico 17:30:14 q+ 17:30:52 enrico: is the syntax with "nameOf" only appear with this construction 17:30:55 q+ 17:31:16 ... so that there is a syntactic restriction, or not? 17:31:17 ack pchampin 17:32:12 pchampin: (in response to enrico) I would not make it illegal 17:32:42 ... (re. nomenclature) I like "triple term" but don't have a strong opinion 17:32:55 ... we also should discuss the name of the "nameOf" relation 17:33:19 ... in favour of "rdf:triple" 17:33:32 q+ on nested triple terms 17:33:39 ... also, should we allow nested "triple terms" 17:33:46 +1 to no nesting 17:33:51 ack AndyS 17:34:04 rdf:triple rdfs:range rdf:Triple . :D 17:34:08 AndyS: I was assuming we would define a range for rdf:nameOf 17:34:14 +1 to define its range 17:34:29