- From: Holger Knublauch <holger@topquadrant.com>
- Date: Thu, 3 Sep 2020 13:35:43 +1000
- To: public-rdf-star@w3.org
- Message-ID: <79e56df0-d978-948b-4735-138446ee3bc9@topquadrant.com>
On 3/09/2020 13:24, Blake Regalia wrote:
>
> :bob
> a :Person ;
> :age 23 ; {| :author :alice; :certainty 0.9 |} ;
> :gender :male ; {| :author :alice |} ;
> .
>
>
> ^^ Hmm, this example of mixing different annotations strikes me as a
> bit odd. Annotating the certainty for each statement seems reasonable,
> and so I see the appeal of the granularity, but I would not say this
> is more natural from a "how people currently work with Turtle"
> perspective. Also, why does the statement that Bob is a person appear
> in the same predicate-object list as assertions /about/ Bob made by Alice?
>
> 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.
It is perfectly fine to have different opinions here. Maybe the
preference shifts if one's focus is on the annotations and provenance vs
the assertions. In any case, the << syntax always remains as fallback. I
guess working with practical use case would inform this better than
these toy examples. In a W3C WG there would be a straw poll on the
various options. We need that too at some stage.
>
> 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>> .
>
Ok makes sense. In this case you'll be in SA mode, i.e. the generic <<
... >> syntax, and triples-as-objects remain available.
Holger
> - Blake Regalia
>
>
> On Wed, Sep 2, 2020 at 7:05 PM Holger Knublauch
> <holger@topquadrant.com <mailto: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
>> <mailto:phayes@ihmc.us>> wrote:
>>
>>
>>
>>> On Sep 2, 2020, at 2:44 AM, Holger Knublauch
>>> <holger@topquadrant.com <mailto: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 <mailto: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 <mailto:jb@metaphacts.com>
>>>>>
>>>>>
>>>>> www.metaphacts.com <https://www.metaphacts.com/>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> htps://www.metaphacts.com/ <https://www.metaphacts.com/>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>> --
>> - Blake
>>
>> Dr. Blake Regalia
>
Received on Thursday, 3 September 2020 03:36:01 UTC