- From: Pierre-Antoine Champin <pierre-antoine.champin@ercim.eu>
- Date: Mon, 19 Oct 2020 10:54:04 +0200
- To: public-rdf-star@w3.org
- Message-ID: <0ef56e46-1e89-6a2a-53bf-d36aa98a2521@ercim.eu>
Dear all,
Holger, Pavel: I assume that blank nodes are internally skolemized, so
indeed, internally, you only have IRIs and literals. Correct?
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 08:54:13 UTC