W3C home > Mailing lists > Public > public-rdf-star@w3.org > October 2020

Re: weakness of embedded triples

From: Holger Knublauch <holger@topquadrant.com>
Date: Tue, 20 Oct 2020 08:23:59 +1000
To: public-rdf-star@w3.org
Message-ID: <ebcfca72-fccf-7d9f-290b-47374ca25cf8@topquadrant.com>

On 10/19/2020 6:54 PM, Pierre-Antoine Champin wrote:
>
> Dear all,
>
> Holger, Pavel: I assume that blank nodes are internally skolemized, so 
> indeed, internally, you only have IRIs and literals. Correct?
>
Using Jena API and its (TDB) databases, bnodes have a persistent 
internal ID, so they almost behave like URIs.

Holger


> On 19/10/2020 10:28, Holger Knublauch wrote:
>>
>> Similar situation here at TopQuadrant, see
>>
>> http://datashapes.org/reification.html#uriReification
>>
>> Holger
>>
>>
>> On 10/19/2020 6:24 PM, Pavel Klinov wrote:
>>> This is roughly how Stardog supports RDF* and so far we find it 
>>> sufficient in the enterprise context. It's pretty easily 
>>> understood by users familiar with edge properties in the property 
>>> graph data model, which is one of the most important factors for us.
>>>
>>> Cheers,
>>> Pavel
>>>
>>> On Sat, Oct 17, 2020 at 9:54 PM Martynas Jusevičius 
>>> <martynas@atomgraph.com <mailto:martynas@atomgraph.com>> wrote:
>>>
>>>     Does RDF* need new semantics at all? Couldn't it be a syntax-level
>>>     convention for unique triple IDs?
>>>
>>>     E.g. <<s>, <p>, <o>> being syntactic sugar for
>>>     uri(concat("urn:rdf:id:", hash(str(<s>)), hash(str(<p>)),
>>>     hash(str(<p>)))).
>>>
>>>     For example, the triple
>>>
>>>     <<https://www.w3.org/People/Berners-Lee/card>
>>>     <http://xmlns.com/foaf/0.1/primaryTopic>
>>>     <https://www.w3.org/People/Berners-Lee/card#i>>
>>>
>>>     gives
>>>
>>>     URI(CONCAT("urn:rdf:id:",
>>>     SHA1(STR(<https://www.w3.org/People/Berners-Lee/card>)),
>>>     SHA1(STR(<http://xmlns.com/foaf/0.1/primaryTopic>)),
>>>     SHA1(STR(<https://www.w3.org/People/Berners-Lee/card#i>))))
>>>
>>>     gives
>>>
>>>     <urn:rdf:id:63874e34ff5f326e67e888f6818f72d5033ecb343cadd8c2120281d72cefce4481485c937b6a95a656beaa67c13db29f3d7be801328b7c9125976c5f>
>>>
>>>     which essentially would become the "5th element", in addition to
>>>     quads.
>>>
>>>     On Thu, Oct 15, 2020 at 1:38 PM Pierre-Antoine Champin
>>>     <pierre-antoine.champin@ercim.eu
>>>     <mailto:pierre-antoine.champin@ercim.eu>> wrote:
>>>     >
>>>     >
>>>     > On 14/10/2020 23:13, Peter F. Patel-Schneider wrote:
>>>     >
>>>     > Let's make the height example even more stark.
>>>     >
>>>     >
>>>     > :loisLane :believes << :clarkKent :height "6.0"^^xsd:decimal >> .
>>>     >
>>>     >
>>>     > does not imply
>>>     >
>>>     >
>>>     > :loisLane :believes << :clarkKent :height "6.00"^^xsd:decimal >> .
>>>     >
>>>     >
>>>     > I would hope that any Tom, Dick, and Lois can realize that
>>>     these two literals
>>>     > are the same.
>>>     >
>>>     > I see your point, but this is really a matter of deciding
>>>     where you put the boundary...
>>>     >
>>>     > So I would still prefer to be radical here and consider any
>>>     lexical difference as potentially significant.
>>>     >
>>>     > If you want to stick to literals that have to be supported in RDF
>>>     >
>>>     >
>>>     > :loisLane :believes << :clarkKent :name "Clark"@en-US >> .
>>>     >
>>>     >
>>>     > does not imply
>>>     >
>>>     >
>>>     > :loisLane :believes << :clarkKent :name "Clark"@en-us >> .
>>>     >
>>>     > Are "Clark"@en-US and "Clark"@en-us really different literals,
>>>     for the abstract syntax??
>>>     >
>>>     > I would have thought they are the same (and so the implication
>>>     above would hold).
>>>     >
>>>     > Reading the spec again, I realize that things are not so
>>>     clear: "Lexical representations of language tags MAY be
>>>     converted to lower case", and then Literal term equality
>>>     requires that language tags "compare equal, character by
>>>     character". So these 2 literals MAY be considered equal, and the
>>>     implication MAY hold... :-/ Add to this that BCP47 explicitly
>>>     state that language tags are case insensitive... I'd say that we
>>>     are in gray area here.
>>>     >
>>>     >
>>>     >
>>>     > peter
>>>     >
>>>     >
>>>     >
>>>     > On 10/14/20 4:45 PM, Doerthe Arndt wrote:
>>>     >
>>>     > Dear Peter,
>>>     >
>>>     > you are right with both observations. The question is whether
>>>     we want that
>>>     > behavior or not.
>>>     >
>>>     > In https://w3c.github.io/rdf-star/ there is a section on
>>>     referential opacity.
>>>     > The main claim there is that triples are referentially opaque.
>>>     >
>>>     >
>>>     > But embedded triples are much weaker than just being
>>>     referntially opaque.  To
>>>     > see this consider the following RDF* graph under the RDF*
>>>     version of RDF
>>>     > entailment recognizing xsd:decimal and xsd:integer.
>>>     >
>>>     > :loisLane :believes << :clarkKent :height "6"^^xsd:decimal >> .
>>>     >
>>>     > In this semantics "6"^^xsd:decimal means the same as
>>>     "6"^^xsd:integer so one
>>>     > would expect that
>>>     >
>>>     > :loisLane :believes << :clarkKent :height "6"^^xsd:integer >> .
>>>     >
>>>     > is RDF*-entailed.
>>>     >
>>>     > But it is not.  There are two reasons for this.
>>>     >
>>>     > First, there is no requirement that satisfying interpretations
>>>     for the first
>>>     > graph map < :clarkKent :height "6"^^xsd:integer > to anything
>>>     and if a
>>>     > satisfying interpretation does map the triple there is no
>>>     requirement that its
>>>     > ITEXT mapping gives the triple its correct meaning. (The value
>>>     of ITEXT for
>>>     > the triple could have the real number pi as its third element.)
>>>     >
>>>     > Second, "6"^^xsd:integer is a different node from
>>>     "6"^^xsd:decimal. So even if
>>>     > the intepretation treats the second embedded triple nicely,
>>>     and thus gives it
>>>     > the same meaning as the first embedded triple, they are still
>>>     two different
>>>     > triples and :loisLane can believe one but not the other.  So
>>>     very little of
>>>     > the semantics of RDF gets into embedded triples.
>>>     >
>>>     > We wanted different that different representations are treated
>>>     differently
>>>     > if they have the same meaning. The reason for that is that we
>>>     expected that
>>>     > RDF* would also be used to make statements about triples as
>>>     they were
>>>     > stated, for example to be able to explain the reasoning
>>>     performed on the
>>>     > triples but also for simple provenance. In these cases there
>>>     should be a
>>>     > difference between
>>>     >
>>>     > :loisLane :believes << :clarkKent :height "6"^^xsd:decimal >> .
>>>     >
>>>     > and
>>>     >
>>>     > :loisLane :believes << :clarkKent :height "6"^^xsd:integer >>
>>>     >
>>>     > since we still talk about different representations.
>>>     >
>>>     > Each triple is, in effect, its own context.  So, in an RDFS
>>>     version of RDF*,
>>>     > even if :loisLane believes several triples that should imply
>>>     another, they
>>>     > generally don't.  For example:
>>>     >
>>>     > :loisLane :believes << :clarkKent rdf:type :man >> .
>>>     > :loisLane :believes << :man rdfs:subClassOf :human >> .
>>>     >
>>>     > Does not imply
>>>     >
>>>     > :loisLane :believes << :clarkKent rdf:type :human >> .
>>>     >
>>>     >
>>>     >
>>>     > So embedded triples are incredibly weak in RDF*.  Making them
>>>     useful will
>>>     > likely require quite a bit of work.
>>>     >
>>>     > Here, "useful" depends again on your intended use. We wanted
>>>     to have a
>>>     > rather weak semantics which allows users with more complex use
>>>     cases to add
>>>     > their semantics. It is easier to make the semantics more
>>>     complex by adding
>>>     > extensions than to ignore certain parts. I for example
>>>     remember that Jos De
>>>     > Roo announced some time ago that his EYE reasoner supports
>>>     rules on RDF*. Of
>>>     > course that alone would not allow you to cover all cases, but
>>>     it could be
>>>     > very helpful in practice.
>>>     >
>>>     >
>>>     >
>>>     >
>>>     > On the other hand, there are some unusual inferences that can
>>>     be made in
>>>     > RDF*.  In an RDF* version of RDFS++ it is possible to state
>>>     that two triples
>>>     > are the same.   The graph
>>>     >
>>>     > :loisLane :believes << :superman :can :fly >>.
>>>     > << :superman :can :fly >> owl:sameAs << :clarkKent :can :fly >> .
>>>     >
>>>     > is consistent here and implies
>>>     >
>>>     > :superman owl:sameAs :clarkKent .
>>>     > :loisLane :believes << :clarkKent :can :fly >>.
>>>     >
>>>     > This last case is an interesting one. We indeed wanted the triple
>>>     >
>>>     > :loisLane :believes << :clarkKent :can :fly >>.
>>>     >
>>>     > to be a consequence of your statements. The question is whether
>>>     >
>>>     > :superman owl:sameAs :clarkKent .
>>>     >
>>>     > should follow (it does indeed follow, just as you describe).
>>>     We made the
>>>     > semantics of embedded triples the way it is to be able to deal
>>>     with blank
>>>     > notes. Here, I can't give a concrete answer whether (at least
>>>     to my
>>>     > understanding) it should be that way. I will think about it
>>>     (and read
>>>     > Pierre-Antoine's thoughts in the mean time, which just arrived
>>>     as well) and
>>>     > come back to you.
>>>     >
>>>     > Kind regards,
>>>     > Doerthe
>>>     >
>>>     >
>>>     >
>>>
Received on Monday, 19 October 2020 22:24:19 UTC

This archive was generated by hypermail 2.4.0 : Monday, 19 October 2020 22:24:20 UTC