Re: Three ideas

Hi Peter

>
> :BOUP rdf:subject :Obama ; rdf:predicate :role; rdf:object :UsPresident ;
>    :between [ :start "2009" ; end "2017" ] .
>


> PS:  Note that I am not arguing that this is a good way to represent
> temporal
> qualifiers.  I am just arguing that RDF is just as good RDF-star for adding
>
> temporal qualifiers.  I actually think that this is a bad, albeit common,
> way
> to represent temporal information.
>

This basically describes time and space positions, or statement-level
timestamping, however you want to view it. I share Fabio's sentiment here,
it's interesting to hear that it's common.

PPS:  If we wanted to be more explicit about the representation we could
> create subclasses of rdf:Statement for cases where we want to talk about a
>
> proposition and cases where we want to talk about stating a proposition.
> This
> allows RDF to be more flexible than RDF-star.  Advantage RDF.
>

This is one of those cases where it's arguable that syntax is easier than
vocabulary. Use cases drop rapidly the further you go, but syntax allows
for nesting, whereas with subclasses I think it turns out to be something
like:

rdf:Statement
    rdf:StatementAboutStatement
        rdf:StatementAboutStatementAboutStatement
            rdf:StatementAboutStatementAboutStatementAboutStatement
                ... and so on.

The same idea applies to lists, it's arguable that list syntax is easier
than list vocabulary.

Regards
Anthony


On Mon, Jan 24, 2022 at 11:40 AM Fabio Vitali <fabio.vitali@unibo.it> wrote:

