Meeting minutes
Discuss if a single id can reify more than one triple
ora: The focus of today is continue the discussions on reification : many-to-one, many-to-many.
… AWS Neptune team discussions, not telling RDF-star WG what to do
… Neptune focus on interoperability between LPG and RDF data.
… can't understand the extended scenario helps given customer discussions.
<pfps> sorry, mike problems
enrico: what is the danger of the extended case
… can it be that advice is to use many-to-one?
… what is the damage of allowing many-to-many?
ora: your (Enricos) case is allow it and advise on its usage.
ora: hard for vendors of triplestores -- not a complete implementation
… for LPG, hard to explain that a property covers "multiple edges"
enrico: profiles would be an approach but we end up with too many profiles
ora: well-formedness is like lists or classic reification case today
tl: two things: Q1: how is many-to-many not possible in LPG?
ora: we didn't find it intuitive in our group.
<pchampin> intuitive is by definition different for different people
tl: annotation syntax is optimized for the many-to-one case
<niklasl> +1 to pchampin re. intutition
ora: not an engineering question - it is the intuitive understanding
souri: interoperability of LPG/RDF1.2 -- since LPG have edge properties with only values
… in RDF 1.2 is general - - edge on edge
<pchampin> +1 to what Souri says
souri: needs to be considered when converting to LPG
… we do not want to RDF 1.2 because of an LPG restriction so consider N-to-1 and N-to-N
<pchampin> and that does not prevent us from providing guidelines for "reading" (different subsets of) RDG 1.2 as LPG
TallTed: The depth of your (Ora) feeling suggests you want the restriction.
… N-to-1 breaks RDF principles in a new way.
ora: this is about well-formedness
tallted: that's your right
… one reifier - multi terms is the next logical step
<pfps> Well-formedness was introduced, I think, to get around a problem with merging graphs, nothing more
AndyS: It's not quite so simple to discuss the differences between systems, we have something called the "Semantic Way".
… If you make restrictions you can impede how different systems interact.
<enrico> << :w1 | :liz :married :richard >> :location :las-vegas .
enrico: technical: in the LPG standard there are undirected edges
<enrico> << :w1 | :richard :married :liz >> :date 1966 .
enrico: this means we need N-to-M
… my other argument is why restrict the well-formedness fragment to "to-one" . We need many well-formed.
… 3rd argument: open world means two URIs can denote the same resource hence n-ary case [scribe: i.e merge]
<enrico> :e rdf:reifies <<( :s1 :p1 :o1 )>> .
<enrico> :e rdf:reifies <<( :s2 :p2 :o2 )>> .
<enrico> ASK WHERE { _:x rdf:reifies <<( :s1 _:y :o2 )>> } ==> TRUE
<enrico> ex:Edge a owl:Class ;
<enrico> rdfs:subClass [ a owl:Restriction;
<enrico> owl:onProperty rdf:reifies ;
<enrico> owl:cardinality 1 ] .
enrico: remove first 3 triples at "a ex:Edge"
enrico: rdf:reifies is not functional in RDF.
… this should be covered in the best practices
fsasaki: I undertand the AWS Neptune feedback was user based. Similar in SAP.
… in LPG framing, easier to explain currently.
… so this is an opportunity for RDF
… the price is less features - clarity of one case over fully generality
… user groups are AI users
<doerthe> only way out here would be referential opacity (just saying, I really do not want to get back to that discussion ;) )
gkellogg: well-formedness well discussed
… none defined by RDF vocabulary - "semantic extensions may impose limits"
<pchampin> i like the "less features can mean more adoption" approach
gkellogg: we could have examples with only allowing literals via annotations
… many-to-one does not remove the UCs - suggests using a container
pchampin: With tallted about say anything about anything - not seeing our choice as "illegal"
… rdf terms same-term, same value example -- 042 and 42
… across various stores
… keep RDF open and better at expressing implementation choices
pfps: I agree with the "many" people.
<tl> +1 to pchampin
pfps: restricting RDF does not work for me. May be other reasons. I haven't heard them.
ora: Worked with RDF for a long term - found when LPG emerged it was more work
… so why do people choose LPG? Several reasons - one is the model is easier to understand
… struggle to keep RDF relevant in the industry
<pfps> I am again puzzled as to why RDF should be limited just because LPGs are becoming more popular.
ora: we see align as a way to keep RDF relevant
… focus on a solution causes more adoption
<pfps> The argument that RDF should be limited to what is in LPQ sounds like "we have to destroy RDF in order to save it"
<fsasaki> https://
fsasaki: not AWS vs group. SAP has the same experience in the AI area
… disagree about profiles. e.g. xHTML. Limited uptake.
tl: OWL profiles work quite well. Main complexity in RDF comes from blank nodes.
… because open world which is a key feature.
… easier to work/model in a known domain
… profiles done right would be a good idea
<pfps> The trouble with the strict division into edges and attributes in LPG is that you can't then, for example, say where Dick and Liz were married by putting an attribute on a marriage edge. Well, you can, and I've seen it done, by using "strings for things", which is a very bad idea.
enrico: to be constructive: (1) well-formedness for many-to-one (2) several profiles (not a good choice IMO) - considerable work (3) have a best practices section.
<pfps> I'm also confused as to just what the status of well-formedness is going to be. Even if the WG says that well-formedness includes many-to-one reifiers, systems should support the many-to-many case.
enrico: keep many-to-many and in the well formed explanation has an interpretation.
… BP choice -- reificiations always have a meaning
<niklasl> +1 (explain, using good, intuitive real-world(ish) examples, different kinds of reification)
tallted: LPGs appeal as fewer rules.
… make choices and may have consequences later
<tl> I would be totally okay with best practices favoring many-to-one edge annotations, and, as I said, the annotation syntax favors them already
<Kurt> LPGs (specifically Neo4J) is also is an abstraction layer on top of a core model - RDF is closer to "machine language" to most people.
<Souri> Can we create an "LPG profile of RDF1.2"? This profile would restrict RDF1.2 in every way needed for keeping it limited to what LPG can support.
<niklasl> Yes (to tl). And to Souri, we can at least have an LPG best practises section (also feeding from what Ted on "if you hit a limit, migrate" + [my addition] "to RDF" ;) ).
<pfps> SPARQL (also SQL) is complex indeed. But I find the hardest to understand complexity is where the bottom-up execution model is violated.
<tl> +1 to an "LPG profile of RDF1.2"
pchampin: about profiles. They such things already (not called "profile").
… do not believe well-formedness is being used the same way by each of us.
<TallTed> in my experience, SPARQL's "bottom up" is too often heard/read as "from the bottom line of the written query to the top ilne" instead of "from the deepest inner sub query, to the highest outer super query"
<TallTed> hence, my calling it "inside-out"
ora: Like the idea of best practices.
<enrico> Answer to Pierre-Antoine: this is the formal definition of well formedness discussed and agreed upon so far: https://
ora: how is that going to work if imples exlude non-best-practice
adrian: in last 10 years, we restrict ourselves for an application by emphasises open-world / the long term.
… hope we don't break open world .. need to restrict complexity because it confuses people.
fsasaki: any consumer can take any producer data, that feature of RDF may be harmed if one data producer uses profile 1 and the other profile 2 etc..
<pfps> There is a bit in 1984 that I think is relevant here: Two ministries are feuding, with the metric being how much floor space they have relative to the other. In the meantime, a third ministry is increasing its floor space at both their expenses.
Kurt: LPGs encodes complexity into bundles
… then work with bundles
… RDF is a substrate language.
… abstraction layers are what users are attracted to.
SemTF tomorrow