Meeting minutes
Use Cases 1
ora: How do we want to proceed with use case discussion?
pfps: Some people were going to add use cases, but none have.
ora: We should issue some kind of "last call" to WG
ora: are people OK with a last call, now?
pfps: will draft a message to that effect
ktk: reminder to ora & gtw that they were going to add a use case
ora: does enrico have a use case to add?
enrico: there's a project about attaching metadata to publications, prodding them to submit use case ASAP
TallTed: I'm late with writing mine up. Will prioritize.
ora: Does anyone have anything specific to discuss, or should we just review the use cases as they are?
tl: I don't understand how to discuss use cases without having settled on how to describe "unasserted assertions" or "occurences" or ...
pfps: We have had precise definitions of lots of things, which shouldn't be discussed unless there's something being raised as wrong with those definitions.
tl: My impression was that we wanted to be able to discuss/describe triples without adding them to the graph. It's not clear how to achieve this.
… Occurence was presented as how to do this. Occurrence isn't added to graph.
ora: You want to be able to say, "I'm annotating this triple on the condition that it's not asserted"?
tl: roughly, yes
… Turtle-star offers a syntax that provides an intuitive visualization of annotating triples that are asserted, and of annotating triples that are *not* asserted, but other syntaxes don't make these clear
… "Special case" of describing statements without asserting them is problematic.
… Suggest two reifying properties, one which asserts and one which does not
AndyS: If we want to get back to use cases, there are 2 that seem immediately interesting. One is about deltas and diffs, which has trouble because of bnodes. The other is about LPGs
ora: Remembers a "patch" proposal
AndyS: There's an RDF-like syntax, but it's not RDF
gkellogg: Trying not to derail use cases, we need to be clear in our nomenclature, e.g., triple_term instead of occurrence.
… graphs are immutable. We don't add things to graphs. We derive or construct or retrieve them, but once that is done, they're concrete.
<AndyS> FYI: https://
gkellogg: It's always been possible to construct a set of triples that include contradictions.
tl: Immutable is a theoretical position. We have UDPATEs and DELETEs, etc.
… Gave examples of things, and then discussed how they are misled
… Still trying to understand what enrico says about LPG use case from gtw, and the use case itself
<gkellogg> From RDF Concepts: "The RDF data model is atemporal: RDF graphs are static snapshots of information."
TallTed: I'm concerned about that assertion that graphs are immutable
… the only way this can be true, in my experience, is by timestamping everything.
… Yes, we don't have a formal semantics of named graphs, but many people are using them, and they change all the time for various reasons.
… A name usually is not usually used with a timestamp.
<gkellogg> "We informally use the term RDF source to refer to a persistent yet mutable source or container of RDF graphs. "
<niklasl> +1 to gkellogg
pfps: The fundamental semantics of RDF say that graphs don't change.
… Nonetheless, it is useful to be able to say `"this graph" is just like "this graph" except for the following differences...`
… It's useful to distinguish between "this is what happens in practice" vs "this is what RDF says"
gkellogg: There are differences between "RDF graphs" which are immutable and "RDF sources" which are mutable and may deliver RDF graphs that differ over time
AndyS: When you publish (endorse) a graph, it's the whole graph that you're endorsing; you can't publish a partial graph.
… The only way mutability is available is by moving from one graph to another.
<niklasl> +1 to AndyS
ora: Change has been problematic since early on
tl: i'm struggling with terminology confusions, and abstract and/or confusing answers to questions
<niklasl> << <s> :p <o> >> a :Theory . <s> :p <o> {| a :Truth |} .
<niklasl> <s> :p <o> . _e1 a :Theory . _e1 rdf:reifies <<( <s> :p <o> )>> . _e2 a :Truth . _e2 rdf:reifies <<( <s> :p <o> )>> .
<niklasl> <s> :p <o> {| a :Theory |}, <o> {| a :Truth |} .
niklasl: [[scribe fails to capture speech 1]]
pfps: I would like to point out that people who submit things to the WG have on their shoulders the responsibility of ensuring that their submission can be understood by the WG
ktk: notes that tl departed the meeting while niklasl was speaking
pfps: I've spent a lot of time reading submissions, and trying to rephrase them such that the WG will understand, with unclear results
ora: it's true that communication of complex topics is sometimes hard. We should still strive toward that goal.
gtw: There are various things that we do with LPGs that may not be compatible with RDF
enrico: I spent most of the past week on these things. There is a formal definition, part of a formal document, from which we should start.
… It's not clear whether the LPG use cases are achievable with RDF, because those use cases are incomplete or not yet submitted
… It seems to me there is a lack of understanding of formal semantics.
… I have tried to make everybody happy with the semantics I have constructed, but it seems that my constructions aren't being understood.
<niklasl> I also fail to see what is not possible (I see more things possible in RDF that are hard to map to LPGs without very idiomatic conventions).
ora: It is difficult to separate people from syntax, even when we are explicitly discussing semantics
AndyS: It's frustrating to reply in detail to various things, and receive "I don't like that" in return
gtw: Many of our use cases seem to be out of scope for this WG, as they're more about interop than about data-at-rest
ora: Our understanding of LPGs is basically what's in the GQL spec.
… We can express things in RDF that cannot be expressed in GQL, and that seems to be their problem.
… It seems that we *can* express in RDF everything that can be expressed in GQL
… We have this baseline model, now. Thought is to review each use case and see whether it can be handled by the baseline.
… We also have some terminology which seemed to be stable, but there seems not to be 100% agreement on that
… Once we have convinced ourselves that the use cases can all be handled by our model, then we look to syntax, and then we claim victory.
… Next order of business seems to be to find which if any use cases are problematic with the current model
<ktk> ok andy was the host somehow
<ora> Whoa I was kicked out of the meeting
(pchampin left, making AndyS zoom host; AndyS left, ending zoom session; all rejoined)
enrico: LPG singleton properties appear to be problematic, but looked to as one solution to reification
… In the past, many people were concerned about `married` vs `married1`. We could formally rule this out?
ora: I also thought we ruled that out.
niklasl: Singleton properties have the same drawbacks as are found in LPGs. Better not to formally bring them into RDF. Might be good to write FAQ with such things as "we didn't do x because y".
ora: Such an FAQ would be good.
<Zakim> niklasl, you wanted to ask about if I should write a UC for my OWL example...
ora: we're about at time. any last words, disagreements with way forward being "review use cases against current baseline"?
<ora> PROPOSAL: The Way Forward: 1) Scrutinize use cases wrt. baseline model, if no problems found, 2) Work through syntax details, and 3) Declare victory.
<ora> +1
<gkellogg> +1
<niklasl> +1
<eBremer> +1
<ktk> +1
<enrico> +1
<TallTed> +1
<gtw> +1
<Souri> +1
RESOLUTION: The Way Forward: 1) Scrutinize use cases wrt. baseline model, if no problems found, 2) Work through syntax details, and 3) Declare victory.
enrico: tomorrow, we will have the Semantics TF meeting