- From: Kurt Cagle <kurt.cagle@gmail.com>
- Date: Thu, 23 May 2024 10:23:45 -0700
- 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: <CALm0LSGROvu_arz6cwhr21A+-EiSQbJ3w88yX8=5Ya3HO1f-9Q@mail.gmail.com>
I've attached a document that covers YET ANOTHER proposal (more properly a
recommendation I've made before).
There are two issues that we seem to be rehashing here. The first is the
question of reificational notation, while the second has to do with LPG
harmonization. My contention is that these are different issues, though we
can use similar notation for both.
*Reification*
A named reification is simply a set of statements:
:r rdf:subject :s; rdf:predicate :p; rdf:object :o .
This is not a triple. It is three statements about the state that a triple
can be in. It does not introduce a triple into the system,it makes no
assertions about the truthiness or even, by itself existence of that
triple. It is simply a statement about the components that a triple might
have. You cannot reason with it directly, though you can use other
processes (SPARQL, SHACL, etc.) to construct or verify the existence of
triples for which these assertions are true. Properly speaking, the above
itself should probably be qualified:
:r rdf:subject :s; rdf:predicate :p; rdf:object :o ; a rdf:Reification .
The notation << :r | :s :p :o >> makes the above statement more compact,
but the reification can apply to any triples within a system, or none at
all, regardless of the values.
*Named Node Expressions*
I propose, in the attached, that we use a similar nomenclature for what I'm
turning named node expressions, to whit:
[ ?nn | :p1 :o1 ; :p2 :o2 ]
where ?nn is replaced by a formal (not blank) IRI.
This is a Turtle (not RDF) syntactical amendment. The above takes what
would ordinarily be a blank node and replaces it with a named node:
For instance:
:liz :hasMarriage [ :marriage 1 | :to :Ricard, :start "1965" ; :end "1975"
].
which expands to:
:liz :hasMarriage :marriage 1 .
:marriage 1 :to :Richard .
:marriage 1 :start "1965" .
:marriage 1 :end "1975" .
Why is this important? Because the blank node is a pointer to a data
structure, but use of the [] notation makes it impossible to reference that
data structure from within Turtle. By adding in a named node as the
referencing node, you gain that ability, and it is a key ability for
modeling.
For instance, I can use the expression:
:liz :hasMarriage [ :marriage 1 | :start "1965" ; :end "1975"; :to :richard
], [ :marriage 2 | :start "1975" ; :end "1985"; :to :john].
This is semantically equivalent to the JSON
{"liz":{"hasMarriage":[{"marriage1":{"start":"1965",
"end":"1975","to":"richard"}},"marriage1":{"start":"1965",
"end":"1975","to":"richard"}}]}}
The same thing can be done with both predicate-positioned named node
expressions and subject-oriented ones.
This addresses the LPG equivalency relationship, and does so without ever
touching reifications.
Note that this also highlights an important point. Blank nodes are useful
because they are unique and system-assigned. However, they are not
referenceable. The Turtle notation:
:liz :hasMarriage _:b1, _:b2 .
_:b1 :start "1965" ; :end "1975"; :to :richard .
_:b2 :start "1975" ; :end "1985"; :to :john .
is simply a preprocessor directive to replace the "named" nodes with
anonymous IRIs in the final indexing. You still have to make _:b1 and _:b2
unique, or the data structures disintegrate.
Anyway, I ask the chair for time during our next meeting to discuss this
proposal.
*Kurt Cagle*
Editor in Chief
The Cagle Report
kurt.cagle@gmail.com
443-837-8725 <http://voice.google.com/calls?a=nc,%2B14438378725>
On Wed, May 15, 2024 at 5:32 AM 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/>>>
> >>>
> >
>
>
>
Attachments
- application/vnd.openxmlformats-officedocument.wordprocessingml.document attachment: Named_Node_Expressions_and_Reifier_Expressions.docx
Received on Thursday, 23 May 2024 17:24:18 UTC