- From: Thomas Lörtsch <tl@rat.io>
- Date: Fri, 5 Jul 2024 13:32:25 +0200
- To: Niklas Lindström <lindstream@gmail.com>
- Cc: RDF-star Working Group <public-rdf-star-wg@w3.org>
> On 4. Jul 2024, at 18:32, Niklas Lindström <lindstream@gmail.com> wrote:
>
> Hi Thomas,
>
> This is just a quick reply.
I appreciate that you gave me some time to digest it before the meeting!
> I may find time for a better analysis, or
> we might be able to go through it tomorrow.
>
> I think part of why our views differ here is a difference between a
> general "n-ary" with constituent relations of equal or varied standing
> (where "reifiers" may fit the bill), and specialization/qualification
> of a single relationship, as in a specific subproperty with a narrower
> extension (down to a "singleton property" denoting one member thereof,
> i.e. tied to one specific subject and object). Then we have the full
> set of reifiers, which may include all of these, but are
> conceptualized from a different angle, having a relationship to the
> relationships they reify.
I suggest that we use the term "reification" not in a general sense - some argue that the data model of Wikidata is essentially reification - but to refer to RDF standard reification. That particualr form of reification is well defined, and its weaknesses can clearly be named. In the discussion last Friday Enrico clearly referred to that interpretation, and you do too in the mail that I responded to. So let’s stick to that narrow definition, and name loser definitions "n-ary" or "qualification" or whatever seems appropriate.
> I concur with Peter (in the other thread [1]), i.e. his example and
> reasoning regarding the adequacy of rdf:reifies. In your first
> example, you refer to :Bob and :Alice using :source, which of course
> does not differentiate their relationships to the statement. Further
> down, you do differentiate with :claimedBy and :denouncedBy. The
> subjects in all cases are reifiers of a relationship (the :madeOf
> between :Moon and :Cheese), conceived as a :Claim or an :UrbanMyth,
> respectively. If that is in the graph, it simply holds in its
> interpretation; if it is not, it does not.
The issue is that this robs us of the ability to qualify a specific relation in the graph. E.g. we may say that Alice doesn’t endorse said statement, but Bob does. But can we say something about how we, as the author of te graph, see it? Do we have to resort to ourselves in third person, like:
:a :b :c .
<< :a :b :c >> a :Theory ,
:accordingTo :ThisAuthor .
I want this metaphysical gap betwen the assertion and the annotation to go away. It only adds ambiguity, useless doubt and ample opportunity for nitpicking dissent.
Instead I want an n-ary relation, e.g. like this (could of course also be a singleton property, because annotating the property has more natural semantics):
:a :b [ rdfq:ObjectInQualifiedAssertion :c ;
a :Theory ;
:accordingTo :ThisAuthor ]
rdfq:ObjectInQualifiedAssertion rdfs:domain rdfq:QualifiedAssertion .
This provides a solid link between assertion and annotation. The only thing that needs to be defined is what it means for a value to be qualified, i.e. to be the _main_ value, not the annotation to it. That is not without problem, or otherwise I would already provide a nicer wording instead of "ObjectInQualifiedAssertion", but it is doable. Even power hungry princes have been able to come up with something catchy - "primus inter pares" - so the concept seems intuitive enough to even withstand war and terror.
> With "rdf:q" you kind of "reinvent" QuID [2] (itself just a collection
> of preexisting notions),
IIRC you dismissed the concept of qualification because you found it running against monotonicity. Do I remember that right?
> which I sent to the CG some years ago [3], as
> you might recall. Qualification is an interesting topic, and reifiers
> can relate to it, but reifiers are also useful when you *don't* have
> qualified relationships, and want to add something ("in the margins").
Which is why I don’t argue against them in toto. I propose to have asserted and unasserted annotations, the former specified as qualification, the latter as reification.
> If you use subproperties instead of :madeOf, you don't need that; nor
> RDF-star at all.
RDF-star is a syntax. It is syntactic sugar, and we discuss "snytactic sugar for what". Defining it as sugaring only reification is a waste, and a deviation from use cases. Most use cases are concerned with n-ary relations and their downsides, foremost there unwieldyness when used a lot, and their requiring updates to queries when introduced at a later stage. This is where our focus should be, not less important issues like unasserted assertions, marginalias, and purist applications of logic largely decoupled from the messiness of the real world.
> But that doesn't handle a neutral reference to a
> member (subject, object pair) of that relationship (the extension of
> the property in the interpretation). Of course, you can
> non-normatively use classic reification for that. (For context, I
> believe qualification of each constituent is what Kurt is also aiming
> for in [4].)
Honestly, I’m done with non-normative. I don’t want to take part in another mess like RDF 1.1 named graphs that have no fixed interpretation. Personally, I’m so obviously frustrated because I’m sick of falling into the same semantics trap again and again, or being ambushed by logicians how can argue just as unprincipled as anybody else when intuition hits them the wrong way. I want a solid and straightforward solution, fit for the real world, period. Logicians are free to continue to use reification when the application demands it. And I see no harm in using reification for unasserted assertions in general, so the two needs seem to converge nicely there. But for annotating assertions that are actually meant to be asserted, qualification is by far the more solid approach.
> Regarding the ensuing disagreement: While it is true that named graphs
> are pairs of names and graphs--and there are no semantics for this
> pairing within datasets--the graphs in these pairs *are* RDF graphs
> [5]. They are also "isolated" by the lack of dataset semantics (which
> I'd argue is a good thing, or at least a "necessary evil", due to the
> inconsistencies and contradictions inherent in the existing
> representations of the "semantic web"). But you can still reason about
> multiple RDF graphs in other ways, such as whether one entails the
> other within the same interpretation. Also, if you merge graphs, which
> is common practice, you can of course reason about that resulting
> graph. I took Peter to be doing just that (talking about each subgraph
> and then their union,
No, he didn’t provide the union, which is precisely why the whole exercise was beside the point. In the WG work we only discuss unions. We don’t work with combinations of graphs. Named graphs are out of the picture. Otherwise the Nested Named Graph proposal [0] would have provided a nice way forward. If you want to begin that fight again, be my guest, but you know very well who you will be up against.
> all within the same interpretation). This is why
> merging graphs with reifiers is important to get right.
I don’t see where we do that. Many-to-many reifications to me seem like an orthogonal issue, but maybe I’m missing something.
> (Aside: That is also why an isolating "opacity" such as between named
> graphs in datasets could be very tricky to add *into* graphs. If
> *needed*, it could be done by a pairing of the literal forms and
> denoted relationships of triple terms, all in the interpretation. But
> it doesn't appear to be needed, as that can be done explicitly in
> those cases, deemed marginal.
Aside: I agree that a literal datatype would be enough, at least a good start, and pretty unproblematic.
> )
>
> Also, I only called out "unasserted assertions" as a phrase, because
> to me that reads a bit like an oxymoron, whereas triple terms, quite
> possibly being unasserted
I disagree, which is why I cope with bloody finger tips until we have resolved this issue. Your argument assumes that unasserted triple terms are the natural way to go, which is ending the discussion before it began ;-) If you can come up with a better/shorter term instead of "unasserted assertion" I’m all ears!
Best,
Thomas
[0] https://github.com/rat10/nng
> , may work better (as in where a triple is
> used as an object to denote a relationship, which is independent of
> its assertion).
>
> Best regards,
> Niklas
>
> [1]: <https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Jul/0003.html>
> [2]: <https://niklasl.github.io/quid/>
> [3]: <https://lists.w3.org/Archives/Public/public-rdf-star/2021Dec/0120.html>
> [4]: <https://github.com/w3c/rdf-star-wg/wiki/Proposal:-Named-Node-Expressions>
> [5]: <https://www.w3.org/TR/rdf11-concepts/#section-dataset>
>
>
> On Mon, Jul 1, 2024 at 3:05 PM Thomas Lörtsch <tl@rat.io> wrote:
>>
>>
>>
>>> On 28. Jun 2024, at 15:38, Niklas Lindström <lindstream@gmail.com> wrote:
>>>
>>> Hi Thomas,
>>>
>>> I'll attempt to clarify some things, as I see them. There are no "unasserted assertions", there are *references to relationships*
>>
>> And yet you were present in the same meetings as me when I asked, repeatedly, if we really need to support the use case of "unasserted assertion" and neither you nor any other logician said that we can’t support them because they don’t even exist. Instead everybody agreed that we need to support them. Now we need to make it work.
>>
>> However, it seems like we first need to agree on what they are. My intuition is that they describe a statement without endorsing it. That may e.g. be an outdated version, an unacceptable viewpoint, a yet unproven theory, etc. My intuition is that these examples do not describe speech acts, or modalities, or possible worlds in the most general sense. They may do that too, but foremost they have to be able to describe more down to earth things like "a possible fact that I don’t want to assert". They have to be able to capture and qualify an assertion, without asserting that assertion. That is pretty much exactly what "unasserted assertion" means when understood literally. Or am I indulged in some private intuition here, and nobody else can follow along?
>>
>> And on the other hand we also need to be able to qualify assertions that we actually endorse, and assert, and the connection between the assertion and its annotation has to be direct and solid and unambiguous, and not some vague "you’re annotating something which has also been said, by you even, but we still don’t believe it to be safe that you annotate what you said, since although _you_ said, it now is a _fact_ and out of your hands, sorry, please proceed, next!". It seems like currently we don’t have that either, see below. So the RDF-star baseline emperor is indeed naked?!
>>
>>> -- 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).
>>
>> How many angels can dance on the tip of a needle etc. I get what you mean (I guess) but don’t you agree that this is much too brittle to satisfy the charter? IMO this rather provides a surrogate, something painted as enabling statements about statements, but the fineprint then says "sorry, but no, and you obviously didn’t read the fineprint". Nobody will dispute that applying logic to a real world application like the semantic web and especially to a thorny issue like meta modelling requires some wiggle room. But if the ambiguity introduced by that wiggle room essentially turns the whole meta modelling mechanism into a handwaving gnome, then the approach is a failure and needs to be dumped.
>>
>>> 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.
>>
>> It seems to me that you provide a definition that is led by the desire to make it work with the tools that standard logic provides, especially reification. Your definition seems to be led by the interest of the hammer, not by the best interest of the nails. But is reification indeed the right tool? I thought so too, but I’ve changed my mind.
>>
>>
>> In Friday’s SemTF meeting we had a short discussion at the and of the meeting where Enrico forcefully maintained that a reification (and its annotations) have no relation to a fact stated in the graph, just as you explain it above. That is certainly correct from a logicians point of view. And the reification mechanism is designed that way because in standard logic facts are indeed rigid, and can’t be allowed to be influenced by other facts. Everything else is modal, as Enrico puts it. However, the semantic web is not foremost a logic application but a social environment, and logic can only play a serving role in it. On the semantic web, as in real life, everything is essentially modal, and "facts" are just an abstraction, a convention, a common ground that is a result of social processes and negotiations at any and every moment. There is a gap between logic and the real world, and depending on circumstances it can become a real rift. As long as we work with standardized vocabularies and simple facts, that gap is well encapsulated and confined inside vocabulary definitions. However, annotating assertions, unasserted assertions even, certainly exposes such rifts because the layering of statements introduces all sorts of nasty problems, from monotonicity to ambiguous references.
>>
>> We have to find an engineering solution, not a logic solution to bridge this rift, and saying "sorry, but logic can’t handle this" is not good enough. The practical result of our short discussion last Friday to me was that we would have to describe for each annotation if we actually mean that to annotate a fact, an asserted assertion. That may sound crazy (and IMHO it is), but you parsed that sentence right. In our examples currently we write:
>>
>> :Moon :madeOf :Cheese .
>> << :Moon :madeOf :Cheese >> :source :Bob .
>>
>> to express that Bob does not only report such a wild opinion but that he actually states it. I criticized that it’s impossible to add unambiguously that Alice reports the same opinion, but without endorsing it.
>>
>> << :Moon :madeOf :Cheese >> :source :Alice .
>>
>> Because taken together it becomes undistinguishable who endorses what:
>>
>> :Moon :madeOf :Cheese .
>> << :Moon :madeOf :Cheese >> :source :Bob .
>> << :Moon :madeOf :Cheese >> :source :Alice .
>>
>> I claimed that to correctly convey Alice's intent we would need to add to her annotation an explicit remark that she doesn’t endorse said opinion, e.g.
>>
>> :Moon :madeOf :Cheese .
>> << :Moon :madeOf :Cheese >> :source :Bob .
>> << :Moon :madeOf :Cheese >> :source :Alice ;
>> :status :UnEndorsed .
>>
>> This IMO already is pretty bad and that’s why I started that discussion about the current proposal not providing adequate support for unasserted assertions. However, if we do indeed follow the path of pure logic, and Enrico’s argument, then not only Alice’s, but also Bob’s annotation has to be annotated with the intended state of endorsement:
>>
>> :Moon :madeOf :Cheese .
>> << :Moon :madeOf :Cheese >> :source :Bob ;
>> :status :Endorsed .
>> << :Moon :madeOf :Cheese >> :source :Alice ;
>> :status :UnEndorsed .
>>
>> Indeed every annotation that is made with the intent of annotating some asserted fact has to be extended (or even itself annotated) by such a clarification. Otherwise annotations are just separate entities on their own, with no connection to facts in the graph.
>> And if the triple is actually asserted is a whole different story again!
>>
>> This is approach is correct, but it is also ridiculously involved and all but sure to be ignored in practice. It shows how far detached from popular intuitions the concept of reification is - rightfully so from the logic perspective, but to the point of being unusable w.r.t. popular demand. Which is why Bryan already commented on Peter’s description what reification is (or rather what it is not) that then he would just ignore it. IMO that is a perfectly understandable reaction, and it might even be considered valid if not different people would then ignore it in different ways, exactly like RDF standard reification is interpreted in different ways in practice (and not even the specs themselves paint an unambiguous picture as Andy and I painfully realized in a WG meeting last winter). After about 25 years of tense relations between practitioners and logicians on the semantic web I find it astounding that logicians are still not more acutely aware of the limitations of their allmighty formalism, but I guess it comes with the territory. Well, enough with the rant...
>>
>> IMO we can resolve this in two ways. Either we employ - and normatively specify - a less rigid understanding of reification (more like n-ary relations), or we change just one word in the spec, from rdf:reifies to rdf:qualifies... Irony aside, Friday’s discussion convinced me that reification is the wrong conceptualization, as logicians will never let go of a tool that allows them to annotate statements without jeopardizing their whole machinery, and that’s fine and very understandable. So let’s indeed go with qualification, which IMO meets users' intuition much better.
>>
>> And, as I’ve argued many times already, there is no logic problem to qualification: it doesn’t jeopardize monotonicity. The fact that a car is blue isn’t changed if we anntotate it with a qualification about the car also being old, bought, by Alice, yesterday, payed in cash, as reported by Bob, as featured in the news, because Alice is also known as Alice Cooper and is a well-known artist, etc, etc. The instant that all this FUD about "but one statement is not allowed to change another one" goes away, that instant we can start to engineer a solid solution to "statements about statements". But if we continue to maintain that "one statement is not allowed to change another one" and interpret every annotation as such a change, then … well, then it’s no wonder that we only arrive at ridiculously involved constructs like the one above.
>>
>> But now I’m really done with ranting - sorry, and back to your mail!
>>
>>
>>> 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.
>>
>> My general approach is to support the most common use case with the most straightforward syntax, and make sure that more special use cases are within reach as well, through more specialized vocabulary and maybe syntactic sugar.
>>
>>> I am not sure if you are arguing for making the syntactic sugar of annotations be for a more specific relationship?
>>
>> The most prevalent use case certainly is that of qualifying an assertion - LPG, Wikidata, essentially everything that is not application specific meta data does IMHO qualify as qualification. So annotating an assertion when asserting it (and making sure that the intent of actually asserting it is unambiguously captured) is the dominant use case.
>>
>> Providing the same for unasserted assertions - to document world views, for versioning, to faciltate controlled data integration, etc - is what some use cases ask for. Those use cases are deemed to be important enough by the WG that we need to provide the same expressivity for them as for the annotation of assereted assertions. It seems to me that that demands and requires more vocabulary and syntactic sugar (not just "less of the same").
>>
>>> Given that currently, this (A):
>>>
>>> :Moon :madeOf :Cheese {| a :Theory ; :claimedBy :Alice |} ,
>>> :Cheese {| a :UrbanMyth ; :denouncedBy :Bob |} .
>>
>> I think I understand, but is this really legal syntax? Just asking. It’s pretty ugly to have to repeat the object.
>>
>>> 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"?
>>
>> Yes. I propose two different syntaxes, e.g.:
>>
>> <<< :Moon :madeOf :Cheese >>> :reportedBy :Alice . # unasserted
>> << :Moon :madeOf :Cheese >> :claimedBy :Bob . # asserted
>>
>> Those map to the following N-Triples-star serialization:
>>
>> _:x rdf:cites <<( :Moon :madeOf :Cheese )>> ; # "rdf:unasserts"
>> :reportedBy :Alice .
>>
>> _:y rdf:asserts <<( :Moon :madeOf :Cheese )>> ;
>> :claimedBy :Bob .
>> :Moon :madeOf :Cheese . # because asserted
>>
>> No more need for a special shorthand annotation syntax. And it is unambiguous who actually endorses a statement, and who only speaks about it.
>>
>> The details (number of brackets, naming of properties) are of course tentative. I stayed clear of "reifies" for obvious reasons, but am not married to such an act of distancing ;)
>> I also hinted at possible extensions of the mechanism towards referentially opaque versions, but that wouldn’t be my priority. I’d prefer the introduction of an RDF literal datatype as a more versatile basic primitive to tackle all use cases that require referential opacity of any kind. I think there we both agree.
>>
>>> 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).
>>
>> But you lose the qualification: _the_ fact is said, and _such_ a fact had been annotated, but if the two are in any more intimate relationship (as most of the use cases clearly assume) is lost, irrevocably. That is the problem.
>>
>>> 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).
>>
>> I think that in general this is too tedious because almost every annotation will need to explicate what by intuition would seem self-evident. Again: I think you don’t see it because you have that hammer called reification. IMO almost every nail, err use case, asks for qualification of assertions that are actually asserted.
>>
>>> 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.
>>
>> You can do all that based on the unasserted assertion:
>>
>> <<< :Moon :madeOf :Cheese >>> a :Belief, :Contradiction, :Suggestion . # 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,
>>
>> The essence of singleton properties is not its specific syntax, or the difficulties in implementing it (where w.r.t. indexing I’m inclined to say "tough luck" to those that don’t index properties, but the need to join over the property column seems to be a real problem). Its essence is qualification through instantiation, and that I do indeed argue for.
>>
>>> 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]).)
>>
>> The simple baseline actually says little about the meaning of that rdf:reifies property. It’s all in our heads AFAICT. It would be in the proposal if we had opted for e.g. Option 1, but now it’s just a word, and as I said above: replace it with rdf:qualifies and the intuitions change completely. Implementor's opposition to decomposing the triple term notwithstanding I think we absolutely need to provide a mapping to standard RDF to make very definitely clear what the meaning of this new construct is, and of course also to facilitate backwards comptability.
>> If that mapping uses RDF standard reification (which in our heads presently it does) then we get into the troubles of rigid interpretation of reification, see above). We could however just as well provide a singleton property based mapping that champions qualification of instances. We don’t even need to base it on the property because that is technically problematic (missing predicate index, more involved joins). Take the following mapping:
>>
>> :Moon :madeOf _:QualifyableFactID .
>> _:QualifyableFactID rdf:qualificationObject :Cheese ;
>> :claimedBy :Bob .
>>
>> rdf:qualificationObject rdfs:Domain rdf:QualifyableFact .
>>
>> (ugly naming to make the meaning clearer)
>>
>> An rdf:QualifyableFact would be considered asserted and should be present as a fact in the data. There would need to be more predicates to support unasserted assertions, opacity, etc.
>> A property path construct in SPARQL makes it easy to query for facts no matter if they are qualified or not, e.g.
>>
>> ?thing :madeOf/rdf:q* :Cheese .
>>
>> (obviously rdf:qualificationObject is too long, so I added that
>>
>> rdf:qualificationObject owl:sameAs rdf:q .
>>
>> )
>>
>> One might even add an option to configure the query to automatically always check the qualifying extension of statements, i.e. under the hood always add that /rdf:q* path expression to any property in a query. That might allow to get away without explicitly adding the straight fact triple to the data, omitting the need for any entailments or mapping macros. Maybe cool, maybe brittle...
>>
>> A problem of this proposal is that the mapping might lead users to believe that it explicitly qualifies the object of the statement. The triple term syntax doesn’t have that problem. To mitigate it we should add more specific properties that allow to annotate the triple itself (as an entity of its own right), the relation (probably the usual case) and subject and object of the statement individually. In RDF-star syntax, e.g. "<< ::Moon :madeOf :Cheese >> :claimedBy :Bob ." it is quite undefined if an annotation refers to the whole entity or the property, and in practice it will probabl ybe used either way (in any case it requires extra effort to annotate subject and object specifically).
>>
>>
>> And now the really heretic proposition: this is so compact that we might even dump the RDF-star abstract triple term alltogether.
>> This RDF
>>
>> :Moon :madeOf _:qID .
>> _:qID rdf:q :Cheese ;
>> :claimedBy :Bob .
>>
>> rdf:qualificationObject owl:sameAs rdf:q .
>>
>> and these SPARQL queries
>>
>> SELECT ?thing
>> WHERE ?thing :madeOf/rdf:q* :Cheese .
>>
>> SELECT ?thing ?claimedBy
>> WHERE ?thing :madeOf [ rdf:q :Cheese ; :claimedBy ?claimedBy ]
>>
>> need neither a new term type nor a new syntax.
>> I concur that
>>
>> << ::Moon :madeOf :Cheese >> :claimedBy :Bob .
>>
>> and the respective SPARQL queries are more readable. However, if a relatively straightforward two-triple n-ary relation is enough reason to introduce a new term type into the abstract syntax is another quetsion.
>>
>>> 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.
>>
>> To me it seems like those worries are belayed, but note that an approach that favors qualification instead of reification automatically shifts the intuition towards the LPG use case. A reification talks about an object, and that object can be composed of one or many statements as we discused and agreed (only a mapping FROM LPG TO RDF would ensure that intitially they don’t). However, if our mental model and mapping is instead guided by qualification through instantiation, then IMO the problem goes away as there is no intuitively sensible way to instantiate a qualified entity from two very different "parent" entities. Only if those entities co-denote the intuition is again that they may be instantiated to the same qualifier. That may well be exactly what we want: it allows co-denotation, but it discourages arbitrary groupings of statements. Well, I’m sure some would also like the latter (probably me included), but I tend to accept Bryan’s argument that then we have to employ an additional mechanism (extra triples to denote membership in a graph, extra syntactic sugar, whatever).
>>
>>> 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")).
>>
>> It’s not only LPG, it’s at least also Wikidata, and I maintain: it’s indeed almost everything except application specific meta data (but that won’t suffer, or can just use named graphs) and very logic-leaning applications (but those are rare, or can just use standard reification). And also, in case you (still! ;-) don’t agree with my assessment, remember that what I propose is pretty extensible. One primitive - triple term or just a two-part n-ary relation - but as many qualifying/reifying/objectifying/instantiating/whatevering properties as necessary.
>>
>> Best,
>> Thomas
>>
>>> 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, 5 July 2024 11:32:36 UTC