> Dear Peter,
>
> I fear there might have been a misunderstanding.
>
> I am in not an original proposer of rdf-star, nor an uncritical zealot. As
> such, I do not think it is my role to justify the existence of rdf star nor
> its improvements over standard RDF reification. People much more competent
> and authoritative than me can do this much better than me.
>
> The main point of the original discussion was not to compare the relative
> merits of temporal annotations using rdf star vs. other models, but rather
> to defend whether it made sense to use rdf-star for actually expressing
> temporal annotations. In that discussion, my point of view was (and is)
> that temporal annotations are simply another non-particularly-special case
> of annotations over a triple, like location, provenance or confidence,
> cases that have been adopted with considerably less objections than time.
>
> Indeed, your suggestion that making temporal annotations using rdf
> reification is a legal (albeit bad (albeit common)) approach fills my heart
> with joy, because it confirms my suspicion that my idea actually makes
> sense.
>
> Of course, rdf reification is just a conceptual model, while rdf star also
> has a linearization and a query language, so it is very hard to compare
> them. You express this yourself: "If there is a desire for better syntax
> then add a new shorthand to Turtle", let's go ahead and imagine a
> Hypothetical Extension to Sparql and Turtle to Express Reification
> (HESTER), so as to level the field.
>
> Of course, rdf-star has several additional aspects totally non relevant to
> the discussion about temporal annotations, including a different semantics
> and this weird idea of referential opacity, that make the FULL comparison
> between rdf-star and HESTER much more complicated than shown here. I will
> leave to other more competent people to express and explore them.
>
> Yet, to me these aspects are not relevant. Subjectively speaking, in fact,
> both rdf-star and HESTER appear pretty much similar to each other with
> regard to my needs and desiderata.
>
> Let me give you a few items for comparison of what matters to me (I
> include my own proposal, called conjectures, just for fun) [In the
> following you may want to use a monospaced font to align checks to their
> respective columns]:
>
>                                                rdf-star      HESTER
>  conjectures
> published                                         x
> existing                                          x
>       x
> works for triples                                 x             x
> works for named graphs
>        x
> has compact syntax for datasets                   x             ?
>       x
> has compact syntax for queries                    x             ?
>       x
> expresses without asserting quoted structures     x             x
>       x
> quoted structures as S or O of triples            x             x
>       x
> quoted structures as self-sustaining structures                 x
>       x
> semantics entirely based on RDF 1.1               ?             x
>       x
> allows qualifications to quoted structures        x             x
>       x
> ... in particular, temporal qualifications        x             x
>       x
> allows annotated structures (quoted and asserted) x             ?
>       x
> annotated structures as first class entities                    ?
>       x
> allows quoting quoted structures                  x             ?
>       x
> allows quoting annotated structures                             ?
>       x
> allows cascading annotated structures                           ?
>       x
>
> My ideal solution, intuitively, would have a check in every row of the
> list, of course.
>
> To summarise, I actually do not faint at the idea of freshening up the
> traditional RDF reification with a new linearization and a usable query
> language. It might take time and it would end up being very similar to rdf
> star now, of course. Still, if HESTER could be designed to have a check in
> any of the above rows, I would switch immediately.
>
> Ciao
>
> Fabio
>
> > On 23 Jan 2022, at 17:44, Peter F. Patel-Schneider <
> pfpschneider@gmail.com> wrote:
> >
> > TL;DR: RDF-star has better syntax for representing temporal
> qualification than RDF does, and no other advantages.
> >
> > Hi Fabio:
> >
> > You appear to be arguing that the embedded triples of RDF provide a
> necessary advance, elminating the need for extra triples, ad-hoc entities,
> and extra connections.  I think this claim quickly falls apart.
> >
> >
> > One way to disprove this claim is by looking at a comparison with how to
> represent RDF-star examples in RDF itself.
> >
> > Let's look at the temporal qualifier example.  Attaching temporal
> qualifiers to triples can be done in RDF itself, using only a few new
> properties.  If we want to say that "Barack Obama was the US president
> between 2009 and 2016" we can use properties already part of RDF for the
> purpose.
> >
> > :BOUP rdf:subject :Obama ; rdf:predicate :role; rdf:object :UsPresident ;
> >   :between [ :start "2009" ; end "2017" ] .
> >
> > Contrary to your claim, this is as good a way of representing the
> sentence as your RDF-star representation, repeated here
> >
> > << :Obama :role :UsPresident >> :between [ :start "2009"; :end "2017". ]
> .
> >
> > There is nothing in either RDF or RDF-star indicating that attaching
> properties to embedded triples is any different from attaching properties
> to RDF statements.  Everything in both cases boils down to the intended
> meaning of the properties.
> >
> >
> > Let's compare the RDF-star and the RDF representations.
> >
> > The only added properties are :between, :start, and :end.  No advantage
> either way.
> >
> > The only added entity in the RDF is a non-blank entity, corresponding to
> the RDF-star embedded triple.  No advantage either way.
> >
> > The only added connections to the original subject, predicate, and
> object in RDF are analogous to the conections made in RDF-star.  No
> advantage either way.
> >
> > The there are only three more triples in RDF over the RDF-star
> approach.  But the embedded triple in RDF-star has these connections as
> well and they are a new, different kind of connection.  If there is any
> advantage here it is for RDF.
> >
> > The RDF-star syntax is somewhat better, particularly if the embedded
> triple is also asserted.  Advantage RDF-star.
> >
> > The RDF-star uses embedded triples.  Advantage RDF.
> >
> > It may appear that implementations of RDF-star will be more efficient
> than implementations of RDF when reasoning and querying this kind of
> information.  Of course, implementations of RDF-star have of necessity
> implementations of embedded triples, which is an extra implementation
> cost.  Implementations of RDF don't have this extra cost, but could be
> optimized if desired.  The advantage here does not lie with RDF-star.
> >
> >
> > My conclusion is that the gains from RDF-star certainly don't push
> RDF-star into something that is needed.   If there is a desire for better
> syntax then add a new shorthand to Turtle, don't satisfy this desire by
> adding an entirely new kind of entity to RDF.
> >
> >
> > peter
> >
> > PS:  Note that I am not arguing that this is a good way to represent
> temporal qualifiers.  I am just arguing that RDF is just as good RDF-star
> for adding temporal qualifiers.  I actually think that this is a bad,
> albeit common, way to represent temporal information.
> >
> > PPS:  If we wanted to be more explicit about the representation we could
> create subclasses of rdf:Statement for cases where we want to talk about a
> proposition and cases where we want to talk about stating a proposition.
> This allows RDF to be more flexible than RDF-star.  Advantage RDF.
> >
> > On 1/23/22 10:11, Fabio Vitali wrote:
> >
> >> Dear Peter,
> >>
> >>>>> Third, RDF-star has its own gotchas. The most discussed recently
> being the "multiple occurrences" problem (Liz and Richard marriages,
> Cleveland's presidencies), so you would still need to add the "additional
> node", even when using RDF-star...
> >>>> Yes. I agree.
> >>>>
> >>>> But this problem is not shared by named graphs, and this is why we
> need a rdf-star-like structure to handle complex and compound statements,
> an rdf-star-named-graph or something.
> >>>>
> >>> I'm not convinced at all by this argument that there is a need for
> rdf-star here.   Why not just use RDF reification?  Or a good temporal
> logic?  What is it about rdf-star that makes it needed here?
> >> I do not know about other people's opinions in this regard, but I am
> happy give you my own point of view.
> >>
> >> Besides a compact syntax, the real advantage of rdf-star from my point
> of view is that it gives us:
> >>
> >> 1) a mechanism to assign annotations to a statement, including temporal
> constraints,
> >> 2) without adding many triples, and
> >> 3) without adding ad-hoc entities (blank nodes, instances of some
> abstract classes or what have you), and
> >> 4) without changing roles and constraints to the original subject,
> predicate and object.
> >>
> >> The interesting part is that temporal annotations are expressible in a
> totally similar way to any other type of annotation, such as location,
> provenance, confidence, etc.
> >>
> >> For instance, assuming a common model to express a time interval, with
> rdf-star the sentence "Barack Obama was the US president between 2009 and
> 2016" can be expressed simply as
> >>
> >> << :Obama :role :UsPresident >> :between [ :start "2009"; :end "2017".
> ] .
> >>
> >> Without rdf-star, we would need to use an abstract concept, e.g., :Term
> in case on n-ary relations, or rdf:Statement in case of traditional
> reification, regardless of whether it was already expected in our mental
> ontology, and attach properties to the new entity. Thus:
> >>
> >> _:t a :Term;
> >>     :appliesTo :Obama;
> >>     :role  :UsPresident;
> >>     :between [
> >>        :start "2009";
> >>        :end "2017".
> >>     ].
> >>
> >> The new entity of type :Term radically changes the graph, which in my
> mind should be read as something like "Barack Obama had a Term as US
> President between 2009 and 2016", which is similar but not the same
> statement as the first one.
> >>
> >> _:b a rdf:Statement;
> >>     rdf:Subject :Obama;
> >>     rdf:Predicate :role;
> >>     rdf:Object  :UsPresident;
> >>     :between [
> >>        :start "2009";
> >>        :end "2017".
> >>     ].
> >>
> >> This in my mind should be read as something like "Somebody is saying
> that Barack Obama was engaged in the relation "role" with the entity
> "USPresident" between 2009 and 2016", which is still not the same statement
> as the first one.
> >>
> >> Also, in both cases there are three or four more triples and entities
> than with the rdf-star syntax.
> >>
> >> Just my opinion
> >>
> >> Thanks for reading,
> >>
> >> Fabio
> >>
> >>> peter
> >>>
> >>>
> >>>
>
>
>