<ora> I have to drop at 15 past, because of a family commitment.
<ora> Also, I volunteer to scribe in our next meeting. Perhaps I will be sufficiently "
<ora> "up to speed" to do a decent job. ;-)
<pchampin> scribe: olaf
<pchampin> https://github.com/w3c/rdf-star/issues?q=is%3Aopen+is%3Aissue+label%3Aaction
<pchampin> https://lists.w3.org/Archives/Public/public-rdf-star/2021Jan/0065.html
pchampin: actions can be closed
... test suite
... only missing item is about SPARQL* syntax
... this may be left open for the moment
pchampin: no spec test for N-Triples*
... however, we are using this syntax already in the test suites
... anyone interested in writing/drafting this part of the spec?
... please chime in on the github issue
... shouldn't be too difficult to write that
<pchampin> ack: gkellogg
pchampin: the parsing may be more difficult b/c it has to recursive
... gkellogg: can write it
... don't think the recursion makes it difficult
... what will be harder will be to extend this for quads
<pchampin> https://www.w3.org/TR/n-triples/#h2_sec-parsing
pchampin: there is already something about triple construction
AndyS: NTriples grammar is just text
... so the task is to simply copy the right pieces from that
gkellogg: we need a separate discussion for NQuads
<gkellogg> ACTION: gkellogg to contribute N-Trnples* section
pchampin: discussion last week started about syntactic sguar
... then it moved on to mime types
... (do we need to extend them / new ones)
... any more comments on this now?
ora: want to confirm, is there an impliciation that there may be docs that are Turtle* but
... do not use any of the new RDF* features?
pchampin: yes
AndyS: does not work
ora: ACCEPT header may come into play in a client-server setting?
AndyS: yes, but then the server has to change its current behavior
... whole result needs to be inspected before responding to ACCEPT
... tried to find definitive text on mime types
... couldn't find
... some examples in which the syntax has changed but the mime type did not
... XML
... it's difficult to change mime types
... old counterexample is Turtle itself
<ora> (Unfortunately I have to drop. Bummer, interesting conversation.) :-(
AndyS: and SPARQL
... for these no change of mime type but the specs changed/evolved
gkellogg: raised examples of HTML and ??
... it would be an exception to make an incompatible change and then change the mime type
<pchampin> HTML is not a good example IMO, because browser have a history of "accepting" invalid HTML anyway
gkellogg: we are not authorized the spec for Turtle
... so, reference for text/turtle would still be to the Turtle doc
... proposal to extend the mime type
... difficult to find examples of groups who have done something like this
james: would take Turtle and NTriples as example
... if a client says it understand Turtle
... would not return something that the client cannot understand
AndyS: danger of locking out old clients
gkellogg: how was the transition for SPARQL?
AndyS: took years to happen
... for SPARQL 1.1, SPARQL 1.0 works
... still systems out there that only speak RDF 1.0
... semantics are different
... different triples may come out by parsing the same doc
pchampin: to james' concern, I agree
... not comfortable for the server to break the contrast
... contract
... but maybe we are overinterpreting mime type as a strong contract
james: how else to interpret it?
... 500 error should be return
AndyS: a robust client should read the whole doc in
... before passing it on to the application software
james: okay, but what's the effect of this on the contract?
AndyS: our group cannot change the mimetype
james: if you have a process in which the client has given ACCEPT with SPARQL with SELECT
... but then sends a CONSTRUCT query
AndyS: correct answer is you do not have to respect ACCEPT field
... server may still send back something in a different format
... no evidence in the doc about mimetypes that a change of the mimetypes is necessary
... what about */*?
james: in this case, the server can elect
AndyS: but then the server has to cache the whole response to figure out the media type before responding
james: agrees with greg's suggestion to have a profile
pchampin: but then the client has to be aware
... that the profile may break the content
AndyS: cannot do that because profiles are subset not supersets
... instead , parameter is needed
gkellogg: requiring a parameter is a way to solve james' concern
AndyS: parameters are not part of the registration
... profiles are
<pchampin> STRAWPOLL: keep the old content-types, but augment them with a profile or parameter to make it explicit that the content MAY contain RDF*-specific features
<pchampin> +1
<AndyS> "MAY augment"
<gkellogg> +1
<pchampin> STRAWPOLL: keep the old content-types, but provide a way to augment them with a profile or parameter to make it explicit that the content MAY contain RDF*-specific features
<james> +1
<pchampin> +1
+0
<thomas> -1
<AndyS> +0.5
<TallTed> +0.5 seems like the minimum possible
<pfps> +0
thomas: as long as this is just a CG, I feel bad about changing Turtle and not being explicit about it
... publishing something as Turtle but that is not actually (pure) Turtle is not a good idea
<TallTed> all old Turtle is also new Turtle-star, but some new Turtle-star is not also old Turtle
pchampin: things are moving on the front of the new proposed semantics
... it build on the RDF semantics
... in current proposal the semantic of embedded triples is rigid and close to literals
... difference between literals and IRIs is that literals are constraint to mean the same in all possible interpretations
... their meaning is defined by the datatype
... embedded triples in the current semantics are a bit like that
... i.e., their meaning is the same in all possible interpretation
... their meaning is essentially the triples themselves
... Are we okay with embedded triples acting as something like a literal?
<thomas> is this a strawpoll?
pfps: discomfort with triples as literals is that
... this adds lots of additional machinary that's not necessary
pchampin: understands the reluctance to add machinery
... to be clear, it's not a datatype
pfps: in contrast, there is a new datatype
pchampin: but this datatype is not for triples
pfps: it is a hidden datatype
... and hidden predicates
pchampin: if we didn't want to have bnodes inside embedded triples,
... (i.e., only ground emb. triples), then
... things would be much easier.
... however, the emb.triples have an internal structure
... that we want to preserve in some wa<
... way
pfps: yet, is this extra stuff necessary?
pchampin: what cannot be ensured otherwise is that
... emb.triples with different, say, subject are different things.
pfps: where is that in the things that are written down?
... have to stop adding desiderata at some point
pchampin: just trying to explain
... didn't want to sound like it must be like that
<pchampin> STRAWPOLL: should << :s :p :o >> and << :s2 :p :o >> always denote different things?
pchampin: question to others ...strawpoll
thomas: do not understand the question
<AndyS> FYI: Stardog has an opinion in this area.
<james> do :s and :s2 denote different things
<pfps> If they always do, then how can extensions make them the same thing if :s and :s2 are the same?
thomas: problem with the semantics, it is so specific
... specific to special problem
<Zakim> TallTed, you wanted to say Embedded-triples-as-subjects can't be simple literals, because literals aren't allowed as subjects in RDF. At minimum, they have to be treated as
thomas: it's not for the use cases that people will use it for
TallTed: emb.triples cannot be literals
... would have to be treated as synt.sugar for single-triple named graphs
... and special treatment needed because things may not be meant to be asserted
thomas: reification is just one way to go about adding statements about statements
AndyS: there were very long discussions about reification in the RDF WG
thomas: we can have a different semantics for embedded triples
... how to get from the ref.opacity to ref.transparency
... why go from a mainstream semantics to a specific one?
pchampin: why don't you go to standard reification if you want ref.transparency?
thomas: the proposed semantic have nothing to do with reification
<TallTed> There seem to be conflicting beliefs about what "everyone" wants to get from RDF-star. It might be worthwhile to open a large-scale poll on just that -- is it somehow easier/better reification/annotation; is it a bridge between RDF Graphs and Property Graphs; is it something else?
thomas: doesn't make sense as a general solution
pchampin: thanks for the lively discussion
<pfps> It is possible to get referential opacity by adding extra properties to standard reification. Then RDF* is just sugar for five (or so) triples.
pchampin: better understand the arguments of people