W3C home > Mailing lists > Public > public-rdf-star@w3.org > January 2021

Re: New proposal for RDF* Semantics

From: Pierre-Antoine Champin <pierre-antoine.champin@ercim.eu>
Date: Wed, 13 Jan 2021 10:10:49 +0100
To: public-rdf-star@w3.org
Message-ID: <7f7d93b6-cd8b-e6b8-56f1-257bd6d439de@ercim.eu>
On 13/01/2021 09:05, Pierre-Antoine Champin wrote:
> But I generally agree with you that dragging blank nodes, not to 
> mention all of them, in the domain of discourse, is a bit 
> discomforting. I am not convinced yet that it causes a real problem, 
> but the simple fact that we are having this discussion hints that it 
> is not such a good idea...
> I still believe, however, that in order to provide some "rigidity" to 
> the interpretation of RDF* triples, we need to constrain somehow the 
> semantics of S*, P*, O* and I* (or whatever properties we use to 
> describe the internal structure of RDF* triples).

 From the conclusions above, I propose to amend the proposed definition 
of RDF* interpretation 
as follows:

* remove the constrain that IR must contain all RDF* terms

* in the specification of IEXT(S*), IEXT(P*), IEXT(O*) and IEXT(I*), 
replace "=" (equal) with "⊆" (subset of equal)

Note that the recognizing of the D* datatype still requires that IR 
contains all IRIs and literals, but at least we do not constrain all 
interpretations to contain all blank nodes nor all triples. Only the 
triples embedded in an RDF* graph (and their constituent terms) are 
required in the interpretations satisfying that graph.


PS: I also considered following Peter's proposal on this thread 
to get rid of the D* datatype, using plain strings instead. This would 
require to update

* the definition of Q(g) for IRIs and literals,

* the specifications of IEXT(S*), IEXT(P*) and IEXT(O*), and

* the specification of IEXT(I*).

The first two items are relatively easy, but the last one is more 
challenging. My intuition is that it would require to redefine a 
datatype-like machinery just for this definition, so for the moment, I 
would prefer to keep the special datatype.

Received on Wednesday, 13 January 2021 09:10:54 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 13 January 2021 09:10:55 UTC