RDF-Star *

22 Jan 2021


AndyS, rivettp, pchampin, gkellogg, olaf, pfps, TallTed


<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

pending actions

<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

N-Triples*: call for volunteers

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

Continue last week's interrupted discussion on Syntactic Sugar / Mime types

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


<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

Discuss the new semantics proposal

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

Summary of Action Items

[NEW] ACTION: gkellogg to contribute N-Trnples* section

Summary of Resolutions

    [End of minutes]

    Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version (CVS log)