- From: Olaf Hartig <olaf.hartig@liu.se>
- Date: Sat, 19 Dec 2020 16:59:15 +0100
- To: public-rdf-star@w3.org
Hi Thomas,
rdf:value is not useful here. It's intended use is for "describing structured
values" [1] as in the following example (adapted from [1]):
:product35 :weight [
rdf:value 2.4 ;
:unit :kilograms ] .
Notice that the :weight triple in this example has a blank node in its object
position. So, we may use a blank node label, say _:x, and rewrite the example
to the following snippet of Turtle, which is semantically equivalent with the
one above.
:product35 :weight _:x .
_:x rdf:value 2.4 .
_:x :unit :kilograms .
Now it should become clear that :unit is a property of the object of the
:weight triple rather than being a property/annotation of the :weight triple.
Best,
Olaf
[1] https://www.w3.org/TR/rdf-schema/#ch_value
On fredag 18 december 2020 kl. 22:07:13 CET thomas lörtsch wrote:
> > On 18. Dec 2020, at 15:45, Pierre-Antoine Champin
> > <pierre-antoine.champin@ercim.eu> wrote:
> >
> > Thomas,
> >
> > I apologize if I sounded disrespectful and patronizing. That was not at
> > all my intention.
> Apologies accepted, of course, but it was not an apology I was after but a
> discussion. However it seems that a better place to continue this
> discussion might be your PR (https://github.com/w3c/rdf-star/pull/69) and
> I’ll wait until you have incorporated your insights from today’s call.
>
> OTOH maybe this ship has sailed and it’s just me who’s not getting it. At
> least your PR already seems to provide a pretty good intuition of what one
> gets from RDF* and what not. That’s not too bad either (although of course,
> still, a missed opportunity, a deplorable lack of ambition, a shame! ;-)
>
> However, PR aside, I wonder if you have any thoughts about the rdf:value
> idea. When RDF* seemed to be about occurrences the reification approach
> made sense. Now that it clearly is about unique types why not drop all the
> complexity that comes with triples as node types, unasserted assertions etc
> and settle for a simple shortcut to the only mildly involved compositional
> construct that rdf:value represents? It would cover the Property Graph
> usecase pretty well and would stay very true to the simple, compositional
> core and flat world default semantics of RDF.
> > As for the position I was trying to defend, I don't consider it as "my
> > semantics". I sincerely believe that this position is shared by a number
> > of people on the list -- as I am sure you do about the position you are
> > defending.
> That was a shortcut expression and my apologies if that was offending.
>
> Thomas
>
> > best
> >
> > On 18/12/2020 12:16, thomas lörtsch wrote:
> >> Pierre-Antoine,
> >>
> >>
> >> you’re completely missing the point.
> >>
> >>> On 17. Dec 2020, at 14:54, Pierre-Antoine Champin
> >>> <pierre-antoine.champin@ercim.eu> wrote:
> >>>
> >>> Peter,
> >>
> >>> in issue #64 (https://github.com/w3c/rdf-star/issues/64) you wrote:
> >> From this sentence
> >>
> >>>> central examples have fatal flaws if embedded triples are unique
> >>
> >> you only take the first half and then go one to show how the
> >> "regrettable", "unfortunate" examples can be saved to fit your
> >> semantics. You introduce new blank nodes and indirections as if the
> >> authors didn’t know what they are doing and had to be tought basic RDF
> >> modelling skills. You even replace well-established properties by
> >> something you invented ad-hoc with a condiserably different meaning. All
> >> the examples rather obviously understand embedded triples as occurrences
> >> but you consequently treat them as wrongly modelling unique triples.
> >>
> >> Notwithstanding the lack of respect and the patronizing attitude, what
> >> you actually show is that the semantics you propose don’t cover those
> >> usecase. Which is the point that has repeatedly been made. Calling that
> >> a possible misuse of RDF* is, well, an interesting perspective. My fear
> >> is that the world will not bend to your semantics and that the ensuing
> >> muddle will not profit anybody.
> >>
> >> This is not to say that there is no case for unique triples: there is and
> >> not long ago I was overly focused on the annotation usecase that
> >> understands them as occurrences. But both usecases are vaild, widely
> >> used and advertized as to be solved by RDF*. Property graphs can do both
> >> without saying as they have no semantics, but in RDF they have to be
> >> catered for.
> >>
> >> And one last thing: if you insist on only covering the unique triples
> >> reading then you should drop everything reification related. Drop SA
> >> mode and drop the new node type because what you are really doing is
> >> defining semantic sugar for n-ary relations, and those are covered by
> >> rdf:value.>>
> >> :a :b :c {| :d :e |}
> >>
> >> is then syntactic sugar for
> >>
> >> :a :b [
> >> :
> >> rdf:value :c ;
> >>
> >> :d :e
> >>
> >> ]
> >>
> >> That has a clear unique triple semantics, true to the flat world ideal of
> >> RDF. It would spare us a whole lot of trouble and avoid any confusion.
> >> It would not cover the annotation usecase and anything that requires a
> >> bit more complexity than the simplistic base of RDF but since you’re not
> >> planning to actually support that anyways, why not at least be honest
> >> about it!
> >>
> >> Of course it would be a wasted opportunity but since you and Olaf seem to
> >> be so heavily inclined…
> >>
> >>
> >> Thomas
> >>
> >>> As you previously made a list of such flawed examples (thanks for that),
> >>> I'll try to explain why I think that these examples are, though
> >>> imperfect, not fataly flawed.>>>
> >>> On 03/12/2020 00:47, Peter F. Patel-Schneider wrote:
> >>>> I certainly agree with Thomas that examples used throughout the RDF*
> >>>> documents and discussions are ill-supported by the various formal
> >>>> definitions underlying RDF*.
> >>>>
> >>>> We see
> >>>>
> >>>> :bob foaf:name "Bob" .
> >>>>
> >>>> <<:bob foaf:age 23>>
> >>>>
> >>>> dct:creator
> >>>>
> >>>> <http://example.com/crawlers#c1>
> >>>>
> >>>> ;
> >>>>
> >>>> dct:source
> >>>>
> >>>> <http://example.net/listing.html>
> >>>>
> >>>> .
> >>>>
> >>>> in
> >>>> http://ceur-ws.org/Vol-1912/paper12.pdf
> >>>
> >>> Assuming that the <<...>> notation represents unique triples, this
> >>> examples conveys the following information: 1) bob is 23, 2) the fact
> >>> that bob is 23 was asserted by #c1, and 3) the fact that bob is 23 was
> >>> found in listing.html . It is tempting to infer that it was #c1 who
> >>> found this information in that document, but that's not what the
> >>> example is saying. This can be regretted, but that does not make the
> >>> example useless or wrong...
> >>>
> >>> It is not fatally flawed, because IF someone wanted to convey richer
> >>> information such that "#c1 found this triple in that document", this
> >>> would be possible by introducing an additional node, representing the
> >>> occurrence of the triple in the document.
> >>>
> >>> That being said, I agree that the example is imperfect because:
> >>>
> >>> * it can easily to the over-interpretation I mentioned above, and
> >>>
> >>> * the choice of the dct:creator predicate is arguable (nobody "creates"
> >>> a triple, it is an abstract mathematical construct that "exists",
> >>> regardless of who asserts it or not).>>>
> >>>> <<:painting :height 32.1>>
> >>>>
> >>>> :unit :cm;
> >>>> :measurementTechnique :laserScanning;
> >>>> :measuredOn "2020-02-11"^^xsd:date.
> >>>
> >>> Granted, this example is very misleading (or mislead).
":measurementTechique" can hardly be argued to be a property of the triple
(more of the measurement that lead to assert this triple). This should have
looked more like:
> >>> <<:painting :height 32.1>>
> >>>
> >>> :unit :cm;
> >>> :measurement [
> >>> :
> >>> :technique :laserScanning;
> >>> :when "2020-02-11"^^xsd:date
> >>>
> >>> ].
> >>>
> >>> This revised example shows, I believe, that <<...>> denoting unique
> >>> triple is not an obstacle to solving this use case.>>>
> >>>> <<:man :hasSpouse :woman>>
> >>>>
> >>>> :source :TheNationalEnquirer;
> >>>> :webpage
> >>>>
> >>>> <http://nationalenquirer.com/news/2020-02-12>
> >>>> ;
> >>>>
> >>>> :retrieved "2020-02-13"^^xsd:dateTime.
> >>>>
> >>>> in
> >>>> https://graphdb.ontotext.com/documentation/9.2/free/devhub/rdf-sparql-s
> >>>> tar.html>>>
> >>> Again, this example is very misleading, because clearly the intention is
> >>> to convey the information that "this triple was retrieved from the
> >>> given page on a given date" (and not "... from the given page, but also
> >>> on a given date"). If we were to represent two distinct retrieval, we
> >>> would lose the link between source and date.>>>
> >>> However, I still believe it is possible to convey this information using
*unique triples*, either with an intermediate node representing the retrieval:
> >>> <<:man :hasSpouse :woman>> :occurence [
> >>>
> >>> :source :TheNationalEnquirer;
> >>> :webpage
> >>>
> >>> <http://nationalenquirer.com/news/2020-02-12>
> >>> ;
> >>>
> >>> :retrieved "2020-02-13"^^xsd:dateTime
> >>>
> >>> ].
> >>>
> >>> or possibly with deeply nested triples
> >>>
> >>> <<:man :hasSpouse :woman>>
> >>>
> >>> :retrievedFrom
> >>>
> >>> <http://nationalenquirer.com/news/2020-02-12>
> >>>
> >>> {| :on "2020-02-13"^^xsd:dateTime |}.
> >>>
> >>> <http://nationalenquirer.com/news/2020-02-12>
> >>>
> >>> dct:creator :TheNationalEnquirer;
> >>>
> >>>> <<:Bess_Schrader :employedBy :Enterprise_Knowledge . >> :dateAdded
> >>>> "2020-05-22" . <<:Bess_Schrader :employedBy :Enterprise_Knowledge . >>
> >>>> :addedBy :user_bscrader .
> >>>>
> >>>> in
> >>>> https://enterprise-knowledge.com/rdf-what-is-it-and-why-do-i-need-it/
> >>>
> >>> This example is interesting because in the code, the author used two
> >>> different occurences of the <<...>> notation, but in the accompanying
> >>> figure, a single :employedBy arc is annotated by the two properties
> >>> :dateAdded and :addedBy.
> >>>
> >>> I think it demonstrate that the author (and, I would venture to
> >>> extrapolate, many people starting with RDF*) did not really think about
> >>> the type/token distinction, or the subtle problems that may arise when
> >>> they are mixed up. I think the problem is more that one, rather than
> >>> "everyone assumes that embedded triples represent occurrences".>>>
> >>>> <<?c a rdfs:Class>> dct:source ?src ;
> >>>>
> >>>> prov:wasDerivedFrom <<?c a owl:Class>> .
> >>>
> >>> For me, this example is really similar to the first one: it states "T1
> >>> appears in src, and T1 can be derived from T2". Both assertions are
> >>> true independantly of each other, and can be considered true of the
> >>> triples themselves, rather than occurrences thereof.
> >>>
> >>> As in the very first example, the chosen predicate (here,
> >>> prov:wasDerivedFrom) is not the best choice (PROV is about artifacts,
> >>> not abstrac things like triples), and I propose to change it for a more
> >>> neutral triple (:canBeDerivedFrom).>>>
> >>>> :loisLane :believes << :superman :can :fly >>.
> >>>
> >>> I don't see the problem here. Of course, one could argue that [my belief
> >>> that superman can fly] and [lois' belief that superman can fly] are
> >>> different things, but I could just as well argue that Lois and I
> >>> believe *the same thing*. Maybe if the predicate was named
> >>> :believesThat would it be clearer that this example uses the second
> >>> option?>>>
> >>>> in
> >>>> https://w3c.github.io/rdf-star/rdf-star-cg-spec.html
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> What should be concluded from this? Just about the most charitable
> >>>> conclusion is that RDF* is unsuitable for its claimed use.
> >>>
> >>> I don't think that is very charitable ;-), nor really fair. At least
> >>> that's what I tried to show above.
> >>>
> >>> What I conclude, though, is that RDF* is easily misued, and that the CG
> >>> report should include material to help people avoid these caveats. I'll
> >>> make a PR to that effect.>>>
> >>> best
> >>>>
> >>>> So what is RDF* good for? I am concerned about this.
> >>>>
> >>>>
> >>>> peter
Received on Saturday, 19 December 2020 15:59:38 UTC