Re: Consolidating triple/edges

On Mon, 2023-12-18 at 00:09 +0100, Thomas Lörtsch wrote:
> On 15. Dec 2023, at 15:33, Olaf Hartig <olaf.hartig@liu.se> wrote:
> > On Fri, 2023-12-15 at 13:57 +0100, Thomas Lörtsch wrote:
> > > > On 15. Dec 2023, at 00:01, Olaf Hartig <olaf.hartig@liu.se>
> > > > wrote:
> > > > [...]
> > > > If so, what would you expect to happen if someone writes the
> > > > following?
> > > >
> > > >   :T rdfx:typeOf << :s1 :p1 :o1 >> .
> > > >   :T rdfx:typeOf << :s2 :p2 :o2 >> .
> > > >
> > > > Which triple type would :T denote in this case (if any)?
> > >
> > > In the strictly monotonic world of RDF :T would then probably
> > > refer
> > > to a little graph term.
> >
> > I don't think this works, but I also think there is no point going
> > further into this discussion for now.
>
> Not attempting to force a discussion on you, but
>
>     :X a :House, :Bird .
>
> is perfectly legal RDF. RDF is not especially safe.

Okay, I backtrack. It certainly depends on how you define the semantics
of rdfx:typeOf.

Based on how you introduced it, I was assuming that the meaning you
have in mind for it is to state that the subject of an rdfx:typeOf
triple (i.e., :T in the examples) is "a reference to the [triple] type"
captured by the triple term in the object position of the triple. Based
on this meaning, I see the two lines above as an inconsistency.

With your statement above (":T would then probably refer to a little
graph term") you are implying a different meaning of rdfx:typeOf; being
a reference to a triple term/type and being a reference to graph term
are different thing (at least, I see it that way). Moreover, if an
rdfx:typeOf triple is meant to state that the subject of this triple is
a reference to a graph term, then I would expect the object of this
triple to be that graph term (as a whole), rather than just one of the
triples that is part of the graph term.

> [...]
> > > > In other words, should the two occurances of the
> > > > subexpression  << :s :p :o >>  in the following two lines be
> > > > understood to "implicitly reference" the same token or two
> > > > different tokens?
> > > >
> > > >   << :s :p :o >> :p2 :o2 .
> > > >   << :s :p :o >> :p3 :o3 .
> > >
> > > Always a different one, and that’s indeed crucial (I pointed that
> > > out in the nested graph proposal too).
> >
> > In this case, I cannot see how it would be possible to make more
> > than one annotation statement for each token? (If you attempt to
> > answer this question based on an example, please write the example
> > either in terms of the abstract syntax or the N-Triple-star format,
> > but not in Turtle-star.)
>
> I was sloppy in this example, but I seem to remember that in the
> context of the whole mail it might have been clearer. The idea was
> (and is) that providing no identifier makes is interpreted as "i
> don’t care about the name of this) and a blank node identifier is
> created. That motivates the need to define a way to refer to the type
> (above). I just realize the type reference, given in the syntax
> above, could then be interpreted as denoting a type of occurrence -
> that would have to be explained away…
>
>     << :s :p :o >> :p2 :o2 .
>     << :s :p :o >> :p3 :o3 ;
>                    :p4 :o4         # multiple annotations only as
> trees
>                                    # if no explicit ID is provided
>
> is then the same as
>
>     << _:b1 | :s :p :o >> :p2 :o2 .
>     << _:b2 | :s :p :o >> :p3 :o3 ;
>                           :p4 :o4 .

No, I would not say that these are the same. In contrast, the first of
these two snippets of Turtle is the same as the following.

   << :s :p :o >> :p2 :o2 .
   << :s :p :o >> :p3 :o3 .
   << :s :p :o >> :p4 :o4 .

Best,
Olaf


