Meeting minutes
Final vote on singleton properties and on opaque IRIs
<ktk> regerts- doerthe
enrico: Finalize two points: 1) close discussion on singleton properties, 2) close discussion on opacity
… re. opacity: an IRI should always (i.e., in all contexts) denote the same thing
… re singleton properties: semantics implies either an automatic owl:sameAs or owl:differentFrom
… We should be ready to stop discussing this.
ora: Anybody else have opinions?
<doerthe> @ktk, I am here :)
ora: singleton properties have come up several times the past 20 years. Discussions either don't go anywhere or have been rejected. You would have to modify your modelling to handle those.
… re. Opacity: the point on IRIs is well taken.
… We should to two separate resolutions and move on.
<ora> PROPOSAL: Close discussion on singleton properties
<ktk> +1
<gtw> +1
<gkellogg> +1
<enrico> +1
<niklasl> +1
<doerthe> +1
<AndyS> +1
<ora> +1
<Souri> +1
<eBremer> +1
<thomas> 0
TallTed: To be clear. We're deciding to not do these.
<pfps> +1 but also that we are not doing singleton properties
<Souri> s/no not/to not/
ora: Yes, that's what we mean.
<TallTed> PROPOSAL: We are not specifying singleton properties.
<ora> PROPOSAL: The group will not consider semantics based on singleton properties
<gtw> +1
<gkellogg> +1
<TallTed> +1
<niklasl> +1
<eBremer> +1
<ora> +1
<ktk> +1
<thomas> 0
<enrico> +1
<pfps> +1
<doerthe> +1
<Souri> +1
<AndyS> +1
RESOLUTION: The group will not consider semantics based on singleton properties
thomas: In some ways there is value in the notion of singleton properties, in some ways not.
<ora> PROPOSAL: The group will not consider semantics where IRIs denote different things in different contexts (sometimes called "opaque IRIs")
<gkellogg> +1
<ora> +1
<enrico> +1
<niklasl> +1
<TallTed> +1
<eBremer> +1
<Souri> +1
<gtw> +1
<AndyS> +1
<thomas> +1
<pfps> +1
<ktk> +1
RESOLUTION: The group will not consider semantics where IRIs denote different things in different contexts (sometimes called "opaque IRIs")
LPG problems we want to solve
Final vote on singleton properties and on opaque IRIs 1
<TallTed> z, next item
LPG problems we want to solve 2
ora: Is a statement about a statement an equivalent of an LPG edge? Another question is if many-to-many is a problem for LPG interop.
… That is, a single reifier for multiple triples.
pfps: We should not in any way be constrained by what cannot be done in LPGs.
ora: We (AWS) have seen customer demand for alignment with LPGs.
… If we make it impossible for an implementation no not be compliant with an RDF specification, that is a problem.
… I think that the current baseline proposal could make this possible.
TallTed: I do not understand why that would be so.
… Would Amazon formally object to an RDF 1.2 that is not perfectly aligned with LPGs?
ora: No, that's not what we're saying.
… What we would like to see is the ability to offer an implementation where it is a level of interoperability of LPGs and RDF over the same graph. Or at least a view thereof.
… In that regard, we're hoping that we can implement RDF 1.2 and still hold this interoperability.
pfps: We seem to be going back to the same discussion. Does Amazon not want to change an existing implementation?
ora: No, that is not true.
TallTed: The data models are in some ways similar, but are very different in details. For instance, they are more like singleton properties; which we just decided not to do.
Andys: You said: being able to query across the models. Is it fair to say: if a mapping from LPG to RDF 1.2 is a subset of RDF 1.2, then that would fulfill your needs?
ora: Yes, RDF would be more expressive than LPGs.
AndyS: The difficult part: Can you draw out the requirements for that to happen?
ora: It would satisfy us if an implementation of this subset would be considered a compliant implementation of RDF 1.2.
AndyS: It's how you can use it. To test that out, could it be done in RDF 1.2. ??
<Souri> Are we looking for a profile that only supports "many-to-one"?
ora: If we provided an implementation that only supported this subset, could we claim to have an RDF 1.2 implementation?
… Could we have a profile of RDF 1.2 that does not mean full support?
<Souri> RDF1.2-Full and RDF1.2-LPG?
thomas: I don't know what this means. A proposal for such a profile would be much easier to discuss. There are many things in RDF that LPGs cannot support.
ora: I think this profile has been articulated in the past.
… we might not have to change anything at this point.
<enrico> https://
enrico: A proposal made some time ago, discussed a lot.
… As this stands, we can map the LPG model to RDF, and that would round-triple. There are things for the mapping still to discuss (the assertion, etc.), but not for this issue.
… We should not define a canonical LPG profile; we could show how it is possible.
<Zakim> gtw, you wanted to add that AWS interest is also in the other direction: we want some subset of RDF 1.2 to also be sensibly queryable in LPG languages
enrico: The details about what to see is orthogonal to this.
gtw: The interest of AWS is not just the mapping, we are interested in both directions of the mapping, for query languages.
… We want to see RDF 1.2 data queryable from LPGs.
<Zakim> AndyS, you wanted to suggest a task force, with deadline(!), to produce a mapping from LPG (as in GQL) to RDF with query considered.
AndyS: Does that mean any RDF data, or RDF data conforming to a profile?
gtw: Any RDF with the caveat that things in RDF-star like the many-to-many probably can't be handled like that.
<Souri> RDF1.2-LPG = RDF1.2-Full - "many-to-many" .
AndyS: a concrete example would help to see the problem.
ora: The concrete problem is that we view a statement about a statement as an edge property in LPGs. A single reifier of multiple statements does not seem to be mappable to that.
<TallTed> Might SPARQL-in-GQL be an option to consider? something like SPARQL-in-SQL (a/k/a SPASQL) -- https://
AndyS: The N-ary-relationship-like effects is not possible?
… Having one reifier for many triples is to have an N-ary relationship, to model the event of something with multiple relationships.
ora: LPGs aside; in RDF, a statement about a statement, where the object is a node in the graph, is already an N-ary relationship?
… We don't need to reify multiple triples for that.
gkellogg: A way to restate it might be: if we have a LPG profile with many-to-one, does that hold up under any entailment?
<Souri> :id | :john :weds :mary . :id :venue :church5 . This is a 3-ary relationship.
gkellogg: A triple term might entail more triples. Presumably the same reifier targets both.
thomas: Two options in the X-to-many: why not add all the annotations to each of those statments? Or, those together describe something, an event.
… It wouldn't be perfect; probably not catastrophic.
ora: If we're ingesting full RDF 1.2 data and transform it on the fly to the many-to-one?
thomas: it wouldn't be a problem apart from losing the togetherness.
TallTed: Is this more a problem for querying? A question for SPARQL 1.2? Like for SPARQL-in-GQL...?
ora: That's interesting.
<enrico> << :w2 | :liz :married :richard >> a :Marriage ; :starts 1975 .
<enrico> << :w2 | :richard :married-in :las-vegas >> :best-man :jim-benton .
enrico: I don't think this can be avoided.
<enrico> << :w2 | :liz :married-on 1975 >> :location :las-vegas .
enrico: This is for data integration, written in different ways - a major case for RDF.
.\.\. Same reifier, same properties; different properties.
<gkellogg> New syntax would be << :liz :married :richard ~ :w2 >> a :Marriage ; :starts 1975 .
<pfps> Multiple triples with one reifier, potentially among other things, permits provenance information to be attached to multiple triples without duplicating the provenance triples. This was discussed a while ago in the working group and the savings were considered to be worthwhile. For example,
<pfps> :r rdf:reifies << :alice :age 53 >> .
<pfps> :r rdf:reifies << :bob :age 54 >> .
<pfps> ... ... ... ... ...
<pfps> :r rdf:reifies << :zeke :age 22 >> .
<pfps> :r :source :census .
<pfps> :r :retrieved "20 jun 2024"^^xsd:date .
<pfps> :r ....
<pfps> This is a savings of at least two triples for each of the annotated triples.
pfps: We have had a long discussion about cases for a single reifier. Such as for provenance.
thomas: In Enricos examples, you can have separate edges for w2, and annotate each of them with the same properties.
ora: From my understanding, given the current baseline proposal, we would be happy if we could have a profile where we do not support many-to-many.
… we're not really objecting to anything.
<thomas> that would be ok with me
ora: The WG would be free of this trouble. We would just like to see an LPG-friendly profile for this.
… Is there an argument for why having that would be harmful?
… We would have a hard time supporting this otherwise.
pfps: I do not like the idea of claiming LPG-friendliness. It really is about implementation.
<AndyS> We will have to relax something. It need a lot of care to specify and frame that profile but it is one interesting way.
pfps: Implementation concerns are relevant, but please frame it like that if so.
<enrico> << :w2 | :liz :married :richard >> a :Marriage ; :starts 1975 .
<enrico> << :w2 | :richard :married-in :las-vegas >> :best-man :jim-benton .
<enrico> :liz owl:sameAs :richard .
<enrico> :married owl:sameAs :married-in .
enrico: If this example is functional, this entailment is necessary.
<enrico> :richard owl:sameAs :las-vegas.
ora: In a profile, that would not be accepted.
<doerthe> note that the wording was different (but let's not go there ;) )
<Zakim> gtw, you wanted to say I think an *official* profile would be difficult to standardize for the reason gkellogg mentioned -- entailment would immediately pull you out of the profile. So it's a profile that precludes higher levels of the semweb stack.
gtw: We think of a syntactic constraint on the loader.
TallTed: Is not doing a profile bad for RDF in general?
<Souri> Can we say (non-normative): Some implementations may enforce a unique(reifier) constraint in an RDF graph?
ora: It would be good for AWS to implement RDF 1.2. We really want RDF to have as wide a support as possible.
TallTed: it's a strategic decision for a vendor, customers have options.
<AndyS> We could position this profile as a restriction pending future work. This WG does not the time and charter to fully do LPG/RDF.
ora: As Gregory said, the profile is syntactic in nature, is interesting.
doerthe: Connecting to what Thomas said: if we have this profile, if you have two triple terms that denote the same thing, would you just pick one and be happy with that?
ora: I cannot give a definitive answer on that.
<TallTed> "One Graph" must necessarily have various sub-graphs, which have their own definitions, limitations, query languages, etc. Sub-graphs in LPG, and in RDF 1.1, and in RDF 1.2, and in SQL, etc.
doerthe: My main concern is that you could do the restriction, but there are problems with syntactic restrictions for something with semantics, but if we can work around that...
<gtw> we're over time
thomas: I made a mapping to RDF 1.1; RDF standard reification is semantic, but it is still restricted to one triple/relationship.
… maybe add edge identifiers
enrico: In my document it is explicitly defined how to map back to LPGs.
… it is a syntactic fragment. It is not semantic, not functional.
<ktk> rs/We should make two/We should make two/