- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Wed, 25 Nov 2020 10:54:10 -0500
- To: Pierre-Antoine Champin <pierre-antoine.champin@ercim.eu>, public-rdf-star@w3.org
So you want something like the following: Define the following datatypes: rdf:IRI a datatype for absolute IRIs The lexical-to-value map is from https://tools.ietf.org/html/rfc3987 No unescaping is performed. rdf:literal a datatype for RDF literals Well-typed lexical forms start with a Unicode string enclosed in " with interior " doubled, followed by an optional language tag preceeded by @, followed by an IRI preceeded by <. The lexical-to-value mapping takes the two or three parts of the lexical form and tries to constructs an RDF literal in the obvious way. If the result is not a valid RDF literal then the lexical form is not in the lexical space of the datatype. No unescaping is performed except for undoubling of "" in the lexical form. This is not the normal writing of RDF literals and was chosen to reduce the need for unescaping and to have a unique representation of RDF literals. Add rdf:subject*, rdf:predicate*, and rdf:object* to the RDF reification vocabulary. These three predicates are used to hold the syntactic form of reified statements when this is desired. RDF* is then RDF with the addition of rdf:IRI and rdf:literal as recognized datatypes. That's it (for RDF*)! Extend Turtle to Turtle* by adding the recursive << s p o >> embedded triples construct. This construct is processed as follows: Let L be an injective mapping from RDF triples to blank nodes that are different from blank nodes resulting from other Turtle constructs. Define M(i) as the RDF literal with datatype rdf:IRI and lexical form i for i an IRI and M(l) as the RDF literal with datatype rdf:literal and the lexical form corresponding to l for l an RDF literal Process an embedded triple << s p o >> construct as follows: If s, p, or o is an embedded triple, process it before processing << s p o >>. Otherwise, replace << s p o >> by L(<s p o>) and add the following triples to the graph being created: < L(< s p o >) rdf:type rdf:Statement > < L(< s p o >) rdf:subject s > < L(< s p o >) rdf:subject* M(s) > if s is not a blank node < L(< s p o >) rdf:predicate p > < L(< s p o >) rdf:predicate* M(p) > if p is not a blank node < L(< s p o >) rdf:object o > if o is not a malformed literal < L(< s p o >) rdf:object M(o) > if o is a malformed literal < L(< s p o >) rdf:object* M(o) > if o is not a blank node peter On 11/25/20 7:27 AM, Pierre-Antoine Champin wrote: > > On 24/11/2020 17:45, Peter F. Patel-Schneider wrote: >> Any encoding will have to transform RDF terms so that there are no collisions >> between them and the terms used in the encoding of embedded triples. >> Otherwise you end up with entailments like: >> >> << :a :b :c >> :d :e . >> >> entails >> >> _:x rdf*:subject* ":a"^^rdf*:term . >> >> (Yes, this is a bit sloppy.) >> >> >> If you are willing to expose the details of the encoding in this way, > > Yes, that's how I envisioned a "syntactic sugar" solution, i.e. Turtle* as a > compact notation for something that could, otherwise, be written in plain > Turtle. > >> or >> exclude certain RDF graphs from RDF*, then it is not necessary to transform >> RDF terms. >> >> >> And, of course, this is simply a specification of entailment in RDF*. >> Implementations are free to do something else that doesn't involve >> transforming RDF terms. >> >> >> >> >> peter >>
Received on Wednesday, 25 November 2020 15:54:25 UTC