> N-Triples-star might look like this:
>
>     _:b1 rdfx:occurrenceOf << <http://example/s> <http://example/p> <
> http://example/o> >>.
>     _:b2 rdfx:occurrenceOf << <http://example/s> <http://example/p> <
> http://example/o> >>
>     _:b1 <http://example/p2> <http://example/o2> .
>     _:b2 <http://example/p3> <http://example/03> .
>     _:b2 <http://example/p4> <http://example/04> .
>
>
> Best,
> Thomas
>
>
> > Thanks,
> > Olaf
> >
> > > The preference for types in the semantics of RDF might be
> > > characterized as early optimization: understandable for an
> > > integration focused technology, and well understood in logic.
> > > However, the unification of tokens into types risks losing
> > > context
> > > (and annotations). It can just as well be postponed to querying
> > > (DISTINCT) or to a concious data management operation (spring
> > > cleaning in the dataset). The one thing that one doesn’t want to
> > > lose
> > > when working with data is … data. So late unification of tokens
> > > into
> > > types has some merit.
> > >
> > > Best,
> > > Thomas
> > >
> > >
> > >
> > > > Thanks,
> > > > Olaf
> > > >
> > > >
> > > > > and may either provide a custom name or will be provided with
> > > > > a
> > > > > new blank node to name the reference.
> > > > >
> > > > >
> > > > > ## Syntax
> > > > >
> > > > > We should try to make the naming syntactically as uniform and
> > > > > predicatble as possible. The nested graph proposal uses a
> > > > > pair of
> > > > > square brackets [] prepending constructs to indicate the
> > > > > name. If
> > > > > a custom name is given it is entered into that pair. That
> > > > > violates the rules for [] in Turtle/TriG but seems to parse
> > > > > unambiguously.  Not providing any name syntactically and
> > > > > still
> > > > > assuming the presence of a blank node name is a bit more
> > > > > tricky.
> > > > >
> > > > >    :liz :spouse :dick [id:1]{| :start 1964; :end 1974 |} .
> > > > >    :liz :spouse :dick {| :start 1975; :end 1976 |} .       #
> > > > > _:id2
> > > > >
> > > > >    [] << :s :p :o >> :start 1964 ; :end 1974 .
> > > > >
> > > > > In any case: if it doesn’t parse without a prepended name,
> > > > > then
> > > > > prepend a [].
> > > > >
> > > > >
> > > > > ## Unasserted vs Asserted
> > > > >
> > > > > Why not define a property that not only references a token,
> > > > > but
> > > > > also creates the triple, e.g.:
> > > > >
> > > > >   :liz :spouse :dick [id:1]{| :start 1964; :end 1974 |} .
> > > > >
> > > > > mapping to
> > > > >
> > > > >    id:1 rdfx:assertionOf << :liz :spouse :dick >>
> > > > >        :start 1964; :end 1974 .
> > > > >
> > > > > instead of
> > > > >
> > > > >    id:1 rdfx:occurrenceOf << :liz :spouse :dick >>
> > > > >        :start 1964; :end 1974 .
> > > > >    :liz :spouse :dick .
> > > > >
> > > > > That way we get identifiers for each triple occurrence
> > > > > together
> > > > > with the triple being asserted - direct identification, not
> > > > > earyl
> > > > > optimization. See above why that is important.
> > > > >
> > > > > All this unasserted business may seem a bit eccentric, but
> > > > > it’s
> > > > > the key to any sort of configurable semantics like quotation
> > > > > etc.
> > > > > It therefore has huge potential - if done right.
> > > > >
> > > > >
> > > > > ## SPARQL sugar
> > > > >
> > > > > You compare the occurence-based shortcut relation to
> > > > > syntactic
> > > > > sugar for RDF lists, which is fine, except that querying
> > > > > those
> > > > > lists is a hardship. Same for RDF/XML’s syntactic support for
> > > > > RDF
> > > > > standard reification. Any kind of RDF syntactic sugar also
> > > > > needs
> > > > > proper support in SPARQL to be effective in practice.
> > > > >
> > > > >
> > > > > ## Triple terms vs Graph terms
> > > > >
> > > > > Just for completeness: all for this can easily be expanded to
> > > > > graph terms. The syntax
> > > > >
> > > > >    []{ :s :p :o. :u :v :w }
> > > > >
> > > > > is explored in the nested graph proposal.
> > > > >
> > > > >
> > > > > ## Graph Terms vs Named Graphs
> > > > >
> > > > > I like Adrians example [0] of a complicated named graph based
> > > > > application and I’m taking that serious. However it should
> > > > > also
> > > > > be clear that triple/graph terms in the end are always stored
> > > > > in
> > > > > a way very similar to named graphs. There is just no other
> > > > > way in
> > > > > a quad based system. Triple/graph terms can be represented as
> > > > > named graphs, named graphs can be represented as graph terms.
> > > > > It’s a practical question of how to encode
> > > > > belonging/membership:
> > > > > syntactically as nested graphs, via a new term type as in
> > > > > RDF-
> > > > > star that transforms a triple into a term at the surface (but
> > > > > NOT
> > > > > in the underlying storage layer, for obvious performance
> > > > > reasons), via explicit binding relations as Niklas proposes
> > > > > [1]
> > > > > (and as Dydra implements nested graphs), etc. The main
> > > > > question
> > > > > is how to ensure that those binding relations don’t get lost
> > > > > in
> > > > > the process, but that IMHO is true for any solution. Nested
> > > > > graphs can be serialized to graph terms, which are just an
> > > > > extension of triple terms. That requires an additional en/de-
> > > > > coding step to fit them into an environment that reserves
> > > > > named
> > > > > graphs to its own purposes. That extra step is the price that
> > > > > those applications have to pay for being so particular about
> > > > > their use of named graphs. That’s only fair, and probably
> > > > > still
> > > > > economical for them.
> > > > >
> > > > >
> > > > > ## Term types vs Datatypes
> > > > >
> > > > > The most fundamental grievance with RDF-star is the
> > > > > introduction
> > > > > of a new term type when a new datatype of type RDF/TTL would
> > > > > suffice. All I proposed above is readily imlpementable in the
> > > > > nested graph proposal, which does map to TriG and regular N-
> > > > > quads
> > > > > and such a datatype (and even Turtle and N-triples, but
> > > > > that’s
> > > > > another discussion).
> > > > >
> > > > >
> > > > > Best,
> > > > > Thomas
> > > > >
> > > > >
> > > > >
> > > > > [0]
> > > > > https://lists.w3.org/Archives/Public/public-rdf-star-wg/2023Dec/0019.html

> > > > > [1]
> > > > > https://lists.w3.org/Archives/Public/public-rdf-star-wg/2023Nov/0032.html

> > > > >
> > > > >
> > > > > >   Andy
> > > > > >
> > > > > > [1]
> > > > > > https://lists.w3.org/Archives/Public/public-rdf-star-wg/2023Dec/0024.html

> > > > > >
> > > > > > [2]
> > > > > > https://w3c.github.io/rdf-concepts/spec/#section-triples

> > > > > >   (as of 2023-12-10)
> > > > > >

Received on Monday, 18 December 2023 14:34:06 UTC