- From: Niklas Lindström <lindstream@gmail.com>
- Date: Fri, 28 Jun 2024 15:38:14 +0200
- To: Thomas Lörtsch <tl@rat.io>
- Cc: RDF-star Working Group <public-rdf-star-wg@w3.org>
- Message-ID: <CADjV5jdj1AaFT0cdw9HySKT=S06amCBWU9z+0sgnGtz6uGodJg@mail.gmail.com>
Hi Thomas,
I'll attempt to clarify some things, as I see them. There are no
"unasserted assertions", there are *references to relationships* -- i.e. to
the abstract relationship atom (propositional axiom) that a triple term
denotes. A triple is asserted if it is a member of the graph. Asserting it
is done through a statement -- a token, which is a kind of occurrence, not
in the graph, but in the domain of discourse (which can include
representations of the graph, or parts thereof). A referenced relationship
may or may not also be stated (said to hold) by a triple in the graph; that
is orthogonal. If it is, then there exists an occurrence of such a
triple (unless the domain is restricted in some way). It may be in a book,
in an utterance, an RDF serialization, or some other reifier. The graph may
also describe those occurrences (atomic triple tokens, or more
coarse-grained such as composite claims or observations) and which of them
are trusted by some agent, such as the publisher of a representation of the
graph.
Currently, for RDF 1.2, the proposal on the table [1] is to make such
references through `rdf:reifies`. This is a very generic notion (like
`rdf:type`), for which there is proposed syntactic sugar. We *may* add
more, if use cases require it. But doing so either requires more
differentiating syntax, or "bare" use of triple terms. That requires users
to make choices.
I am not sure if you are arguing for making the syntactic sugar of
annotations be for a more specific relationship?
Given that currently, this (A):
:Moon :madeOf :Cheese {| a :Theory ; :claimedBy :Alice |} ,
:Cheese {| a :UrbanMyth ; :denouncedBy :Bob |} .
is *identical* to this (irregular) formulation (B):
:Moon :madeOf :Cheese {| a :Theory ; :claimedBy :Alice |} .
<< :Moon :madeOf :Cheese >> a :UrbanMyth ; :denouncedBy :Bob .
As is this (C):
:Moon :madeOf :Cheese .
<< :Moon :madeOf :Cheese >> a :Theory ; :claimedBy :Alice .
<< :Moon :madeOf :Cheese >> a :UrbanMyth ; :denouncedBy :Bob .
Do you want to further differentiate that? As in having the annotation
syntax expand not to `rdf:reifies`, but to something like `rdf:asserts`?
I.e. to say "this relationship holds"?
As you point out, anyone can also define a class of reifiers which
represent "that which is true". Or better, if you, as a creator or
publisher of a graph, want to say that you believe in a specific reifer,
then do so: `<moon-cheese-theory> :believedBy <me>`. (See also how ranking
is modelled in Wikidata [2].) That is part of the domain of discourse.
I thus don't believe anything more is needed; but it could be debated. I
believe that the connection between a reifier referencing a relationship
and an assertion of it is the relationship itself. We know that it is
asserted if it is asserted, making it *simply* true (in the domain the
graph expresses). The reifier "doesn't know" what the graph at hand
contains or not. Its rdf:type determines its nature as a reifier (a
:Belief, a :Contradiction, a :Suggestion, a :Marriage, a
:PublicationEvent). And I want to be able to annotate things I believe with
many different kinds of reifiers thereof; some being dissenting beliefs,
suggested refinements, etc.
(I do however want a slightly more convenient syntax to not have to repeat
the object as in (A) above. And I want to group unasserted relationship
reifiers under a shared subject. (I've implemented that, but we need to
settle this design before going further with syntactic details.) That is to
make *lots* of data with reifiers more readable and without brittle
repetition; some of stated facts, some of proposed or rejected claims.
(These examples we use are but a tiny fraction of what we have in our
records.) But I do not want to introduce more nuances and differing
meanings at this basic level (and certainly not opacity, other than through
explicit, regular use of literals). Adding triple terms as objects is
already radical enough IMO. I have accepted that added complexity, since I
see its potential.)
But if you are also(?) arguing for singleton properties, which I believe
Kurt is in [3] (along with other things), then we are not that close to
agreement on what we need for referencing relationships. I still hope we
can settle for the simpler baseline [1]. Otherwise, we will have to debate
well-formedness, classic reification and singleton properties. If we have
not retained the arguments against those, those need to be revisited.
(Arguably, one upshot of that is, *if* it makes more sense to most people,
at least I see no need to add triple terms at all. Well-formedness would be
enough (as I said in [4]).)
I am also not sure if the worries from e.g. the Amazon and SAP
representatives regarding the LPG use cases are belayed yet (no references,
see various mails), or if they still need *something* "token-like" [4, 5],
rather than general reifiers. I do still maintain that if something
*directly* isomorphic to the LPG design is called for, then that is the
singleton property design, as in "relationship instances" (at least that's
how Neo4J conceptualizes it). I just don't believe that is what is called
for in general. I believe that the general [1] option can handle LPGs too
(just not always roundtrippably; as reifiers, like other aspects of
RDF, are decidedly more expressive and general (and IMHO "natural")).
Best regards,
Niklas
[1]: <
https://github.com/w3c/rdf-star-wg/wiki/RDF-star-profile-%22transparent%22>
[2]: <https://www.mediawiki.org/wiki/Wikibase/DataModel#Ranks_of_Statements>
[3]: <
https://github.com/w3c/rdf-star-wg/wiki/Proposal:-Named-Node-Expressions>
[4]: <
https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024May/0046.html>
[5]: <
https://docs.google.com/presentation/d/e/2PACX-1vQd9lU1j4TPxluCe-cB0t7_BUpy8zAfeY_5hDlbwIyOB8wsiRqkRtSFP4AeflV5UsE4EqT-Y3_Jjx9q/pub
>
On Tue, Jun 25, 2024 at 2:47 PM Thomas Lörtsch <tl@rat.io> wrote:
>
>
>
> > On 20. Jun 2024, at 17:53, Niklas Lindström <lindstream@gmail.com>
wrote:
> >
> > On Thu, Jun 20, 2024 at 4:12 PM Thomas Lörtsch <tl@rat.io> wrote:
> >>
> >>
> >>
> >> Am 20. Juni 2024 12:46:49 MESZ schrieb "Niklas Lindström" <
lindstream@gmail.com>:
> >>> Thomas,
> >>>
> >>> Neither reifier asserts the triple. It is simply either asserted --
> >>> i.e., in the graph -- or not.
> >>>
> >>> If you use named graphs for provenance, then maybe you have an
> >>> existing "out of band" way, using some domain-specific vocabulary
> >>> (e.g. dc:creator and/or dc:source) to describe the resource whose name
> >>> is paired with the graph (outside of formal semantics).
> >>>
> >>> With reifiers, you can model this more granularly with reifiers
> >>> (themselves, as resources denoted by their names) being explicitly
> >>> related to one or more relationships (or possibly opaque triples
> >>> thereof). You still need to define predicates and/or classes which
> >>> describe the intent/meaning of that, within your domain of discourse
> >>> (see Wikidata for an example of such design).
> >>>
> >>> But triples are still simply asserted or not asserted -- either in the
> >>> graph or not. That is the simple, monotonic way RDF works. And I can
> >>> imagine there'd be quite some danger in us tampering with that
> >>> simplicity.
> >>
> >> singleton properties showed how to do it a decade ago: infer the
un-annotated statement from the annotated one
> >
> > Yes, that [1] is a particular kind of rdfs:subPropertyOf usage (where
> > it goes down to the singleton specificity of one per
> > subject+object+"particular meaning" combination). I.e. simply what
> > RDFS entailment gives us. But it does not redefine the notion of what
> > an asserted triple is. (Not that that is necessarily what you're
> > asking for, I just want to clarify.)
> >
> > Once we get the basics stable, we should of course further explore
> > which kinds of use case requirements we have that rely on entailments
> > (such as I did in [2] for data integration across granularities). So
> > you could submit it to [3] as a concrete use case, to test the basics
> > against. I am all for elaborating on and framing this need, to get an
> > appropriate suggested usage pattern in place.
> >
> > For triple terms, I expect some sound entailments to be needed (akin
> > to D-entailment); e.g. to align with classical reification, and/or
> > cater for modelling domains and ranges based on triple term
> > constituents; such as for connecting a :Marriage "reifier" class with
> > uses of :spouse predicates in what it reifies.
> >
> > I think that would be enough to, for example, define your use case as
> > a need for *validation*: to check if purportedly accepted claims
> > (given a domain model for such) are also simply asserted. I doubt I'm
> > the only one who'd be glad to help out in sketching out how to use
> > e.g. SHACL for that (even in an "unstarred" form for use in existing
> > tools today).
>
> To give a reasonably complete account of why I think that such an
approach is doable, but still a mistake, let me elaborate a bit.
>
> I take it that the current rough consenus in the WG is that
>
> (A) RDF-star does need to provide unasserted assertions
> (B) RDF-star does provide unasserted assertions
>
> W.r.t. (A) I never was in principal against (A) but I always questioned
its relevance. However, repeated inquiries have seemed to confirm the need,
and standard reification is considered not good enough to fulfill it (i.e.
it s not just an edge case that can be expected to cope with the verbosity
of reification quads). So I take it that there is a real need for
unasserted assertions and it has to be treated not just half-heartedly, but
in a comprehensive way.
>
> W.r.t. (B) I don’t think that RDF-star provides such a comprehensive
solution. The treatment of unasserted assertions in RDF-star is
half-hearted because it can’t unambiguously diffentiate between annotations
on asserted and on unasserted statements.
> In RDF-star unasserted assertions are rather a stepping stone to
statement annotation than a construct of their own right. Because of that
annotating an unasserted statement (with the intend to only describe but
not assert it) works only as long as the statement isn’t asserted by
someone else or in some other context. That is incomplete, and ambiguous.
If we consider (A) a given, then we must get better in (B)
>
> Ted outlined in the Telco last Thursday what he expects from a
comprehensive solution (I hope I do capture him correctly here!):
> - issue asserted statements
> - issue unassserted statements
> - query asserted statements
> - query unasserted statements
> That is a good start, but for the sake of completeness I would like to
add that at all times - when issuing and when querying - it must be clear
if a statement is meant to be asserted or unasserted. Otherwise the state
of assertedness can quickly become unclear when new data is added.
>
>
> The easiest way to extend the current proposal to unambiguous handling of
unasserted assertions would probably be to add a special class
'rdf-star:UnassertedAssertion'.
>
> :Moon :madeOf :Cheese .
> << :Moon :madeOf :Cheese . >>
> a :Theory ;
> :claimedBy :Alice .
> << :Moon :madeOf :Cheese . >>
> a :UrbanMyth , rdf-star:UnassertedAssertion ;
> :denouncedBy :Bob .
>
> That way the following chain of authoring would always lead to an
intuitively correct set of assertions. First Bob’s notion of some
questionable claim is added to the dataset, but making sure to clarify that
he doesn’t endorse what he annotates:
>
> << :Moon :madeOf :Cheese . >>
> a :UrbanMyth , rdf-star:UnassertedAssertion ;
> :denouncedBy :Bob .
>
> Then Alice's point of view is added:
>
> :Moon :madeOf :Cheese .
> << :Moon :madeOf :Cheese . >>
> a :Theory ;
> :claimedBy :Alice .
>
> The result - see above - is unambiguous. One could even add one more
class 'rdf-star:AssertedAssertion' to achieve super-unambiguity, but that
definitely smells like overkill.
>
>
> Granted, this doesn’t look very bad, but it doesn’t look very good
either. Let's look at an alternative, which takes teh problem serious:
let's add a special term type of unasserted assertions and some explicit
syntax, e.g. triple chevrons in Turtle-star, and let the standard triple
term always be asserted (just like it was defined in the original RDR/RDF*
proposal). This would not only relieve users from having to add an extra
triple specifying 'rdf-star:UnassertedAssertion', it would also make the
standard case much shorter.
>
> << :Moon :madeOf :Cheese . >> # like in the original RDR/RDF*
proposal
> a :Theory ;
> :claimedBy :Alice .
> <<< :Moon :madeOf :Cheese . >>>
> a :UrbanMyth ;
> :denouncedBy :Bob .
>
> This is much more straightforward in ALL cases, not just the special case
of unasserted assertions. I think it’s clearly the better solution. It also
makes the shorthand annotation syntax superfluous. That syntax gives the
wrong impression to disambiguate asserted from unasserted annotations, so
getting rid of it would not only streamline the whole proposal but also
remove a possible (and probable) pitfall.
>
>
> For clarification I’d like to add that referential opacity is an
orthogonal issue. E.g. both viewpoints above don’t require referential
opacity. Syntactically it could be added via extra quote signs. E.g. one
might wish to document Bob’s opinion of Alice and the exact wording he
used, but not endorse it:
>
> <<<" :Alice a :Believer ">>> :utteredBy :Bob
>
> I'll leave the formalization to the experts ;-) but all these different
semantics could be derived (with the TEP-mechanism proposed by the RDF-star
CG) from the same primitive in the abstract syntax, i.e. the <<( :s :p :o
)>> abstract triple term. Such a mechanism would also be easily extensible
to other use case like e.g. closed world scenarios or specific constructs
like lists, so it could make for a very nice basis to accomodate often
voiced needs in semantic extensions or future versions of RDF.
>
>
> > What I don't think is that automatic assertion of a reified statement
> > is something to be added to the foundational RDF abstract syntax and
> > semantics. We're trying to keep that simple enough (which is evidently
> > very hard).
>
> It is always a design decision what is considered the right kind of
simple. Very simple formalisms can be very expressive, but also very
tedious to use. Asking users to write down a statement that they want to
annotate a second time, just to annotate it, is tedious and verbose. Yes,
the annotation syntax ameliorates that, but it also gives the impression
that there was a solid connection between the asserted statement and its
annotation, and no connection between an unasserted statement and its
asserted variant if one doesn’t use the shorthand syntax. And that is not
true. So users have to get accustomed to two syntaxes and are still led
into wrong assumptions, plus implementors have to cater for two different
syntaxes. This is not a simple design, and it is error-prone too.
>
> > And keep in mind: RDF-star annotation syntax is also in SPARQL-star,
> > and is precisely for when you want an assertion and accompanying
> > reifier description(s). For one, I would very much appreciate that
> > syntax being extended for unasserted stuff, so I could group such
> > "suggestions" under the same subject. But we're not there yet.
>
> But we have to design that now, as otherwise we might later figure out
that we manouevered ourselves into a dead end. We have to get there now,
not some time later.
>
> > (To entail an assertion from a claim might call for something not
> > practically possible even with OWL today. I believe OWL lacks an
> > efficient means for entailing a simple statement wherein the predicate
> > comes from a non-predicate constituent of another statement (such as a
> > classic reification). Using a system supporting e.g. Notation 3 would
> > make it simple enough of course; something like `{ [] ex:asserts <<(
> > ?s ?p ?o )>> } => { ?s ?p ?o }.`; but that looks dangerous to me...))
>
> I would like to give a more precise answer to this but the only answer I
got to my question how a semantics of asserted triple term occurrences
would look like was that it would only require a minor tweak to the
baseline proposal. So I take it that it's not hard. Singleton properties
come with a complete semantics and set of entailment rules and I’m not
aware that anybody found a bug in those since the proposal was published in
2014. You know OWL better than me but entailing a type from an instance
doesn’t seem like rocket entailment science to my layman’s intuition.
Certainly nothing looking dangerous.
> Then there’s also that new "macro" thing. What’s wrong with defining that
>
> << :s :p :o >> :b :c .
>
> expands to
>
> :s :p :o .
> :x rdf-star:statingOf <<( :s :p :o )>> ;
> :b :c .
>
> whereas
>
> <<< :s :p :o >>> :d :e .
>
> expands to
>
> :y rdf-star:positingOf <<( :s :p :o )>> ;
> :d :e .
>
> (property naming very much provisional)?
>
> I know you are prudent, but designing what we design we have to be bold
at times, as no matter which design we choose we will restrict what others
can do in the future. Being too anxious is as dangerous as overreaching.
>
>
> > Best regards,
> > Niklas
> >
> > [1]: <https://arxiv.org/abs/1509.04513>
> > [2]: <
https://github.com/w3c/rdf-star-wg/wiki/Strawman-Proposal:-Triple-Tokens-Entailing-Reified-Statements#bridging-different-designs
>
> > [3]: <https://github.com/w3c/rdf-ucr/>
>
> Thanks for taking the time to add proper references!
>
> I might write up a use case when I’m sufficiently sure that I've got at
least some support for what seems pretty obvious to me. Currently I still
don't sense enough awareness for the problem in the WG to get so formal.
But arguing with you definitely helps to shape and sharpen my argument, so
thanks a lot for that!
>
> Best
> Thomas
>
>
> >
> >>> (If the reifier is the agent that *actually* put the triple in the
> >>> graph, and that is stated, then this is true in a very practical
> >>> sense. But this is the innocent first step down the rabbit hole of
> >>> epistemology. Been there; got the t-shirt (but left it down there).)
> >>>
> >>> Best regards,
> >>> Niklas
> >>>
> >>>
> >>> On Thu, Jun 20, 2024 at 12:05 PM Thomas Lörtsch <tl@rat.io> wrote:
> >>>>
> >>>> [Changing the subject line to bring more attention to this issue]
> >>>>
> >>>> Imagine a graph which contains the following triples:
> >>>>
> >>>> << :Moon :madeOf :Cheese >> a :Theory ;
> >>>> :mentionedBy :Alice .
> >>>>
> >>>> Alice doesn’t endorse that statement, but she is polite and calls it
a 'theory’ nonetheless. Then another pair of triples is added to the graph,
maybe because new facts come in, maybe because a merge is performed between
multiple graphs concerned with that topic. That new pair of triples is:
> >>>>
> >>>> :Moon :madeOf :Cheese .
> >>>> << :Moon :madeOf :Cheese >> :mentionedBy :Bob .
> >>>>
> >>>> (it seems like Bob endorses that theory). The addition results in
the following graph:
> >>>>
> >>>> :Moon :madeOf :Cheese .
> >>>> << :Moon :madeOf :Cheese >> a :Theory ;
> >>>> :mentionedBy :Alice .
> >>>> << :Moon :madeOf :Cheese >> :mentionedBy :Bob .
> >>>>
> >>>> Here it is not clear anymore who asserted what, or who just
commented on a statement without asserting (and endorsing) it. If one
doesn’t know the complete change history of the graph one wouldn’t even
know if both, or none of them, asserted and endorsed that statement ':Moon
:madeOf :Cheese .' (it could have been there before any annotating
satetements).
> >>>>
> >>>> It is also not possible for Carol to add another pair of triples
without getting near the asserted statement that the Moon is made of
cheese, as adding her two cents, err triples:
> >>>>
> >>>> << :Moon :madeOf :Cheese >> a :IdioticClaim ;
> >>>> :mentionedBy :Carol .
> >>>>
> >>>> results in the following graph:
> >>>>
> >>>>
> >>>> :Moon :madeOf :Cheese .
> >>>> << :Moon :madeOf :Cheese >> a :Theory ;
> >>>> :mentionedBy :Alice .
> >>>> << :Moon :madeOf :Cheese >> :mentionedBy :Bob .
> >>>> << :Moon :madeOf :Cheese >> a :IdioticClaim ;
> >>>> :mentionedBy :Carol .
> >>>>
> >>>> I.e. Carol is getting dangeruously close to the asserted claim no
matter her intentions.
> >>>>
> >>>> Knowing this we can’t even be sure anymore that Bob actually meant
to assert and annotate the statement in question. Maybe he already fell
into the same trap.
> >>>>
> >>>> Plain and simple: the construct of unasserted assertions as
currently specified is ambiguous to an untolerable degree. The instrument
as such - being able to annotate statements without asserting them - is a
rather delicate construct. The last thing it needs is ambiguity over the
question if a statement so annotated was asserted or not.
> >>>>
> >>>> The only way out of this conundrum that I see is to explicitly
introduce a type of unasserted term, and by extension define the most
standard term type as asserted (as it was in the original proposal of
RDF*/RDR) (’standard’ here meaning: the most accessible one, the one with
the most straightforward syntax).
> >>>>
> >>>>
> >>>> Such a more explicit approach also has a massive usability advantage
(which is the reason why I started to poke into this issue again): the
normal use case is to annotate assertions that are actually asserted. We
have no empiric evidence for this, but the fact that CG and WG adopted a
special shorthand notation as syntactic sugar to faciltate that case IMO is
proof enough that this sentiment is widely shared at least among us.
> >>>>
> >>>> To make things worse the shorthand annotation syntax is ill
conceived, as it approaches the problem from the wrong direction. A
standard design strategy would be to cater for the vast majority of use
cases first and then try to ease the way for the more involved ones with
some syntactic sugar. The Turtle-star syntax does the opposite: it caters
for unasserted assertions first and then adds syntactic sugar for
annotating asserted assertions. that is pretty bad from a usability
standpoint.
> >>>> However, the real nail in the coffin of the shorthand annotation
syntax is the fact that the information that the syntactic sugar conveys -
if an annotated statement is also meant to be asserted - gets lost when
mapping to the Turtle standard notation, or to any other notation like
JSON-LD, or N-triples even. This is intolerable, as it lures users into
believing that they have expressed something (they think they unambiguously
asserted AND annotated a statement in one go), whereas that crucial detail
- "AND" - will actually get lost with the first transformation into another
syntax. This is plain and simple a very bad design.
> >>>>
> >>>>
> >>>> I’m a bit drastic in my portrayal of this issue because I’ve already
mentioned it multiple times during the last months, but my concerns have
been met with little interest. Of course we also have other problems to
solve, but good solutions often come from clever combinations of issues.
Currently we are discussing different term types (or type defining
properties to the same effect). This could be a very good opportunity to
also resolve this issue about annotations on asserted and unasserted
statements. I hope that the WG will not much longer hesitate to tackle it.
My concrete proposal is to add another syntax for unasserted assertions -
see below the quote of my orignal mail in this thread for more detail. It
is not completely worked out, but it’s at least a start.
> >>>>
> >>>>
> >>>> Best,
> >>>> Thomas
> >>>>
> >>>>
> >>>>
> >>>>> On 19. Jun 2024, at 13:25, Thomas Lörtsch <tl@rat.io> wrote:
> >>>>>
> >>>>> Hi Niklas,
> >>>>>
> >>>>> thanks for looking into this!
> >>>>>
> >>>>> Am 18. Juni 2024 13:20:35 MESZ schrieb "Niklas Lindström" <
lindstream@gmail.com>:
> >>>>>> HI Thomas,
> >>>>>>
> >>>>>> In principle, are you suggesting that an asserted triple should no
> >>>>>> longer mean just "the triple is in the graph", but either that or
when
> >>>>>> it is encoded as a triple literal which is used as an object of a
> >>>>>> triple in the graph (with some predefined predicates)?
> >>>>>
> >>>>> I’m not sure I understand your concern correctly. Let me try to
clarify. You have to distinguish the parts where I speak about the abstract
syntax from those where I sketch concrete implementations. The idea for the
abstract syntax - and IIUC Pierre-Antoine had the same idea, just
formulated as a variant of the CG’s TEP proposal - is to derive all
different concrete semantics (asserted, unasserted, ref. transparent, ref.
opaque, and/or any/some combination thereof) from one abstract type. The
way to describe the desired semantics is by chosing the right property. We
already have such properties in the current baseline proposal, namely
:reifies and :annotationOf, just without this functionality. Instead we
define two different types of abstract triple. The idea is to get away with
only one type of abstarct triple, and putting more
functionality/information into the properties.
> >>>>>
> >>>>>> I.e. that,
> >>>>>> AFAICS, the RDF semantics have to be extended so that each
extension
> >>>>>> of a property also must take into account, recursively, some other
> >>>>>> property extensions, wherein an extension membership (a
"statement")
> >>>>>> is encoded as a literal?
> >>>>>
> >>>>> I'm afraid I can't follow. And please note that the literal aspect
is totally optional, the proposal is just as valid with the abstract triple
term (and its <<(…)>> syntax) as we have it.
> >>>>>
> >>>>>> And, presumably, this would similarly have to
> >>>>>> be added to the definition of basic pattern matching in SPARQL?
> >>>>>
> >>>>> This is a question that I can mostly only speculate about. If the
definition of SPARQL as "Turtle with holes" carries far enough then the
different syntactic variants should allow to focus precisely on
asserted/unasserted/transparent/opaque statements. The details might be
harder to get right: how to query over all asserted statements, no matter
if opaque or transparent? How to to dismabiguate results that stem from
semantically different statements? I’m not sure if the current proposal of
SPARQL-star captures such nuances (because I haven’t investigated this
issue enough).
> >>>>>
> >>>>>> While this is not where my expertise lies, I have a hard time
seeing
> >>>>>> how this simplifies what an asserted triple is. Unless I'm missing
> >>>>>> something, I'd rather stay on the currently agreed route where
> >>>>>> assertion and reification are separate and complementary.
> >>>>>
> >>>>> They don’t complement so much as they should. E.g., can you tell
for sure from the following example if Bob actually did assert <:s :p :o >?
> >>>>>
> >>>>> :s :p :o .
> >>>>> << :s :p :o >> :b :Bob ;
> >>>>> :c :Carol .
> >>>>>
> >>>>> Short answer: you can’t, as at some point all the available
information might have been:
> >>>>>
> >>>>> << :s :p :o >> :b :Bob .
> >>>>>
> >>>>> So no endorsement of < :s :p :o > by Bob. And only later were the
following two triples added (maybe through merge, maybe because new
information came in):
> >>>>>
> >>>>> :s :p :o .
> >>>>> << :s :p :o >> :c :Carol .
> >>>>>
> >>>>> Ergo this is ambiguous. Given that use cases for unasserted
assertions are often concerned with modelling information with a high
degree of precision, this can’t be treated as a rare side-issue, but has to
be understood as a real problem: this approach to unasserted assertions
claims to solve a specific problem (namely to facilitate unasserted
assertions), but it doesn’t provide a solid solution. Nonetheless it makes
normal usage quite a bit harder (at least when one doesn’t or can’t use the
annotations syntax).
> >>>>>
> >>>>> The annotation syntax provides syntactic sugar to ease authoring
(and querying I suppose?), but that sugar dissolves irrevocably as soon as
the data is converted to N-triples. We talked a lot about how important
N-Triples are as the format in which data is sent over the wire, especially
in streaming contexts. I have to take the word of practitioners for it, but
when I do I have to conclude that the way we currently handle unasserted
assertions is dead in the water.
> >>>>>
> >>>>> I looked at the use cases today to see how many of them require
unasserted assertions: not too many, I suppose. The fact that we have extra
syntactic sugar to annotate asserted statements speaks for itself: the
sentiment that those are the norm rather than the exception is not only my
personal impression. This is another reason to not burden the standard case
with an extra syntax.
> >>>>>
> >>>>> The normal approach is to facilitate corner cases with syntactic
sugar, and let those expand to a standard form that converts all the
information encapsulated in syntactic sugar into standard idioms. The
current approach however makes the standard use case dependent on syntactic
sugar, and loses information when converting to standard form.
> >>>>>
> >>>>>> The use of literals, as discussed, also suffers from the problem of
> >>>>>> blank node identifiers [1], which are not global, but local to an
RDF
> >>>>>> document *at parse time*. I believe the CDT [2] proposes to treat
each
> >>>>>> literal as its own document. But this is not easily (if at all)
made
> >>>>>> workable for the needs of RDF-star.
> >>>>>
> >>>>> You may be right w.r.t. blank nodes and literals. So let's keep the
"abstract term" as the basic building block to keep the discussion focused.
> >>>>> However, in principle I guess it shouldn’t be too hard to define
some parsing rules that determine how blank nodes in RDF literals are to be
interpreted. Those rules would again be triggered via the properties that
"unfold" those literals into annotated statements.
> >>>>>
> >>>>> Best,
> >>>>> Thomas
> >>>>>
> >>>>>> Best regards,
> >>>>>> Niklas
> >>>>>>
> >>>>>> [1]: <https://www.w3.org/TR/rdf11-concepts/#section-blank-nodes>
> >>>>>> [2]: <
https://awslabs.github.io/SPARQL-CDTs/spec/latest.html#dfn-bnl2bn>
> >>>>>>
> >>>>>>
> >>>>>> On Sun, Jun 16, 2024 at 10:19 PM Thomas Lörtsch <tl@rat.io> wrote:
> >>>>>>>
> >>>>>>> as was discussed in the semantics TF meeting last friday we could
streamline the abstract syntax of the baseline proposal by deriving triple
term occurrences with different semantics from only one primitive, the
abstract triple term - the '<<( :s :p :o) >>' in n-triples - by defining
appropriate properties, e.g. for referentially transparent occurrences
> >>>>>>>
> >>>>>>> :reified_x rdf-star:reificationOf <<( :s :p :o )>> .
> >>>>>>>
> >>>>>>> and for referentially opaque occurrences
> >>>>>>>
> >>>>>>> :annotated_y rdf-star:annotationOf <<( :s :p :o )>> .
> >>>>>>>
> >>>>>>> this seemed like a good idea to some people (including me) and
IIUC Enrico might incorporate it into an update to the baseline proposal.
> >>>>>>>
> >>>>>>>
> >>>>>>> for one, it occurred to me later (again, and the original idea is
not mine) that we could then also replace the abstract triple term by a
literal of a to be defined RDF datatype, e. g.:
> >>>>>>>
> >>>>>>> :reified_x rdf-star:reificationOf ":s :p :o"^rdf:ttl .
> >>>>>>> :annotated_y rdf-star:annotationOf ":s :p :o"^rdf:ttl .
> >>>>>>>
> >>>>>>> it seems that this wouldn't require any change to the RDF 1.1
abstract syntax at all, which would be nice. also, as recent works by the
Amazon Neptune team have shown, there is more interest in and more uses for
an RDF literal datatype. it would be a generically useful addition to the
RDF toolbox.
> >>>>>>>
> >>>>>>>
> >>>>>>> secondly, i'd like us to think again about the different
semantics we need. both options discussed in the current proposed baseline
are unasserted, one of them is referentially transparent and the other one
to some degree opaque. it bothers me a great deal that we provide no option
to assert and annotate statements in one go (the same when querying). this
makes statement annotation unnecessarily tedious in the majority (*) of use
cases (and it introduces ambiguity when annotated statements occur both in
asserted and unasserted form). we should change this and make the
referentially transparent triple occurrence asserted (as it was conceived
in the original RDF* proposal) whereas the referentially opaque variant may
remain unasserted.
> >>>>>>>
> >>>>>>> we could also define all 4 permutations of asserted/unasserted
and referentially transparent/opaque, e.g.
> >>>>>>>
> >>>>>>> # stating - asserted, ref. transparent
> >>>>>>> ## asserting and annotating in one go
> >>>>>>> ## n-triples
> >>>>>>> :a rdf-star:statingOf ":s :p :o"^rdf:ttl ;
> >>>>>>> :some :Attribute.
> >>>>>>> ## turtle
> >>>>>>> << :s :p :o >> :some :Attribute.
> >>>>>>>
> >>>>>>> # mention - unasserted, ref. transparent
> >>>>>>> ## citing, but not endorsing, without syntactic precision (eg
indirect speech)
> >>>>>>> ## n-triples
> >>>>>>> :b rdf-star:mentionOf ":s :p :o"^rdf:ttl ;
> >>>>>>> :some :Attribute.
> >>>>>>> ## turtle
> >>>>>>> <<< :s :p :o >>> :some :Attribute.
> >>>>>>>
> >>>>>>> # posit - asserted, ref. opaque
> >>>>>>> ## stating with exactly these terms (eg functional mapping from
LPG)
> >>>>>>> ## n-triples
> >>>>>>> :c rdf-star:positingOf ":s :p :o"^rdf:ttl ;
> >>>>>>> :some :Attribute.
> >>>>>>> ## turtle
> >>>>>>> <<" :s :p :o ">> :some :Attribute.
> >>>>>>>
> >>>>>>> # quote - unasserted, ref. opaque
> >>>>>>> ## quoting, not asserting, exactly those terms (eg versioning)
> >>>>>>> ## n-triples
> >>>>>>> :d rdf-star:quotingOf ":s :p :o"^rdf:ttl ;
> >>>>>>> :some :Attribute.
> >>>>>>> ## turtle
> >>>>>>> <<<" :s :p :o ">>> :some :Attribute.
> >>>>>>>
> >>>>>>> naming of the variants and syntax variations are of course
tentative proposals.
> >>>>>>> also i've omitted the optional explicit occurrence identifiers in
the turtle syntax.
> >>>>>>>
> >>>>>>>
> >>>>>>> all 4 variants make sense, but the first one is without
reasonable doubt the most important one.
> >>>>>>>
> >>>>>>>
> >>>>>>> how precisely referential opacity is to be defined is another
question. the RDF literal shouldn't be constrained to single statements
and bnodes might be treated decently by annotating their concise bounded
description. alternatively the CG semantics of always transparent bnodes
might be used. IRIs in ref. opaque posits and quotes would denote, but not
co-denote. fully uninterpreted, syntactic opacity can be achieved via the
RDF literal itself.
> >>>>>>>
> >>>>>>>
> >>>>>>> the abstract syntax wouldn't change at all, but the semantics
would be extended by formalizations of the different types of annotated
terms: stating (same as RDF 1.0/1), mention, posit and quote.
> >>>>>>>
> >>>>>>>
> >>>>>>> best,
> >>>>>>> thomas
> >>>>>>>
> >>>>>>>
> >>>>>>> (*) Andy might again denounce this as a sweeping claim, but in
the absence of solid empiric data what else can we do but make good guesses.
> >>>>>
> >>>>
> >>>
>
Received on Friday, 28 June 2024 13:38:49 UTC