- From: Holger Knublauch <holger@topquadrant.com>
- Date: Mon, 19 Oct 2020 18:28:50 +1000
- To: public-rdf-star@w3.org
- Message-ID: <e1dd8845-7ef5-338f-a3e0-4dc3f714b698@topquadrant.com>
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:29:10 UTC