<gatemezing> hi all
<pchampin> scribe: gatemezing
<scribe> scribe: gatemezing
<pchampin> https://lists.w3.org/Archives/Public/public-rdf-star/2020Nov/0057.html
<scribe> Agenda: https://lists.w3.org/Archives/Public/public-rdf-star/2020Nov/0057.html
<pchampin> scribe: pchampin
gatemezing: I am Ghislain Atemezing, working for Mondeca (Paris), a SemWeb company.
... I have been in data-related groups at W3C.
... We have to manage metadata, so we are interested in RDF*.
<scribe> scribe: gatemezing
pchampin: specifies how to use the IRC to ask question..
... the next point is about the pending actions
<pchampin> https://github.com/w3c/rdf-star/issues?q=is%3Aopen+is%3Aissue+label%3Aaction
pchampin: which are available here https://github.com/w3c/rdf-star/issues?q=is%3Aopen+is%3Aissue+label%3Aaction
... we have 2 exactly
<Doerthe> p+
<Doerthe> no
pchampin: creates a test suites available here https://github.com/w3c/rdf-star/issues?q=is%3Aopen+is%3Aissue+label%3Aaction
<AndyS> Great to see the test suite forming!
gkellogg: suggest to use the manifest (..)
<Olaf> https://github.com/w3c/rdf-star/issues/8#issuecomment-734258118
Olaf: had another action related to the semantics... and sent an email with the github issue
... where people need to review and discuss it
... the new version is SA mode, different from the one in the paper is PG mode
pchampin: this will need to be added in the test suite.. something to decide within the group
... could be need more time for people to review? next week?
<Olaf> To clarify: the action was on the query semantics
Olaf: It sounds good to postpone the discussion next week
<pchampin> https://github.com/w3c/rdf-star/pull/39
<pchampin> http://champin.net/tmp/rdf-star-pr39.html#query-result-formats
Olaf: proposed by jeenbroekstra
... need a vote if to merge in the document
... that would give more confidence in the stability of the proposal
AndyS: putting things in the document is not a sign of agreement of the entire content...
... even if the vote is positive today
... the vote is just a way for showing a formal decision on our progress
... to give a summary: the idea is to extend the result format, a kind of "straithforward" extension
... don't think controversal
gkellogg: Do we want to extend other result format?
pchampin: that can be a seperate discussion but something to take into account
<pchampin> PROPOSED: merge pull-request 39 introducing extension of the XML an JSON format for SPARQL results
<pchampin> +1
<gkellogg> +1
<Olaf> +1
+1
<pavel> +1
<AndyS> +1
<jerven> +1
<thomas> +0
<james_> +0
<blake> +0
<Doerthe> +0
pchampin: please vote (+1, 0, -1)
... asking if pfps has voted
<pfps_> my computer died so I have no context
<pfps_> 0
<pchampin> APPROVED: merge pull-request 39 introducing extension of the XML an JSON format for SPARQL results
pchampin: thanking the voters
... relating issues regarding separate namespace and so on
pchampin: A good way to move forward is maybe to propose a test suite with a concrete results to decide on what we agree
... or disagree
<pchampin> https://github.com/w3c/rdf-star/issues/37
<pchampin> https://w3c.github.io/rdf-star/tests/semantics/manifest.html
pchampin: link available here https://w3c.github.io/rdf-star/tests/semantics/manifest.html of the manifest
<pchampin> https://w3c.github.io/rdf-star/tests/semantics/manifest.html#embeded-triples-everywhere
AndyS: What are the tests about?
pchampin: They are entailments tests based on if this happen then... based on some graph databases
... used for the tests. There is a thread on the mailing list about the topic
AndyS: Consider beeing in both direction, and the way you set up the engine, ....
<pfps_> But isn't SPARQL BGP ASK matching supposed to be the same as simple entailment if there are no variables in the BGP?
gkellogg: I wondering if we need to update that to reflect ...
... I recognize the simple solutions but how to compare them with others?
pchampin: The tests are not supposed to be the solution but rather discuss the validation in general
gkellogg: We need a practical guidance of what we expect from the output of the engines
... getting out of something that work or correspond to what we have to go
... I do agree we can separate the examination from the methodology
<pfps_> If you want to test pieces of the systems, then you have to be careful to isolate that piece, yes. That was the point of my message earlier today.
pchampin: I suggest we can on the different test
... I agree that the results can someone be misleading
<pchampin> https://w3c.github.io/rdf-star/tests/semantics/manifest.html#embeded-triples-everywhere
<pfps_> It's puzzling that Stardog fails the very first test
<pavel> Stardog intentionally does not support annotations on objects
AndyS: We could discuss on the general way and move forward
<pavel> that is, embedded triples in the object position
<Olaf> maybe it should be split into two separate tests then
pchampin: the first test passed also for EYE. see email
... pavel needs to explain?
<pfps_> Given that there is one system that handles embedded triples differently in subject and object positions, the other tests should include cases where there are embedded triples in object position.
pavel: We don't support this because we need minimum semantics for now
... and it's easy for Stardog to add more features than to retract them
<pavel> btw we have the exact same position about nested embedded triples
Who is here?
jerven: Question: why we don't have emebedded triples in the property position?
... we need to put in down somwhere in the proposal
Olaf: why would it be used for?
Is that use case somewhere in the use case list?
<AndyS> There is "generalized RDF" in RDF 1.1 that is more open.
<AndyS> :-)
pavel: we would be careful, guided by the use cases
... no issue from the technical part
<pfps_> Indeed, if the meaning of RDF* is defined as just a vocabulary extension to RDF, and embedded triples are IRIs, then embedded triples should be allowed in predicate position in surface syntaxes. However, it looks as if embedded triples have to be blank nodes in this definition of RDF*, so they can't be in predicate position.
pchampin: We should stick for now with the restrictions
<gkellogg> +1 to restricting the predicate position to IRIs
<pchampin> PROPOSED: mark embeded-triples-everywhere as approved
pchampin: we vote on each issue or group of issue
<pchampin> +1
<james_> +1
blake: I want to inquire a bit to see the aspects of embedded graph, embedded quad
<thomas> +1 to blake: keeping the possibility open to have embedded quads in the future
pchampin: A very good question by blake. There should be an issue for that in the repo. Yet another separate question
... that need to be checked and discussed
... Anyone wants to react?
<pchampin> ACTION: blake to submit an issue on embedded quads
james_: Embeded quad is actually in one of the use case. I react on the the point of using embedded triples in the predicate
... Describing a use case.
<pfps_> I don't see how embedded triples as predicates advances similarity to property graphs. I would need an example of a property graph to see how this might work.
Could james_ add that use case somewhere?
<Olaf> I don't understand
<pchampin> PROPOSED RDF* will allow embedded triples in subject and object position
<jerven> +1 if we rename the test to embeded-triples as subject and object (think about named graph for sparql*)
<pchampin> +1
<Olaf> +1
+1
<james_> +1
<pfps_> +1
<pavel> +1 (but i'd prefer 2 separate tests)
<Doerthe> +1
<AndyS> +1
<thomas> +1
pchampin: we have two missing voters
<gkellogg> +1
<blake> +1
<AndyS> Agree - 2 tests would be nice.
<pchampin> APPROVED: RDF* will allow embedded triples in subject and object position
<pchampin> ACTION: pchampin to split and rename test embeded-triple-everywhere
<pavel> we are not going to have time to vote on each test individually :)
sure pavel
pchampin: next test on identical embedded triples
... prefix : <http://example.com/ns#> << :a :b :c >> :p1 :o1. << :a :b :c >> :p2 :o2. MUST entail prefix : <http://example.com/ns#> << :a :b :c >> :p1 :o1; :p2 :o2.
... this use case can be viewed in neo4j or wikidata
... there are ways to go around them, since there are discussions
<pchampin> a?
gkellogg: I don't know if it's meaningful the test as it is
... it depends too much on how your parser acts not the abstract data model
pchampin: the abstract syntax is perfectly clear on that... see def of embedded triple
... I agree that the way is presented it can be misleading
AndyS: If you have the same line twice, what should happen?
<AndyS> << :a :b :c >> :p :o . << :a :b :c >> :p :o . ==> one triple or two?
<AndyS> c.f. [] :p :o . [] :p :o . ==> one triple or two?
Olaf: this is my understanding since the begining and I don't want to change that
pfps_: Whether is possible to construct embedded triples by other mean?
... if you define RDF* as a mapping to RDF, that definitively an issue
<blake_> << :a :b :c >> :p1 :o1.
<blake_> << << :a :b :c >> :p3 :o3 >> :p2 :o2 .
<blake_> ==== MUST entail? =====
<blake_> << :a :b :c >> :p1 :o1; :p3 :o3 .
blake_: what bout the above examples?
pchampin: a mix of variation of PG and SA mode
<pfps_> A big question for RDF* is whether you can construct embedded triples by means other than the <<>> syntax. If you can, then the uniqueness of embedded triples becomes much more complex.
pchampin: that's one test done
... hope once the core questions are off the way, the rest will follow
... please use the mailing list to discuss as well
<AndyS> Thank you pchampin for chairing.
pchampin: thanks everyone
... thanks the chairs and pchampin
<Olaf> Thx all!
<jerven> Bye
pchampin: talk to you next week
<thomas> bye
bye