14:00:25 <RRSAgent> RRSAgent has joined #rdf-star
14:00:29 <RRSAgent> logging to https://www.w3.org/2024/08/09-rdf-star-irc
14:00:30 <Zakim> Zakim has joined #rdf-star
14:00:31 <enrico> enrico has joined #rdf-star
14:00:37 <TallTed> agenda: https://www.w3.org/events/meetings/6d0cd306-0be8-4267-865a-6272cc8d9da4/20240809T100000/
14:00:37 <agendabot> clear agenda
14:00:37 <agendabot> agenda+ Discussion on open problems in the semantics of the baseline
14:00:39 <TallTed> meeting: RDF-Star Semantics Task Force
14:00:39 <enrico> present+
14:00:41 <TallTed> rrsagent, draft minutes
14:00:42 <RRSAgent> I have made the request to generate https://www.w3.org/2024/08/09-rdf-star-minutes.html TallTed
14:00:44 <TallTed> rrsagent, make logs public
14:01:11 <TallTed> previous meeting: https://www.w3.org/2024/08/08-rdf-star-minutes.html
14:01:13 <TallTed> next meeting: https://www.w3.org/2024/08/15-rdf-star-minutes.html
14:01:34 <gkellogg> gkellogg has joined #rdf-star
14:01:59 <TallTed> RRSAgent, draft minutes
14:02:00 <RRSAgent> I have made the request to generate https://www.w3.org/2024/08/09-rdf-star-minutes.html TallTed
14:02:21 <gkellogg> present+
14:02:45 <enrico> Item propose for discussion by Andy: Discuss a roadmap for producing content for the RDF specifications and also identify any WG Notes. Objective: bring this roadmap to the full WG.
14:02:46 <doerthe> doerthe has joined #rdf-star
14:03:04 <TallTed> present+ TallTed, AndyS, gkellogg, pfps, niklasl, enrico, thomas, doerthe
14:03:40 <AndyS> AndyS has joined #rdf-star
14:03:47 <AndyS> present+
14:05:15 <niklasl> present+
14:06:41 <AndyS> scribe: AndyS
14:06:56 <AndyS> enrico: If we start from the baseline
14:07:58 <AndyS> ... we touch RDF Concepts, RDF Semantics, SPARQL, syntax documents
14:08:16 <AndyS> AndyS: including RDF/XML esp. rdf:ID.
14:09:15 <Souri> Souri has joined #rdf-star
14:09:19 <AndyS> enrico: talked to Stefan Staab about an improved reification based on RDF-star/CG
14:09:21 <Souri> present+
14:10:00 <AndyS> ... believing we have the syntax of the of the GC
14:10:37 <AndyS> gkellogg : N-triples, N-quads updated to latest syntax; Turtle partly done, more to do
14:10:46 <AndyS> ... to do - TriG
14:11:10 <AndyS> ... the WG has suggested we may not touch RDF/XML.
14:11:22 <AndyS> .. . some work in JSON-LD
14:11:49 <AndyS> s/.. ./.../
14:11:59 <doerthe> present+
14:12:15 <enrico> https://www.ki.uni-stuttgart.de/institute/news/Representing-Subjective-Facts-with-Epistemic-Knowledge-Graphs/
14:12:42 <AndyS> s/Stefan/Steffen/
14:14:06 <niklasl> https://w3c.github.io/rdf-turtle/spec/#reified-triples
14:14:31 <gkellogg> https://w3c.github.io/rdf-turtle/spec/#triple-terms
14:14:33 <TallTed> s/we may not/we might not/
14:17:53 <niklasl> q+
14:18:34 <thomas> q+
14:18:57 <AndyS> AndyS: We should scope a "note" to get a sense of how much work is involved.
14:19:21 <AndyS> niklasl: hope to contribute
14:19:32 <AndyS> ... also material in the RDF Primer
14:21:26 <AndyS> thomas: could put the material in the primer
14:23:06 <thomas> q+
14:23:11 <AndyS> niklasl: will ask around at workplace for suggestions
14:23:19 <AndyS> ack niklasl
14:23:23 <AndyS> ack thomas
14:23:37 <niklasl> q+
14:23:43 <AndyS> thomas: RDF/XML - don't need to touch it
14:24:11 <AndyS> ... but in the note need to refer to rdf:ID and explain why it's different
14:25:12 <AndyS> ack niklasl
14:25:46 <AndyS> niklasl: named graph can be used for some purposes not covered by transparent RDF-star
14:25:59 <AndyS> ... and there is "unstarring"
14:26:38 <AndyS> AndyS: where does "unstarring" go?
14:26:54 <AndyS> gkellogg: in RDF-Concepts?
14:27:18 <AndyS> ... because in the RDF namespace
14:28:03 <AndyS> AndyS: Impact on canonicalization - in the note?
14:28:12 <AndyS> gkellogg: yes
14:28:35 <niklasl> +1 to "re-starring" thoughts
14:28:52 <AndyS> ... and consider classical reification -> RDF-star -> unstar
14:29:15 <AndyS> ... and RDF-star -> unstar -> RDF-star
14:30:49 <AndyS> niklasl: may be a subclass of rdf:Statement for  RDF-star -> unstar -> RDF-star
14:32:47 <AndyS> (discussion about subclass + domain)
14:35:01 <AndyS> niklasl: will take stab at an outline
14:35:27 <AndyS> agenda?
14:35:51 <AndyS> enrico: baseline - syntax
14:35:58 <AndyS> ... full unrestricted
14:35:59 <gkellogg> zakim, next item
14:35:59 <Zakim> agendum 1 -- Discussion on open problems in the semantics of the baseline -- taken up [from agendabot]
14:36:10 <AndyS> ... well-formed for RDF entailment
14:36:51 <AndyS> ... open - triple terms only in the object position which could mean start with the well-formed syntax
14:36:54 <thomas> q+
14:37:16 <niklasl> q+
14:37:39 <AndyS> ... personal - I prefer not to have the triple term - object restriction at the lowest level.
14:37:56 <gkellogg> q+
14:38:02 <AndyS> thomas: prefer object restriction in the abstract data model
14:38:36 <AndyS> ack thomas
14:38:43 <doerthe> can you post again the current version of the baseline? I am back from holidays and wonder whether we changed
14:38:48 <AndyS> ack niklasl
14:39:24 <AndyS> niklasl: not in favour of unrestricted triple term in the data model
14:39:34 <enrico> q+
14:39:42 <AndyS> ... there is generalized RDF (non-normative)
14:39:54 <AndyS> ... lots of variations - confusing?
14:40:45 <doerthe> https://github.com/w3c/rdf-star-wg/wiki/RDF-star-%22working-baseline%22?
14:42:09 <AndyS> q?
14:42:33 <AndyS> ack gkellogg
14:43:33 <AndyS> gkellogg: currently RDF Concepts  - object restriction + notes on use of triple terms with rdf:reifies
14:43:39 <niklasl> q+
14:43:50 <doerthe> I am actually against the restriction
14:44:22 <doerthe> I also don't get it
14:45:04 <AndyS> enrico: not seeing the harm of triple terms in the subject at the data model level ... wanting to see a concrete illustration
14:45:10 <doerthe> how does object position prevent that?
14:45:16 <AndyS> thomas: (spoken example)
14:45:21 <niklasl> The seminal example mistake.
14:45:37 <pfps> q+
14:45:46 <niklasl> q-
14:46:00 <AndyS> (discussion)
14:46:19 <AndyS> ack enrico
14:47:46 <doerthe> ok, what makes the object position so special?
14:48:13 <AndyS> enrico: examples are outside the well-formedness
14:48:31 <niklasl> The well-formed syntax is good and needed, yes; especially if the "unrestricted" allows too much in "user space".
14:48:38 <AndyS> ack pfps
14:48:48 <AndyS> pfps: I agree with Enrico
14:49:30 <niklasl> q+
14:49:31 <AndyS> ... one of design philosophy of RDF is that you can do some really stupid thing with it
14:49:48 <niklasl> Why don't we want to be consistent here then?
14:49:50 <AndyS> ... with inconsistencies
14:50:11 <gkellogg> q+
14:50:25 <niklasl> q-
14:50:26 <AndyS> tallted: no way to handle literal-as-subjects at scale
14:50:26 <niklasl> q+
14:50:41 <enrico> q+
14:52:25 <AndyS> gkellogg: literals-as-subject may be an implementation
14:52:50 <AndyS> ... impact
14:53:10 <AndyS> ack gkellogg
14:53:19 <AndyS> ack niklasl
14:54:01 <AndyS> niklasl: maybe well-formedless is the solution - not clear to me ATM.
14:54:31 <AndyS> ... RDF/XML does not have literals-as-subject
14:55:37 <AndyS> gkellogg: at the moment (RDF-concepts), abstract syntax does not allow (literals or) triple terms in the subject position
14:55:59 <AndyS> ... reified triples can be in the subject position in syntax
14:56:58 <AndyS> ... and we expect/hope that most use is via "agreed syntax" not raw rdf:reifies.
14:57:02 <AndyS> q?
14:57:09 <AndyS> ack enrico
14:57:39 <AndyS> enrico: Triple terms are not like literals (not self-denoting)
14:58:10 <niklasl> Literals are tuples too (and denote resources).
14:58:11 <AndyS> ... RDF is not an object oriented language  - RDF is neutral to class and object-ness
14:58:43 <AndyS> ... often people write data in an object-like way but it is not required.
14:59:48 <AndyS> q?
15:01:05 <AndyS> ... Turtle - maybe have only the shortland syntax
15:01:36 <AndyS> NT is a syntax subset of TTL.
15:02:16 <Souri> q+
15:02:18 <niklasl> +1 for *at least* pushing well-formed; but yes, NT is the base
15:02:21 <gkellogg> q+
15:02:22 <AndyS> ... encourage the well-formed syntax restriction
15:02:22 <doerthe> I remember why I dislike the well-formed syntax, but I think that should better be discussed in mails. I will write one.
15:02:40 <AndyS> ack Souri
15:02:49 <enrico> yes, doerthe
15:03:36 <AndyS> Souri: as I see it, it is associating a URI/bnode RDF term with a triple term. Then use RDF term as you like.
15:03:39 <doerthe> so, I am against the restriction with the object position and even against well-formedness at all, but if we discuss these matters separately, I am with Enrico here
15:04:48 <AndyS> s/use RDF term/use that RDF term/
15:04:54 <doerthe> q+
15:04:58 <AndyS> .. I like the restrictions.
15:05:02 <AndyS> s/.. /.../
15:05:25 <AndyS> gkellogg: good points about consistency concerns
15:05:26 <thomas> +1 to Souri
15:05:48 <niklasl> I agree with Souri that it seems simpler to add as little as possible to the RDF 1.1 abstract syntax.
15:05:52 <Souri> q+
15:06:00 <AndyS> ack gkellogg
15:06:11 <AndyS> ack doerthe
15:06:26 <enrico> q+
15:06:48 <AndyS> doerthe: I don't think of the object position being different to the subject position
15:06:55 <AndyS> ack Souri
15:07:07 <AndyS> Souri: about the inverse
15:07:40 <niklasl> It's a directed graph, so I'd say it "affords" only pointing *to* more complex structures of literals and triple terms. But that's not a "logical" position, it's an "ergonomic".
15:07:45 <AndyS> ... if rdf:reifiies domain & range is defined then this restricts the subject
15:08:12 <doerthe> :isReifiedBy inverseOf :reifies ?
15:08:37 <AndyS> ... my emphasis is for rdf:reifies as identifier association.
15:08:39 <AndyS> q?
15:08:40 <doerthe> so, reified is simply not a "normal" propoerty?
15:08:48 <niklasl> Same as ex:nameOf owl.inverseOf foaf:name
15:08:49 <AndyS> ack enrico
15:09:06 <AndyS> enrico: thought experiment
15:09:42 <AndyS> ... if we define "rdf:isReifiedBy"
15:09:52 <Souri> q+
15:10:11 <AndyS> ... well-formedness gives the intent on position.
15:11:42 <thomas> q+
15:11:51 <doerthe> q+
15:11:59 <Souri> q-
15:12:35 <AndyS> thomas: not heard a use case for subject-triple terms.
15:12:59 <doerthe> just reverse the predicate you use?
15:13:03 <AndyS> q?
15:13:08 <AndyS> ack thomas
15:13:17 <AndyS> ack doerthe
15:13:38 <AndyS> doerthe: to Souri
15:13:57 <AndyS> ... rdf:reifies is a property which can be reversed.
15:14:29 <niklasl> Is that an argument for also allowing literals in the subject position too?
15:14:57 <AndyS> ... could define it specially but then it have sub-property
15:15:07 <AndyS> ... to thomas
15:15:12 <niklasl> q+
15:15:25 <Souri> rdf:type does not have an inverse defined in RDF, rdf:reifies/rdf:states could be treated similarly
15:15:32 <AndyS> ... I agree with Enrico - subject is not special compared to object
15:16:00 <AndyS> q?
15:17:13 <AndyS> ack niklasl
15:17:39 <AndyS> niklasl: one last thing - there is nothing special about the subject
15:17:48 <AndyS> ... it is wellformedness that is important
15:18:11 <AndyS> ... for me, it is the affordance of the graph
15:18:21 <AndyS> ... an ergonomic argument
15:18:24 <enrico> q+
15:18:43 <AndyS> ack enrico
15:18:56 <doerthe> it makes people using triple terms less?
15:19:04 <AndyS> enrico: this is what I mean by object oriented thinking.
15:19:35 <niklasl> Yes doerthe
15:20:09 <Souri> terms used as objects today can be more complex than subject, so we keep subject simple like today by allowing this complex thing -- triple-term -- to be only in the object position
15:20:23 <doerthe> ok
15:20:29 <doerthe> that point I get
15:21:44 <AndyS> gkellogg: three  cases:
15:22:17 <niklasl> And yes to Souri, I think like that too.
15:22:25 <AndyS> ... fill unrestricted syntax - triple terms in subject position
15:22:37 <Souri> from an implementation point of view=> parsers today have a complex logic for recognizing objects, so we just increase the complexity a bit more there to recognize triple-terms -- this allows subject parsing to stay simple
15:22:59 <AndyS> ... RDF concepts current restricts triple terms to object position
15:23:28 <AndyS> ... wellformed - only use with "rdf:reifies  triple term"
15:23:40 <AndyS> q?
15:24:33 <thomas> q+
15:24:36 <doerthe> so, you have an implementation argument here, Souri? That is something I would have to trust you on, but you really think it would be far more complex to program?
15:25:26 <AndyS> At the terminals level, nothing is content sensitive.
15:25:40 <AndyS> SourI: argues for simple parsing.
15:26:17 <gkellogg> q+
15:26:34 <AndyS> ack thomas
15:26:51 <AndyS> thomas: update on rdf:states
15:27:17 <AndyS> ack gkellogg
15:27:44 <AndyS> gkellogg: further implication of subject usage. If possible, people will use it.
15:27:53 <doerthe> thank you for answering Souri (I  like to understand all pints of view :) )
15:28:10 <AndyS> s/pints/points/
15:28:19 <enrico> 🍺
15:28:56 <AndyS> q+
15:29:20 <AndyS> enrico: implementations reflect an object-oriented POV
15:29:53 <gkellogg> ack AndyS
15:30:10 <AndyS> rrsagent, please publish minutes
15:30:12 <RRSAgent> I have made the request to generate https://www.w3.org/2024/08/09-rdf-star-minutes.html AndyS
15:30:26 <doerthe> ... wishful thinking, Enrico ;)
15:51:13 <gkellogg> gkellogg has joined #rdf-star
16:03:38 <gkellogg> gkellogg has joined #rdf-star
16:14:15 <gkellogg> gkellogg has joined #rdf-star
16:34:02 <gkellogg> gkellogg has joined #rdf-star
16:52:20 <gkellogg> gkellogg has joined #rdf-star
17:00:57 <pfps> pfps has left #rdf-star
17:02:11 <gkellogg> gkellogg has joined #rdf-star
17:20:30 <gkellogg> gkellogg has joined #rdf-star
17:32:29 <gkellogg> gkellogg has joined #rdf-star
17:43:54 <gkellogg> gkellogg has joined #rdf-star
18:13:09 <gkellogg> gkellogg has joined #rdf-star
18:30:42 <gkellogg> gkellogg has joined #rdf-star
18:38:10 <gkellogg> gkellogg has joined #rdf-star
18:56:12 <gkellogg> gkellogg has joined #rdf-star
19:15:33 <gkellogg> gkellogg has joined #rdf-star
19:33:40 <gkellogg> gkellogg has joined #rdf-star
20:03:25 <gkellogg> gkellogg has joined #rdf-star
20:03:28 <gkellogg_> gkellogg_ has joined #rdf-star
20:07:56 <gkellogg_> s/fill unrestricted syntax/full unrestricted syntax/
20:08:47 <gkellogg_> rrsagent, draft minutes
20:08:49 <RRSAgent> I have made the request to generate https://www.w3.org/2024/08/09-rdf-star-minutes.html gkellogg_