- From: Olaf Hartig <olaf.hartig@liu.se>
- Date: Thu, 03 Sep 2020 14:37:32 +0200
- To: public-rdf-star@w3.org
- Cc: Blake Regalia <blake.regalia@gmail.com>
Hi Blake, On onsdag 2 september 2020 kl. 20:24:11 CEST Blake Regalia wrote: > [...] > I would expect the annotations to exhibit locality as they 'scope' the > assertions; consider the typical use case for a linked data: > > # no annotations > > :bob :name "Bob" . > > # assertions made by alice > <| :bob a :Person ; > :age 23 ; > :gender :male |> > :author :alice ; > :submitted "2020-06-01" ; > . > > Is much clearer and concise to me. In my opinion that's not a good approach. Instead of individual annotations of each of the three triples about :bob, it looks more like annotations of the group of all three triples together. Olaf > I have not yet come across cases where a reified triple is used in the > > > object position. > > We are currently experimenting with an approach where changes are recorded > as such: > > r:47e1cf2 a :Commit ; > > :delete <<:bob :age 23>> ; > :add <<:bob :age 24>>, <<:bob :gender :male>> . > > - Blake Regalia > > > On Wed, Sep 2, 2020 at 7:05 PM Holger Knublauch <holger@topquadrant.com> > > wrote: > > On 3/09/2020 08:49, Blake Regalia wrote: > > > > Reading thru quickly here, but I think the suggested `{| ... |}` syntax > > for the proposed annotation sugar is simply on the wrong part of the > > triple. Instead, the new production should identify the triple which is > > being both asserted and annotated. This gets around the subject/object > > issue Olaf pointed out and is complementary to `<< ... >>` satisfy for PG > > mode while having another for SA: > > > > Using `<|` here simply to distinguish from previous: > > > > <| :bob :age 23 |> :certainty 0.9 . > > ## equivalent to: ## > > > > :bob :age 23. > > > > <<:bob :age 23>> :certainty 0.9 . > > > > :alice :disbelieves <| :bob :age 23 |> . > > > > ## equivalent to: ## > > > > :bob :age 23 . > > :alice :disbelieves <<:bob :age 23>> . > > > > This design would unfortunately break how people currently work with > > Turtle. People would need to use a different syntax for the asserted > > triples that carry reifications than for asserted triples that don't carry > > reifications. > > > > In particular, consider the ; case at the subject: > > :bob > > : > > a :Person ; > > > > :age 23 ; {| :author :alice; :certainty 0.9 |} ; > > :gender :male ; {| :author :alice |} ; > > > > . > > > > The syntax above looks reasonably natural and much less disruptive than > > surrounding the asserted triples, esp how in cases like ; and , lists? > > Furthermore this syntax works well if a triple has multiple annotations. > > > > But you are right that from a symmetry POV your syntax would be better. I > > have not yet come across cases where a reified triple is used in the > > object > > position. Your example above could semantically be rewritten as > > > > :bob :age 23 {| :disbelievedBy :alice |} > > > > Sometimes allowing less flexibility is actually better, as long as the > > majority of cases is covered. My current gut feeling tells me that having > > good support for subjects will be enough, and all other cases can fall > > back > > to the generic, original << >> syntax. > > > > Holger > > > > - Blake Regalia > > > > On Wed, Sep 2, 2020 at 7:48 AM Patrick J Hayes <phayes@ihmc.us> wrote: > >> On Sep 2, 2020, at 2:44 AM, Holger Knublauch <holger@topquadrant.com> > >> wrote: > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> On 2/09/2020 15:41, Patrick J Hayes > >> > >> wrote: > >> > >> > >> > >> > >> > >> > >> > >> > >> Jeen and Holger, greetings. > >> > >> > >> > >> > >> > >> > >> It seems to me that there is a more basic issue > >> > >> here. However it is written, if this maps to an RDF graph > >> > >> containing the triple > >> > >> :bob :age 23 . > >> > >> then that triple is /asserted to be true/, and > >> > >> that assertion of truth is independent of any other triples, > >> > >> be they called ‘annotations’ or not. Adding a triple to an RDF > >> > >> graph cannot change or modify the asserted truth of any other > >> > >> triple in the graph, even if it refers to it. This follows > >> > >> from the monotonicisty of the underlying semantics. > >> > >> > >> > >> > >> > >> > >> Yes, understood. Adding RDF* triples does not alter the > >> > >> truthvalue of any other triple. The example :certainty could have > >> > >> been any other property, such as dct:created. > >> > >> > >> It seems that the topic you raise applies to RDF* in general, not > >> > >> just this particular syntax extension here in this thread. > >> > >> Yes, it does. This was the first time I had seen the suggestion to use > >> annotations to change the underlying logic, though, so I reacted in > >> place, > >> as it were. Sorry. > >> > >> Best wishes > >> > >> Pat > >> > >> > >> > >> Holger > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> One could of course provide an alternative > >> > >> semantics which would allow this, but the underlying language > >> > >> would then no longer be RDF. > >> > >> > >> > >> > >> > >> > >> > >> This of course does not apply to annotations which > >> > >> record provenance of triples or describe their status in some > >> > >> way. But an annotation which changes the truthvalue of a > >> > >> triple is not merely meta-knowledge or documentation, but > >> > >> rather moves it into a different logic. > >> > >> > >> > >> > >> > >> > >> > >> Pat Hayes > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> On Sep 1, 2020, at 8:07 PM, Jeen Broekstra > >> > >> <jb@metaphacts.com> > >> > >> wrote: > >>> Yes, I think so and apologies if I > >>> > >>> didn't communicate this clearly. > >>> > >>> The point here is to *add* an > >>> > >>> alternative short cut so that instead of > >>> > >>> :bob :age 23 . > >>> > >>> <<:bob :age 23>> :certainty > >>> > >>> 0.9 . > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> we can simply (alternatively) > >>> > >>> write > >>> > >>> :bob :age 23 {| :certainty 0.9 > >>> | > >>> |} . > >>> > >>> This would serve as syntactic > >>> > >>> sugar for the (common) use case of both > >>> > >>> asserting and annotating a triple, while still > >>> > >>> allowing free-standing annotations. The short > >>> > >>> cut will not only make files significantly > >>> > >>> shorter, but also make editing more > >>> > >>> user-friendly. The cost is for implementers > >>> > >>> though, who would have to cover an additional > >>> > >>> case (both in parser and serializer). > >> > >> Thanks for clarifying - in that case > >> > >> I think it's actually a very good idea. The main > >> > >> issue I see with supporting it is in the > >> > >> serialization side, which will be tricky to do for > >> > >> any streaming writer. However, we could support > >> > >> that kind of thing under the moniker of "pretty > >> > >> printing", which is already something that > >> > >> requires buffering anyway. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Jeen > >> > >> > >> > >> > >> > >> > >> -- > >> > >> > >> > >> > >> > >> > >> Dr Jeen > >> > >> Broekstra (he, him) > >> > >> > >> > >> > >> *principal software engineer* > >> > >> > >> > >> > >> > >> > >> > >> jb@metaphacts.com > >> > >> > >> www.metaphacts.com > >> > >> > >> > >> > >> > >> > >> > >> [image: htps://www.metaphacts.com/] <https://www.metaphacts.com/> > > > > -- > > - Blake > > > > Dr. Blake Regalia
Received on Thursday, 3 September 2020 12:37:54 UTC