- From: thomas lörtsch <tl@rat.io>
- Date: Fri, 22 Jan 2021 13:13:55 +0100
- To: Olaf Hartig <olaf.hartig@liu.se>
- Cc: public-rdf-star@w3.org
> On 21. Jan 2021, at 15:35, Olaf Hartig <olaf.hartig@liu.se> wrote: > > Hi Thomas, > > You are raising an interesting point that I was also thinking about recently, > and I believe I have a solution. > > First of all, regarding terminology, our groups' earlier discussions related > to this topic used the terms "referential opacity" and "referential > transparency" for what you call "syntactic triple" and "interpreted triple" > now. > > The proposed semantics adopts referential opacity. From my understanding, in > comparison to a semantics that adopts referential transparency, adopting > referential opacity (as in the proposed semantics) is less restrictive in the > sense that it does not rule out the possibility to use referential > transparency for selected cases. In other words, by using referential opacity > as a basis (i.e., for the semantics of RDF*), on top of this basis you may > still define specific cases for which the additional nested triples may be > derived that you would expect under referential transparency. In contrast, if > referential transparency is used as a basis, which says that such additional > nested triples can be derived for all cases, then it is not possible to define > on top of this basis that there are cases for which the additional triples > should actually not be derived. At least, that's what I had understood from my > discussions with Pierre-Antoine and Dörthe (please feel free to confirm or > correct me on this). Seems to be the same understanding as mine. > Given this understanding, you may indicate the cases in which you want to use > referential transparency on top of a referential opacity semantics by using > specific properties that you introduce for this purpose. For instance, you may > introduce a property denoted by the URI ex:statedBy and define that > referential transparency can be used for nested triples that have this > property in their predicate position. This way, related to your example, if > you have a nested triple > > <<:cars :are :bad>> ex:statedBy :Alice > > you can derive the following triple. > > <<:automobiles :are :bad>> ex:statedBy :Alice > > So, while the semantics of RDF* adopts referential opacity, you can build on > it and define cases in which you want to have referential transparency. But doesn’t this mean that in every case that you want to comment on a triple with referential transparency you have to define a new property with those specific semantics? That would seem like an outrageous demand to me. And even then: how would you define such a property? It probably should be a subproperty of the property that you intend to use. That seems to need a new property like rdf*:isSubpropertyWithOpaqueSemanticsOf or even rdf*:isSubpropertyWithOpaqueSemanticsInDomainOf rdf*:isSubpropertyWithOpaqueSemanticsInRangeOf rdf*:isSubpropertyWithOpaqueSemanticsInDomainAndRangeOf as different embedded triples in subject and object position might have different semantics. So you’d get three subproperties per any property from any established vocabulary, right? Maybe not *all* of them but certainly not a few in between. If this is indeed your proposal then I think you’ll have to come up with something better. Or please explain what you meant instead. Thomas > Best, > Olaf > > > On torsdag 21 januari 2021 kl. 13:40:56 CET thomas lörtsch wrote: >> [I hope I’m using the right terminology in the right way. Advice is >> welcome.] >> >> The proposed semantics defines that the embedded triple refers to a triple >> on the syntactic level, not in the realm of interpretation. In defense of >> this rather peculiar arrangement Pierre-Antoine and Dörthe argued that >> going from the syntactic to the interpreted triple is always possible >> whereas the other way round it is not: once a triple is part of the >> interpretation we can not know what its original syntactic structure was. >> That’s true (at least in any normal setup) but let's assume I’d like to >> annotate not the syntactic triple but the interpreted triple. What would I >> actually have to do to construct a reference to an interpreted triple from >> an RDF* embedded triple? >> >> >> Lets for example assume someone published the triple >> >> :cars :are :bad . >> >> As he published that statement on the semantic web we can assume that his >> intend was to refer not only to :cars but just as well to :automobiles, >> :voitures etc. Now if we want to comment on that general interpretation of >> this statement, irrespective of the concrete vocabulary used, irrespective >> of any syntactic specifics, how would we do that? The proposed semantics of >> >> << :cars :are :bad >> :a :disputedClaim . >> >> doesn’t cover this very common case as the embedded triple only refers to >> that very specific syntactic form. From this RDF* statement we couldn’t >> infer that >> >> << :automobiles :are :bad >> :a :disputedClaim . >> >> even if we were using a reasonably complete mapping of car related >> vocabiularies. Adding all those derivable embedded triples to the database >> is not a viable option as it would increase operational costs enormously. >> We need a way to derive a reference to the interpreted triple from the >> syntactic triple that the RDF* embedded triple represents. But how? >> >> >> Thomas > > >
Received on Friday, 22 January 2021 12:14:15 UTC