Re: A different symbol for {|

Or:

    bob: age 42 *{ :source <http://example.org/~bob/ <http://example.org/~bob/>> }

After all it's called RDF Star...

Richard



> On 5 Jan 2021, at 11:47, Ghislain ATEMEZING <ghislain.atemezing@gmail.com> wrote:
> 
> There can be also alternatives such as the following:
> 
> bob :age 42 @( :source <http://example.org/~bob/ <http://example.org/~bob/>> )
> 
> bob :age 42 ^^{:source <http://example.org/~bob/ <http://example.org/~bob/>> }
> 
> bob :age 42 ^^(:source <http://example.org/~bob/ <http://example.org/~bob/>> )
> 
> Yes, a combination of requirements and little subjectivity will play to have a good candidate.
> 
> #my2cents 
> Ghislain 
> 
> Sent from a mobile device, please excuse any brevity or typing errors
> 
> 
>> Le 5 janv. 2021 à 11:41, Miel Vander Sande <miel.vandersande@meemoo.be> a écrit :
>> 
>> 
>> IMO, sticking to the triple structure is the only thing that makes sense coming from RDF. I only brought this proposal up to illustrate that there have been alternatives. 
>> 
>> The only leanier thing I can think of is:
>> - graph annotation:  { :s :p "abc" @en } -> this is an N3 feature and not part of RDF*
>> - SA mode: {$ :s :p "abc" @en } (could be the same as the above, up to the implementers)
>> - PG mode -> {! :s :p "abc" @en }
>> 
>> 
>> 
>> Op di 5 jan. 2021 om 10:57 schreef Andy Seaborne <andy@apache.org <mailto:andy@apache.org>>:
>> 
>> 
>> On 04/01/2021 22:42, Holger Knublauch wrote:
>> >>
>> >> :bob :age 42 @{  :source <http://example.org/~bob/ <http://example.org/~bob/>> }
>> > 
>> > I would prefer this @{ ... } over {| ... |} and believe this topic is 
>> > quite important to get right, as there may be a large number of files 
>> > that actually fit into this dialect.
>> 
>> Holger - Just checking here - by "this dialect" do you mean @{... } ? If 
>> so, it would be good to have references to any data and parsers 
>> conforming to this.
>> 
>> I believe in discussions in this community it has been no more than an 
>> idea expressed.  I haven't seen a link to any data or parsers using that 
>> style.
>> 
>> All - Has anyone tried?
>> 
>> ---
>> :s :p "abc"@{ :a:b } .
>> ---
>> and why isn't that read as modifying "abc"?
>> 
>> 
>> https://github.com/w3c/rdf-star/issues/9 <https://github.com/w3c/rdf-star/issues/9>
>> https://lists.w3.org/Archives/Public/public-rdf-star/2020Aug/0043.html <https://lists.w3.org/Archives/Public/public-rdf-star/2020Aug/0043.html>
>> 
>> 
>> == Call for Implementation Experience ==
>> 
>> For any of the Turtle, TriG and SPARQL -
>> 
>> has anyone tried it when the object is a string literal?
>> 
>> It is not in conflict with the grammar in the spec (I have checked 
>> Turtle/LL(1)) but this may cause problems because there may be compliant 
>> parsers ("compliant" => pass all current legal Turtle files) that do 
>> langtag parsing differently. There are quite reasonably alternatives in 
>> regular turtle for implementation.
>> 
>> ---
>> PREFIX : <http://example/ <http://example/>>
>> :s :p "abc"@{ :a:b } .
>> ---
>> 
>> And because there can be space between " and @:
>> 
>> ---
>> PREFIX : <http://example/ <http://example/>>
>> :s :p "abc" @en , "abc" @{:a :b} .
>> ---
>> 
>>      Andy
>> 
>> > 
>> > Holger
>> > 
>> > 
>> >>
>> >> Sort of doable.
>> >>
>> >> No technical barrier that I can see but it has it's own style 
>> >> implications.
>> >>
>> >> In Turtle etc, @ introduces langtags (not a techncial barrier - 
>> >> langtags are at least one character) so still have syntax that 
>> >> suggests another thing. Or directives (Turtle, N3).
>> >>
>> >> The trailing "}" is the same as graph end (TriG), block end (SPARQL) 
>> >> and formula end (N3), which as mentioned last time, does not help 
>> >> visual pairing of start-finish annotation to the same degree as a 
>> >> distinctive pair.
>> >>
>> >> There seems to be no single perfect answer.
>> >>
>> >>> }.| syntax. Bu I believe the plan is to keep annotations and triples 
>> >>> together while staying within the triples  model.
>> >>>
>> >>> best
>> >>>
>> >>>
>> >>> Op zo 3 jan. 2021 om 09:02 schreef Laura Morales <lauretas@mail.com <mailto:lauretas@mail.com> 
>> >>> <mailto:lauretas@mail.com <mailto:lauretas@mail.com>>>:
>> >>>
>> >>>     Hello,
>> >>>     since the spec is still WIP and you are welcoming comments, I would
>> >>>     like to suggest to change the symbol {|
>> >>>     The main reason is that I find it very ugly and in stark contrast
>> >>>     with the simplicity and user-friendliness of Turtle. The two symbols
>> >>>     are also on the opposite sides of the keyboard and require quite
>> >>>     some effort to type (at least for ISO keebs), but this is only a
>> >>>     secondary reason; much less of an issue than the first one. I don't
>> >>>     find << >> particularly nice too, but it's completely bearable and I
>> >>>     don't really have much problems with it. But {| |} is just... too
>> >>>     much, I think.
>> >>>     I understand that the symbol must work both for Turtle and SPARQL,
>> >>>     and the list of available characters combinations is limited because
>> >>>     of this fact. So I'm not sure what a better replacement could be, if
>> >>>     a new keyword, or a different 1-char symbol, or a better 2-char
>> >>>     symbol such as {{ [[ (( -> => etc. Can << >> be reused maybe? What
>> >>>     are the use cases for using << >> as an object of another triple?
>> >>>     Maybe << >> as a subject could stand for non-assertion triples,
>> >>>     whereas << >> used as an object could stand for annotation (instead
>> >>>     of {| |}). Even a reference system like this would be better imo:
>> >>>
>> >>>          :alice :knows :bob . [1]
>> >>>          ...other turtle ...
>> >>>          [1] ex:since 1980 .
>> >>>
>> >>
>> > 
>>