Meeting minutes
<TallTed> gb, status?
<gb> TallTed, the delay is 15, issues are on, names are off, full issues are printed 10 at a time; and the repositories are w3c/
<gb> … w3c/
<gb> … concepts w3c/
<gb> … csv-tsv w3c/
discussion about profiles
ora: Topic today is discussion about profiles
… apologies for not getting my email out until yesterday
… anyways, I had some questions in that email
… the fourth of these questions came to my mind only recently:
… what are the implementation ramifications of the choices?
… How much implementation experience do we have in the group?
enrico: I replied to your email with material regarding the first three questions in your email.
… I believe we should have a best practice -- not a profile
… Defining an LPG profile with functionality of rdf:reifies makes is loose
… the option to define simple entailment using pattern matching
… My opinion, using a syntactic condition / restriction, should be good enough.
… Of course, round tripping with LPG is not possible.
ora: sure, no round tripping
… okay, syntactic restriction is good
… what worried me was that people could not build reasoners
enrico: With a syntactic restriction, the reasoners work.
… any entailment over this fragment remains in this fragment.
ora: even better
… Then, my fourth question (implementation-related ramifications)
… Does anyone here implementation experiences with this stuff?
Souri: We have only done prototyping. Still waiting for the finalization of this groups' work.
ora: We have OpenCypher over RDF now (modulo blank nodes).
… The main issues there were more about OpenCypher tooling (parsers etc)
Souri: We have experience with translating relational DB to RDF.
… e.g., with R2RML
… where each primary key ends up as a reifier
… example with 'employed' table
… 'employed' table plays two roles
… one, to contain one row per employee
… two, same row to capture the relationship of the employee to their department
… and the relationship to their supervisor
… That situation was a surprise to me.
… i.e., case where the primary key cannot become the subject but must become a reifier
pchampin: regarding the baseline that we have, it is not very different regarding the abstract syntax
… compared to the CG version of RDF-star
… and there exists implementation experience for that
… This impl.experience can serve as an input for the discussion.
tl: I wrote an email asking what the problem is.
… I was trying to explore what the difficulty would be with the many-to-many option
… I came up with three cases and didn't see a problem with any of them.
… My question then is whether it is really necessary to take away this option.
… You have to look through my examples.
<AndyS> +1 to pchampin on implementation. More impact because of initial text direction.
tl: Do you have an example of data that gave you a problem?
ora: Edge properties.
… We wanted to understand what the RDF-star correspondence for them is.
… Issue when mapping from RDF to LPG in case of many-to-many.
tl: Only problem that I see is if you have a many-to-many annotation where the annotation is for the whole group of triples.
ora: Other question now. What do we think, more generally, about the idea of profiles?
gkellogg: Maybe it is premature to specify this. We don't have enough experience with it.
<tl> examples of many-to-many situations and how they might translate to LPG edges: https://
gkellogg: We may instead have member submissions first.
ora: My understanding of what you say is that we would leave the door open for profiles that might emerge. That makes sense to me.
… Then, people may perhaps even come up with other ideas for possible profiles that make sense.
<tl> maybe write a Note that discusses LPG interoperability
enrico: Generalizing this discussion of profile, we still leave open the question of what the syntax of simple RDF is.
… Do we want to have a distinction based on specific syntactic restriction? e.g., triple terms only in object position of rdf:reifies triples
… In terms of semantics, an additional question is whether we want to add rdf:asserts.
ora: Okay, I got my questions for today answered. We may thus move on to talk about rdf:asserts and the likes
niklasl: Before we move on, I have a question about the Amazon implementation and graph query languages.
… Can one see the edge ID in such languages?
… If not, perhaps you wouldn't see the whole RDF side when querying with Cypher.
ora: We had lots of discussions regarding such RDF views when using Cypher.
… and there might be loss of the projections.
… Round tripping RDF -> 1G -> RDF without loss, same for LPG -> 1G -> LPG. But potential loss for RDF -> 1G -> LPG or vice versa.
… From our experience in the context of OpenCypher over RDF, some developers will never touch SPARQL.
… Still use cases about combining an LPG and an RDF graph.
Souri: What situation did you have where an LPG cannot be translated to RDF 1.1 (using RDF reification)?
ora: Other observation was that none wanted to touch RDF reification.
… (none of the customers)
Souri: Same experience. Customers don't want to touch SPARQL. Customers want edge properties.
… Other reason for picking LPG is the lack of proper path queries in SPARQL.
ora: Limitation of LPG is that there is no schema language.
… related pondering about how to bring RDF-star into ontology language
AndyS: Where are we now regarding the LPG profile? Are you okay to have it outside the core specs?
… Personally, I prefer outside of specs, before we don't have so much experience with all this stuff.
gtw: To the point that we don't have impl.experience regarding this stuff, the same issue holds also about implementations of the many-to-many option.
ora: The same issue existed in the first RDF WG.
AndyS: Experience from SPARQL is that the first version can be more risk-taking.
ora: But that's not how standardizing traditionally works.
fsasaki: To gtw's point, the W3C process requires implementations in the candidate recommendation process step, so there is still an opportunity to gather and document implementation experience and revise the many to many feature.
william_vw: Now to the rdf:asserts topic.
… I had a lot of questions there.
… Tried to get more information on the mailing list.
… Souri, do you have an RDB to RDF mapping? Can you elaborate on it?
Souri: Miss-understood someone else's proposal.
… I tried arguing more on the independence.
… Truth and hypothesis is at a very basic level that may cover a lot of cases.
… in RDF, a triple is a small unit (only three elements), which is different form RDB
… I wanted ID to be integrated into SPO
… Such that it can have a truth value.
… without having to add an extra triple.
… which also avoids extra triple patterns in SPARQL queries.
… To the question of leaving things out of the standard now, I am worried that adding such things later takes years
… in the meantime people will start doing their own thing.
william_vw: So, any meaning becomes application dependant.
… It was unclear to me why you focused specifically on these particular meanings mentioned in your emails.
tl: Very binary consideration whether triple is true or not.
… Asserted or not is essential and belongs into the spec. Everything else can be application specific meanings.
… Annotations syntax is currently mapped to rdf:reifies, which is a mismatch. It should be mapped to rdf:asserts
<Zakim> pchampin, you wanted to point out that we have chosen the "living standard" mode
tl: We are really defining something there, and we are currently doing it in the wrong way.
pchampin: Just to point out that we chose to leave the spec open as a living standard. hence, adding new features would not be as long and tedious as several years.
niklasl: I wrote emails half an hour before the meeting.
… I don't see the problem. My example should show that.
… We might talk about it tomorrow in the SemTF
<Zakim> Tpt, you wanted to comment on writing a note
Tpt: We can just write a Note if we are not confident adding something into the standard.
enrico: We have a SemTF meeting tomorrow. We can talk about ... (?)
… I made the point that we have had infinite discussion. The WG should make a decision.
Tallted: Asking that everything to be voted on will be put on the mailing list in good time, with precise definitions.