- From: Miel Vander Sande <miel.vandersande@meemoo.be>
- Date: Thu, 16 May 2024 10:52:14 +0200
- To: Thomas Lörtsch <tl@rat.io>
- Cc: RDF-star Working Group <public-rdf-star-wg@w3.org>, "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
- Message-ID: <CAHeRLWu1riJzSmeWJwac6HOzuvM6Ejo1jZCTAxmSm-g6SvBH3g@mail.gmail.com>
Hi Thomas,
Check, understood! So the mapping is mostly for legacy systems. Are stores
that implement RDF-star expected to interpret these standard RDF documents
as RDF-star semantics?
Best,
Miel
On Thu, 16 May 2024, 10:01 Thomas Lörtsch, <tl@rat.io> wrote:
> Hi Miel,
>
> this proposal is based on RDF-star triple terms. Its semantics and the
> mapping to standard RDF however are based on the Singleton Properties
> proposal. So the problems with efficiency of Singleton Properties don’t
> occur if a store implements RDF-star triple terms. That’s explained in more
> detail in the proposal, but I understand that this can be overlooked at
> first reading because it’s a long mail. Maybe check the section titled CORE
> again.
>
> Best,
> Thomas
>
>
> > On 16. May 2024, at 09:19, Miel Vander Sande <miel.vandersande@meemoo.be>
> wrote:
> >
> > Hi Thomas,
> >
> > Thanks for the proposal, but I'm missing something important. The main
> concern about singleton properties is the way Triple Stores can efficiently
> handle them. They often rely on a low number of unique predicates. If
> compatibility/mapping with standard RDF is kept, would that not make it
> hard or impossible for triple stores to optimise these singleton
> properties? And if singleton properties are somehow treated differently,
> are they not the same as a statement identifier that is independent from
> the predicate (as proposed by some of the other proposals)?
> >
> > How would you position your proposal wrt this? Al least for me,
> expressiveness is useless if it can be queried or retrieved within
> reasonable time.
> >
> > Cheers,
> >
> > Miel
> >
> >
> >
> >
> > On Wed, 15 May 2024, 14:32 Thomas Lörtsch, <tl@rat.io> wrote:
> > YET ANOTHER GRAND UNIFYING PROPOSAL
> > ===================================
> >
> > What appeared as the way forward last winter is getting more and more
> convoluted as the details are discussed. I agree with Niklas that this is a
> result of the choice for Option 3, but it also is sign of a deeper problem:
> we might still don’t work with the right primitives and still don’t have a
> solid understanding of the problem we’re dealing with. I’m well aware that
> everybody is tired and wants to be done with all this, but it seems to me
> that we should change course, again. I’ll discuss some background first,
> but then make a pretty concrete proposal of how to attack the problem by
> combining the syntax of RDF-star with the semantics of singleton
> properties. IMHO it has some very concrete advantages: less triples, less
> confusing indirections, and more intuitive semantics.
> >
> >
> > BACKGROUND
> > ==========
> >
> > I see two main use cases for statement annotation:
> >
> > - n-ary relations
> > with a primary topic and secondary, qualifying attributes
> > -> that can be interpreted as INSTANTIATION
> >
> > - metadata annotations
> > that are orthogonal to the topic of the statement
> > -> that can be interpreted as REIFICATION
> >
> > The metadata use case (quite often characterized as provenance) is
> strong in RDF land with its focus on integration of data from heterogeneous
> sources. In LPG land much more emphasis is put on structuring the graph
> into easy to navigate main relations and their less important details (and
> attributed objects, but that’s another topic). Of course that is just a
> very rough characterization, and overlaps in both directions are common.
> >
> > The metadata use case is well captured by REIFICATION because
> reification stays clear of the annotated statement itself (lets keep in
> mind that reification is a general concept and don’t associate it with the
> syntactic verbosity its implementation in RDF for a moment). There is an
> air gap between the statement and its reification that ensures that the
> original statement is unencumbered and unchanged by the annotation. This is
> good for the metadata use case but it is not easy to understand as recent
> mail exchanges on the list between Olaf, Niklas, Bryan and Peter have shown
> (again) and the indirection can cause irritating and unfortunate effects.
> >
> > In an n-ary relation the main relation can be understood as an
> INSTANTIATION of the type of relation it represents, with each instance
> having its own secondary attributes as qualifications. Instantiation is a
> concept that is well understood and maps nicely to everyday
> conceptualizations like "a car" (engine, four wheels, etc) and "my car"
> (again engine, four wheels, etc, but also a sedan, blue, old, etc).
> Instantiation is what drives the semantics of the singleton property
> approach.
> >
> > Of course, the distinction is more one of tendencies than of a hard
> separation: reification can represent n-ary relations and instantiation via
> n-ary relations can represent metadata, one person’s data is another
> person’s metadata, etc. However, in both cases that comes at a certain cost
> in intuitiveness and naturalness. If used wrongly, subtle breaks can be
> introduced that may lead to surprising and undesirable results.
> >
> > The problem with the singleton property approach as proposed by Nguyen
> et al is that it tries to achieve its goal without a change to the syntax
> of RDF. It lacks the boldness of RDF-star to introduce a new term type into
> RDF. This makes it verbose, hard to optimize and requiring to entail the
> primary relation as if it was an additional detail, an afterthought even.
> On the other hand RDF-star was intially a syntax without a well-defined
> semantics, or model theory even, and this WG still struggles to make it all
> work out. This here is an attempt to re-use the singleton property
> approach as the semantic underpinning of the RDF-star syntax, or, put the
> other way, to augment the singleton property approach with the RDF-star
> syntax, thereby getting rid of its verbosity. So let’s get to it.
> >
> >
> > CORE
> > ====
> >
> > 1) a return to RDR and pre-CG RDF*: EACH TRIPLE TERM IS ASSERTED, e.g.
> >
> > << :s :p :o >> :b :c .
> >
> > asserts ' :s :p :o ' and annotates it in one go. This gets rid of the
> need for an annotation/shorthand syntax and it safes an extra triple to
> actually assert the assertion. It captures the predominant intuition:
> saying something and adding detail to it. At this point it doesn’t matter
> much if that detail is metadata or qualifying detail. What matters is that
> both are solidly connected, not separated (and prone to mixups and
> misunderstandings through overlapping multi-edge situations).
> > A query for { :s :p :o } in SPARQL-star on the above example must
> retrieve the statement ':s :p :o' from the triple term << :s :p :o >>, etc
> - "Turtle with holes".
> > This means that in common scenarios there is zero overhead because of
> singleton property verbosity and entailments, unasserted assertions, etc.
> The main use case is very straightforward to use (and implement, I reckon).
> >
> >
> > 2) the RDR/RDF* proposal is extended with TRIPLE TERM IDENTIFIERS not
> unlike the current WG proposal, but with a twist: user-provided identifiers
> are handled differently (more on that below). Just as in the current WG
> proposal a bnode identifier is provided by the system for every triple
> term, e.g. the above '<< :s :p :o >> :b :c .' is equivalent to
> >
> > << _:p1 | :s :p :o >> :b :c .
> >
> > The triple term is now a QUAD-TUPLE: the identifier becomes part of the
> triple term also in model and abstract syntax, getting rid of the abstract
> triple term type (the thing syntactically expressed as '<<( :s :p :o )>>'
> in the current proposal - however, we will reuse that syntax, see below).
> This identifier is equivalent to the singleton property itself in the
> approach so named.
> > The statement identifier, refering to an instance/occurrence of the
> abstract statement, is essential to capture the semantics of most use
> cases, not the least LPG uses, where statements (or edges in LPG) of the
> same type can occur multiple times, each with different and not to be mixed
> up sets of annotations.
> >
> > The current WG proposal offers to users the possibility to explicitly
> define an IRI en lieu of but semantically equivalent to the system provided
> bnode, e.g.
> >
> > << :x | :s :p :o >> :b :c .
> >
> > Its purpose is to work around the limitations of line-based
> serializations. We do this too, but in a different way (that’s the TWIST
> hinted at above): an explicitly provided identifier is stored separately
> from and additionally to the system provided bnode. The quad therefore
> conceptually becomes a QUIN-TUPLE - however, stores may choose to just
> store the explicit identifier via an extra statement, like in the mapping
> discussed next. The rationale behind this arrangement will become apparent
> below when we discuss many-to-many relations, sets and graphs.
> >
> >
> > 3) a MAPPING to standard RDF is based on the singleton property
> approach, e.g.
> >
> > :s :p :o .
> > :s _:p1 :o .
> > _:p1 rdf12:singletonOf :p ; # _:p1 is a singleton property of _:p
> > rdf12:id :x ; # :x is a user-provided identifier
> refering to _:p1
> > :b :c .
> >
> > This should work well through the whole installed base and stack of
> RDF/RDFS/OWL/etc, at least in principle (issues e.g. with missing predicate
> indexes notwithstanding). [0] have found that singleton properties have
> quite favorable properties w.r.t. reasoning (and even more so if, in
> contrast to those authors, one interprets singleton annotations not as
> constraints but as additional detail).
> >
> >
> > I claim that so far all this is pretty straightforward and covers the
> vast majority of real world usage. It is cleaner and more concise than the
> current proposal in that it doesn’t separate assertion from annotation, it
> saves that extra un-asserted triple in storage and it makes the shorthand
> annotation syntax superfluous.
> >
> >
> > Some details are important to understand:
> >
> > - rdf12:singletonOf rdfs:subPropertyOf rdf:type .
> > This reflects the intuition that each singleton is unique, an intuition
> that is better expressed as instantiation than as subclassing.
> >
> > - the verbosity and optimization troubles of singelton properties, as
> evidenced in the mapping, only occur in environments that don’t support
> RDF-star triple terms (otherwise what would we need RDF-star for ;-).
> >
> > - the mapping loses the strong connection between a statement and its
> annotation. Just as with the current WG proposal it is possible to have the
> same statement asserted and, e.g. after merging a different source,
> annotated but assumedly un-asserted. The latter information will get lost,
> making the whole concept of un-asserted assertions brittle and unreliable.
> The current WG proposal always has this problem, this proposal here only
> when mapping to standard RDF.
> >
> > - the main difference between our proposal and the singleton property
> approach is that we reverse access: we put the un-annotated statement in
> the foreground (by means of the triple term syntax), both in the user
> facing syntax and at the implementation level, whereas in the singleton
> property approach it has to be entailed from the annotated singleton
> statement. This makes our proposal much more straightforward to use and
> implement.
> >
> >
> >
> > EXTENSIONS
> > ==========
> >
> > The current WG proposal tries to cover more ground than just statement
> annotation, most notably annotating un-asserted assertions, but also other
> stuff that depending on perspecticve seems like low-hanging fruit,
> especially annotating sets of statements and referentially opaque statement
> annotations. We argue that those are orthogonal demands and should be
> implemented in a way that doesn’t complicate the above very simple basic
> arrangement. It seems however that it is possible to achieve this with
> modest effort.
> >
> >
> > UNASSERTED ASSERTIONS
> >
> > We re-use the syntax of abstract triple terms from the current WG
> proposal to encode unasserted assertions, as the concept of abstract triple
> terms is obsolete in our approach. Like triple terms they are four-tuples,
> i.e. they always have an identifier implicitly provided by the system as a
> bnode. As the use case is rather niche we consider the introduction of an
> unasserted assertion in model and abstarct syntax overkill, but instead
> advocate to implement the syntax as syntactic sugar for standard
> reification, e.g.
> >
> > <<( :s :p :o )>> :b :c .
> >
> > in standard RDF maps to standard reification:
> >
> > _:p2 rdf:type :rdf:Statement ;
> > rdf:subject :s ;
> > rdf:predicate :p ;
> > rdf:object :o ;
> > :b :c .
> >
> > The same for explicitly named un-asserted assertions like e.g. '<<( :x |
> :s :p :o )>> :b :c .'
> >
> > _:p2 rdf:type :rdf:Statement ;
> > rdf:subject :s ;
> > rdf:predicate :p ;
> > rdf:object :o ;
> > rdf12:id :x ;
> > :b :c .
> >
> >
> > REFERENTIAL OPACITY
> >
> > Referential opacity has come up again lately and although I’m pretty
> wary of the concept I can see a way in which its introduction will probably
> not harm RDF in general. Most of all I like to see it as an orthogonal
> concern that should not be entagled with annotations or un-asserted
> assertions as such. Therefore I take up the idea of introducing yet another
> syntax (by Enrico IIRC, in a recent telco), e.g.
> >
> > <<" :s :p :o ">> :b :c .
> >
> > Again this may be implemented as a new term type in model and abstract
> syntax, or we may follow Antoine Zimmermanns proposal for an RDF literal
> datatype. The latter can be employed to define referential opacity as
> syntactic sugar and map to standard RDF maps as follows:
> >
> > :s :p :o .
> > :s _:p3 :o .
> > _:p3 rdf12:singletonOf :p ;
> > :b :c ;
> > rdf12:ofArtefact ":s :p :o"^^rdf:ttl .
> >
> > The RDF literal datatype documents precisely the syntactic
> representation of the statement. This is a very un-intrusive approach to
> referential opacity and IMHO won’t get in the way of standard RDF
> procedures. Of course it doesn’t prevent undesirable entailments from being
> made, as the approach to referential opacity taken by the CG proposal does,
> but at least it allows to track them back to the original source and treat
> them accordingly. Bnodes might either not be handled or be covered more
> fully than in teh CG report proposal by allowing artefacts to be concise
> bounded descriptions. E.g. an artefact ":s :p _:b1 . _:b1 :d :e , :f
> ."^^rdf:ttl would give a full account of the meaning of _:b1 at the time
> the artefact was created.
> >
> >
> > REFERENTIALLY OPAQUE UNASSERTED ASSERTIONS
> >
> > Again, referential opacity and unasserted assertions are orthogonal
> concerns, and therefore yet another syntax is introduced to combine the
> two, e.g.
> >
> > <<(" :s :p :o ")>> :b :c .
> >
> > Following the above proposals this is mapped to standard RDF by adding
> the literal representation to the reification quad, e.g.
> >
> > _:p4 rdf:type :rdf:Statement ;
> > rdf:subject :s ;
> > rdf:predicate :p ;
> > rdf:object :o ;
> > rdf12:hasArtefact ":s :p :o"^^rdf:ttl ;
> > :b :c .
> >
> > Considering the mindboggling level of disambiguation that this
> arrangement provides the complexity isn’t too bad IMHO ;-)
> >
> >
> > MANY-TO-MANY, SETS, GRAPHS
> >
> > Like the current WG proposal this approach doesn’t rule out many-to-many
> relations, e.g.
> >
> > << :x | :s :p :o >> :b :c .
> > << :x | :u :v :w >> :b :c .
> >
> > We might even consider to introduce a supporting syntax, aka GRAPH
> TERMS, e.g.
> >
> >
> > << :s :p :o .
> > :u :v :w >> :b :c .
> >
> > or, explicitly named
> >
> > << :x | :s :p :o .
> > :u :v :w >> :b :c .
> >
> > I don’t want to push the envelope too far (given the constraints imposed
> by the charter, the controverses around the topic, etc) but it’s good to
> see that this is syntactically straightforward - it isn’t with the
> shorthand annotation syntax of the WG proposal.
> >
> > Anyway, employing the mapping to standard RDF from CORE above, we get a
> straightforward definition of the meaning of many-to-many annotations (no
> matter if they come as singleton terms or as hypothetical graph terms),
> e.g. mapping the above many-to-many relation to
> >
> > :s :p :o .
> > :u :v :w .
> > :s _:p5 :o .
> > _:p5 rdf12:singletonOf :p ;
> > rdf12:id :x ;
> > :b :c .
> > :u _:v1 :w .
> > _:v1 rdf12:singletonOf :v ;
> > rdf12:id :x ;
> > :b :c .
> >
> > This establishes a FOR-EACH semantics: annotations of the graph term are
> annotating each triple, not the graph (or set of triples if one prefers
> that slightly looser wording) itself. The same is true for annpotations on
> :x: they too are mapped to all statements so named, e.g.
> >
> > << :x | :s :p :o .
> > :u :v :w >> :b :c .
> > :x :d :e .
> >
> > is mapped to
> >
> > :s :p :o .
> > :u :v :w .
> > :s _:p5 :o .
> > _:p5 rdf12:singletonOf :p ;
> > rdf12:id :x ;
> > :b :c ;
> > :d :e .
> > :u _:v1 :w .
> > _:v1 rdf12:singletonOf :v ;
> > rdf12:id :x ;
> > :b :c ;
> > :d :e .
> >
> >
> > To annotate the set of triples itself one would have to create an
> explicit reference via the identifier :x, e.g.
> >
> > :x rdf12:asObject [ # or "rdf12:asGraph", "rdf12:asSet" ...
> > :f :g
> > ] .
> >
> > A possible use case might be to express that a set of statements
> together describe a situation, postulate a theory, etc.
> > This arrangement can also be used to annotate singleton statements as
> objects of there own right (not as annotations to the predicate).
> Semantically this is probably closer to reification than to n-ary
> relations, but I’m not really sure myself what to make of it. In any case
> it is more expressive than the current WG proposal which provides no means
> to differentiate between the object and its content (httpRange-14 raising
> its ugly head again, I guess)
> >
> >
> > However, this arrangement has repercussions on the interpretation of
> annotations on :x (or _:x) in x-to-one cases, i.e. when single statements
> are annotated, because it can only mean that also those annotations refer
> to the statement as a whole, not its n-ary property. This is a departure
> from the current state which leaves this question open - and sure to cause
> some irritation.
> >
> >
> > TBC… I’m leaving it at this for reasons of time, but also to solicit
> some general comments. The details most certainly need some more tweaking,
> as so far all proposals did. The means to explicitly name an occurrence
> were introduced to overcome the limitations of serialization, but they do
> open the door to many-to-many relations, and that comes in handy when
> discussing sets and graphs. However it mixes orthogonal concerns, so may
> have unintended consequences. I expect this arrangement to be
> controversial, and maybe buggy. Comments welcome!
> >
> > Best,
> > Thomas
> >
> > [0] https://link.springer.com/chapter/10.1007/978-3-319-58068-5_39
> >
> >
> > > On 2. May 2024, at 16:00, Peter F. Patel-Schneider <
> pfpschneider@gmail.com> wrote:
> > >
> > > The singleton property approach has benefits and downsides. The
> quoted triple approach has benefits and downsides.
> > >
> > > One very big advantage of the singleton property approach is that it
> is (barely) possible to use it with any RDF system, even RDF systems that
> have no optimizations. A big disadvantage of the quoted triple approach is
> that it requires new syntax, new semantics, and new implementations.
> > >
> > > One cannot successfully argue that just because the singleton property
> approach may require more triples that it is inherently worse than the
> quoted triple approach. RDF implementations can be tuned to the singleton
> property approach, providing special data structures for singleton
> properties and special code to optimize SPARQL queries for the singleton
> property approach.
> > >
> > > One possible way to do this is to use a special approach for singleton
> properties where the internal name of the blank node encodes the parent
> property. This could result in minimal or even no storage overhead for
> singleton properties. Of course the implementation effort to make this
> completely transparent would be significant, but then so is the effort to
> make a performative implementation of quoted triples.
> > >
> > > I note that in this approach the singleton property triples would look
> very much like multiple edges, i.e., this could be considered to be a
> space-efficient implementation of RDFn.
> > >
> > > peter
> > >
> > >
> > > On 4/30/24 15:46, Thompson, Bryan wrote:
> > >> Your proposal would require two statements on top of the original SPO
> statement before you should begin to make assertions about the original SPO
> statement?
> > >> Anything based on the singleton property approach will have quite an
> impact on database statistics. The number of used predicates would jump
> from millions (for open linked data) to the cardinality of the statements
> about which statements are being made (e.g., billions, 10s of billions,
> etc.). @Williams, Gregory <mailto:ngregwil@amazon.com> or @Schmidt,
> Michael <mailto:schmdtm@amazon.com> can comment on this, but this
> certainly places a new burden on common techniques for extracting
> statistics from a graph.
> > >> Note that there is really no reason to rely on the P position in your
> proposal. You could use S since it already allows blank nodes. You then
> hang the Subject of the original asserted SPO on the statement about that
> unique subject. (Or you could use O, which might be kinder for database
> statistics since they tend to focus on SP* analysis.)
> > >> _:si :statementInstanceHasSubject :s .
> > >> _:si :p :o .
> > >> :s :p :o.
> > >> I have been impressed in the past with the space and time overhead
> which arises out of various modeling decisions around possible statements
> about statements treatments. I would recommend carefully considering that
> impact. Another 2 triples makes a huge difference when all statements
> carry annotations, as they do in some domains. For example, consider the
> relatively common case in which you have a graph consisting of a topology
> and edge weights. This is very common - lots of graphs are simply edges
> and their weights. As I understand it, your proposal would have 3 times
> the data volume to model the topology (some set of edges) in a manner which
> would permit associating edge weights with the edges in that topology. And
> the database would need to chase a long chain to obtain those edge weights
> in a correct manner: :s :p :o. => :s _:pi :o => _:pi rdfs:subPropertyOf :p
> . => _:pi :hasWeight 1.0. The cost of chasing that chain would make
> applications relying on edge weights very expensive in both time and
> space. I can't see that as being responsive to such use cases. To be
> efficient, there needs to be a close association between an edge and the
> properties of that edge. Their resolution needs to be very efficient.
> > >> Also note that this singleton property proposal would not support
> alignment in the data (interoperability in the data) with LPG edge
> properties. So it would fail to offer a unification path for the common
> use cases of RDF and LPG.
> > >> Thanks,
> > >> Bryan
> > >>
> ------------------------------------------------------------------------------
> > >> *From:* Peter F. Patel-Schneider <pfpschneider@gmail.com>
> > >> *Sent:* Tuesday, April 30, 2024 10:40:18 AM
> > >> *To:* public-rdf-star-wg@w3.org
> > >> *Subject:* RE: [EXTERNAL] The singleton property option
> > >> CAUTION: This email originated from outside of the organization. Do
> not click links or open attachments unless you can confirm the sender and
> know the content is safe.
> > >> I think that this is far too strong. The singleton property
> approach has
> > >> problems, but not to this extent.
> > >> For any statement that does not require annotation, the singleton
> property
> > >> approach does not require any changes at all, i.e., just use
> > >> :s :p :o .
> > >> For a statement that does require annotation, the singleton property
> requires
> > >> two or three triples, one to make the blank node a subproperty of the
> desired
> > >> property, one to state the relationship using the blank node, and, if
> the RDF
> > >> system does not implement RDFS semantics, one to make the statement
> using the
> > >> regular property, i.e.,
> > >> _:pi rdfs:subPropertyOf :p .
> > >> :s _:pi :o .
> > >> :s :p :o.
> > >> The added storage for this might be less than that needed for
> efficient
> > >> processing of quoted triples, particularly if the third statement is
> not needed.
> > >> There is no need to change modelling if the statement is annotated
> after the fact.
> > >> peter
> > >> On 4/30/24 12:26, Thompson, Bryan wrote:
> > >>> The singleton property approach undermines the direct use of
> predicates in
> > >>> statements and forces a second hop for any use case to determine the
> actual
> > >>> predicate used. It also requires that the "statement" is modeled
> differently
> > >>> in advance, thus increasing the space requirements even if no
> statements about
> > >>> statements are used.
> > >>>
> > >>>
> > >>> This is not efficient.
> > >>>
> > >>>
> > >>> Effectively, the singleton property model says that the RDF triple
> is wrong.
> > >>> It says that you should model using (S ID O) and then model the
> predicate and
> > >>> other information as statements about that ID. This is not the RDF
> model.
> > >>>
> > >>>
> > >>> The approach with Statements about Statements should IMHO be built
> on (S P O
> > >>> ID). That is, there is a unique identifier for the SPO and you make
> > >>> statements about that statement ID.
> > >>>
> > >>>
> > >>> Bryan
> > >>>
> > >>>
> ------------------------------------------------------------------------------
> > >>> *From:* Thomas Lörtsch <tl@rat.io>
> > >>> *Sent:* Tuesday, April 30, 2024 12:02:21 AM
> > >>> *To:* public-rdf-star-wg@w3.org; Thompson, Bryan; Niklas Lindström;
> RDF-star
> > >>> Working Group
> > >>> *Subject:* RE: [EXTERNAL] The singleton property option
> > >>>
> > >>> *CAUTION*: This email originated from outside of the organization.
> Do not
> > >>> click links or open attachments unless you can confirm the sender
> and know the
> > >>> content is safe.
> > >>>
> > >>>
> > >>> Brian,
> > >>>
> > >>> Niklas combines the RDF-star syntax with the semantics of Singleton
> > >>> Properties. AFAIK no implementations of or papers on Singleton
> Properties have
> > >>> done that. This combination doesn't even require an index on
> properties.
> > >>>
> > >>> This combination is nearer to the original RDR approach than
> anything else
> > >>> discussed by CG and WG. It is IMO a very neat idea and deserves a
> closer look.
> > >>>
> > >>> Thomas
> > >>>
> > >>>
> > >>>
> > >>> Am 29. April 2024 19:06:37 MESZ schrieb "Thompson, Bryan" <
> bryant@amazon.com>:
> > >>>
> > >>> The singleton property approach has many downsides and is
> pragmatically
> > >>> unworkable. There is a good reason people are not happy with
> this approach.
> > >>>
> > >>>
> > >>> Bryan
> > >>>
> > >>>
> ------------------------------------------------------------------------------
> > >>> *From:* Niklas Lindström <lindstream@gmail.com>
> > >>> *Sent:* Friday, April 26, 2024 2:08:41 PM
> > >>> *To:* RDF-star Working Group
> > >>> *Subject:* [EXTERNAL] The singleton property option
> > >>> CAUTION: This email originated from outside of the
> organization. Do not
> > >>> click links or open attachments unless you can confirm the
> sender and know
> > >>> the content is safe.
> > >>>
> > >>>
> > >>>
> > >>> For completeness (and perhaps to widen the perspective), here
> is the
> > >>> singleton property option I briefly mentioned on the semantics
> call
> > >>> (and alluded to in [1]). Also see [2] for the original; this is
> just a
> > >>> quick strawman adaptation for the benefit of the LPG
> perspective.
> > >>>
> > >>> It extends RDF 1.1 differently; no triple terms, no opacity,
> just:
> > >>>
> > >>> 1. Allow bnodes as predicates (blank predicates).
> > >>> 2. Define rdf:singletonPropertyOf for linking those to the
> property
> > >>> they represent instances/occurrences/edges of.
> > >>>
> > >>> 3. Well-formedness conditions:
> > >>> 3.1 Bnode predicates are only to be used once; with one s and o
> > >>> (similar to list cons nodes, who are "single purposed").
> > >>> 3.2 The rdf:singletonPropertyOf is semantically functional
> (exactly
> > >>> like rdf:first and rdf:rest).
> > >>>
> > >>> 4. For optimization, implementations can put triples with blank
> > >>> predicates in a dedicated table (using edgename as unique key),
> > >>> relying on well-formedness for cohesion. Such a table is
> completed in
> > >>> two steps: 1) the singleton assertion inserts s and o for
> edgename; 2)
> > >>> the rdf:singletonPropertyOf assertion inserts p for edgename. If
> > >>> well-formedness is broken, all optimization bets are off.
> Perhaps a
> > >>> dedicated skolemization scheme can be employed for some more
> control
> > >>> and/or "unstarring".
> > >>>
> > >>> 5. RDF-star syntax obviously needs no naming syntax; naming
> these
> > >>> would break well-formedness.
> > >>> 6. What these *mean* of course needs a good definition (property
> > >>> specializations, edge type instances or similar). Are they
> asserted?
> > >>> Sure. Do they assert something using their
> rdf:singletonPropertyOf
> > >>> property as predicate? No. (Could they? Well, they can be
> declared
> > >>> ("inline") to *also* be subPropertyOf the same property, and
> through
> > >>> entailment that would happen.)
> > >>> 7. Reifiers become a usage pattern (informative) as suggested
> from the
> > >>> property edge perspective. Any desired :reifiedBy or :partOf
> relation
> > >>> can link predicate singletons to one or more "reifiers".
> > >>>
> > >>> Basic example:
> > >>>
> > >>> << :s :p :o >> :source <stream662be7ba> ;
> > >>> :timestampMills 1714153402 .
> > >>>
> > >>> Expands to:
> > >>>
> > >>> :s _:e1 :o .
> > >>> _:e1 rdf:singletonPropertyOf :p ;
> > >>> :source <stream662be7ba> ;
> > >>> :timestampMills 1714153402 .
> > >>>
> > >>> Annotation syntax:
> > >>>
> > >>> :s :p :o {| :reifiedBy <#reifier> |} .
> > >>>
> > >>> Expands to:
> > >>>
> > >>> :s :p :o .
> > >>> :s _:e1 :o .
> > >>> _:e1 rdf:singletonPropertyOf :p ;
> > >>> :reifiedBy <#reifier> .
> > >>>
> > >>> Possible singleton property entailment?:
> > >>>
> > >>> _:e1 a rdf:SingletonProperty;
> > >>> rdf:subject :s ;
> > >>> rdf:prediate :p ;
> > >>> rdf:object :o .
> > >>>
> > >>> Will entailment break well-formedness if (accidentally?) *put
> back*
> > >>> into a regular graph? Of course, just as RDF lists are "broken"
> > >>> whenever that happens (as in look terrible when serialized,
> make no
> > >>> sense when queried, etc.).
> > >>>
> > >>> Best regards,
> > >>> Niklas
> > >>>
> > >>> [1]:
> > >>> <
> https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Apr/0158.html
> > >>> <
> https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Apr/0158.html
> > >> <
> https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Apr/0158.html
> >>>
> > >>> [2]: <https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4350149/
> > >>> <https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4350149/
> > >> <https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4350149/>>>
> > >>>
> > >
> >
> >
>
>
Received on Thursday, 16 May 2024 08:52:32 UTC