SPARQL*/RDF* and RDFS support

[peterjohnlawrence]

I see from other posts discussion of 'standard' reification, which I assume to be that defined in rdf, viz rdf:Statement rdf:subject, rdf:predicate, rdf:object vs what I guess is non-standard reification using rdf:Triple rdfx:subjectTerm, rdf:predicateTerm, rdf:objectTerm and other variants. My question is related to 'standard' reification and to what extent RDFS will be supported. I use the equivalent of reification extensively in models. However I do create rdfs:subClassOf rdf:Statement and the corresponding rdfs:subPropertyOf rdf:subject, rdf:predicate, and rdf:object.

For example, when modeling a resource's attributes (aka observations, measurements), instead of the simple :aResource :hasHeight "25"^^xsd^^double we need to reify this to capture further details such as units-of-measure, time-of-measurement, accuracy etc (yes Reification-101):

def:Attribute_1
  rdf:type def:Attribute ;
  def:attribute.of.Item id:Peter ;
  def:attribute.Property def:hasHeight ;
  def:attribute.Value "25"^^xsd^^double ;

  def:attribute.UOM def:CM ;
  def:attribute.accuracy ".32"^^xsd^^double ;
.

Where the following have been declared:

def:Attribute
  rdfs:subClassOf rdf:Statement 
.

def:attribute.of.Item
  rdfs:domain def:Attribute ;
  rdfs:subPropertyOf rdf:subject ;
.

def:attribute.Property
  rdfs:domain def:Attribute ;
  rdfs:subPropertyOf rdf:predicate ;
.

def:attribute.Value
  rdfs:domain def:Attribute ;
  rdfs:subPropertyOf rdf:object ;
.

I guess one could use only 'standard' reification, but this loses the disambiguation that RDFS offers:

def:Attribute_1
  rdf:type rdf:Statement ;
  rdf:predicate def:hasHeight ;
  rdf:subject id:Peter ;
  rdf:object "25"^^xsd^^double ;

  def:attribute.UOM def:CM ;
  def:attribute.accuracy ".32"^^xsd^^double ;
.

I realise that SPARQL alone does not recognize RDFS, but the implications (I think) of <<...>> and standard reification is that rdf:subject, rdf:predicate, and rdf:object have rdfs:domain rdf:Statement. Following this same slippery slope, have rdfs:subClassOf and rdfs:subPropertyOf also been considered?

To illustrate this pattern's use, the following is the equivalent of select * {?s ?p ?o}

select  ?relationshipType ?s ?p ?o
{
VALUES(?reificationType ?s ?p  ){ (UNDEF UNDEF UNDEF  )}
OPTIONAL{ ?subject rdfs:domain ?reificationType; rdfs:subPropertyOf rdf:subject  . ?reifiedRelationship  ?subject ?s .}
OPTIONAL{ ?predicate rdfs:domain ?reificationType  ; rdfs:subPropertyOf rdf:predicate  . ?reifiedRelationship  ?predicate ?p . }
OPTIONAL{ ?object  rdfs:domain ?reificationType  ;  rdfs:subPropertyOf rdf:object  . ?reifiedRelationship  ?object ?o .}
}

For example

select  ?relationshipType ?s ?p ?o
{
VALUES(?reificationType  ?s ?p  ){ (def:Attribute   id:Peter def:hasHeight  )}
OPTIONAL{ ?subject rdfs:domain ?reificationType; rdfs:subPropertyOf rdf:subject  . ?reifiedRelationship  ?subject ?s .}
OPTIONAL{ ?predicate rdfs:domain ?reificationType  ; rdfs:subPropertyOf rdf:predicate  . ?reifiedRelationship  ?predicate ?p . }
OPTIONAL{ ?object  rdfs:domain ?reificationType  ;  rdfs:subPropertyOf rdf:object  . ?reifiedRelationship  ?object ?o .}
}

Why? In my experience this pattern of 'extended reification' appears over and over again in the models I have encountered, so it is useful for me to standardize on the pattern and reuse it whenever possible. Sometimes the pattern is not obvious. For example a purchase order's line item follows this pattern, as do many of the '3D/4D' modeling needs [http://hdl.handle.net/1854/LU-5721901]

[pchampin]

A short comment, unrelated to RDF*, about this:

SPARQL alone does not recognize RDFS

If I understand correctly what you mean by that, this is not entirely accurate. SPARQL engines are not required to support RDFS-inferences, but some of them may support it (see https://www.w3.org/TR/sparql11-entailment/). So given this data:

:alice a :Woman.
:Woman rdfs:subClassOf :Person.

and the following query:

SELECT * { ?x a :Person }

some engines may return no results, and others may return :alice.

Note also that a more robust way (compared to your examples) to emulate subproperty inference on a non-RDFS SPARQL engine would be:

SELECT * {
    ?s ?p ?o.
    ?p rdfs:subPropertyOf* :myPredicate.
}

[pchampin]

You are correctly assuming that "standard reification" in our discussions refers to https://www.w3.org/TR/rdf11-mt/#reification .

However, RDF* has a very different approach, which I think (but I may be missing something) makes your question about RDFS irrelevant.

In RDF's abstract syntax, embedded triples (e.g. << :s :p :o >> in SPARQL) are terms of their own (like IRIs or literals). Unlike standard reification, their internal structure is not represented a set of triples.

SPARQL* is based on that abstract syntax, and so you can not query the subject of a triple with a triple pattern of the form ?triple rdf:subject ?s, but instead, you would simply write << ?s :rest_of :the_triple >> (or << ?s ?p ?o >> if you also don't know the predicate and object of said triple).

As there is no rdf:subject (or similar) property involved, the question of using a subpoperty of it is a non-issue.

[peterjohnlawrence]

Does this not imply that SPARQL has to be aware of the storage model adopted RDF or RDF?

I would have expected that the SPARQL would allow a user to express their query without having to know if RDF had decided to store its as a triple <<:aSubject :aPredicate :aObject >> or explicity stored the multiple triples:

 :aTriple rdf:subject :aSubject ;  
         rdf:predicate :aPredicate ;  
         rdf:object :aObject ;. 

But perhaps this the anticipated behaviour for SPARQL*, I am just guessing at this stage.

[afs]

Does this not imply that SPARQL has to be aware of the storage model adopted RDF or RDF?

Yes - though a better framing is that they share storage or even that the RDF database for SPARQL is the storage, RDF is one API to that and Turtle is a input format.

A system could do a transformation to reification as Turtle* is parsed - i.e. a very superficial treatment. It has consequences if done naively (a lot of triples) and optimizing it is a significant investment: https://www.hpl.hp.com/techreports/2003/HPL-2003-266.pdf

Results would not contain RDF* triple terms.

Adding a new RDF term type for <<>> isn't that big a deal in my experience.

[afs]

I am having difficulty translating this into a use case of the form:

As an <actor>       … WHO
I want a <feature>  … WHAT
So that <benefit>   … WHY

My reading is that it is asking for referential transparency so the RDFS applies.

There are use cases for both referential transparency and referential opacity.

One can go from referential opacity to referential transparency but not the other way round.

Converting to reification is one way (not the only way) - this is because the application can decide that the opaque << >> can be lifted up to being transparent in this graph (this domain of discourse).

[peterjohnlawrence]

As a user I want to express facts as triple statements (:s :p :o} within a triplestore Later on I realise I want to add facts about this fact. However the {:s :p :o} triple has already been asserted in the triplestore, so I need to add a reification

:key rdf:subject :s ; rdf:predicate :p ; rdf:object :o .

Now I can add facts about the fact:

:key :uom :cm ; :accuracy ".32" .

So far 'standard' reification.

However, as a user I want to add some RDFS 'referential' integrity to help manage the use of additional predicates such a :uom and :accuracy. Since the rdfs:domain of rdf:subject, rdf:predicate, and rdf:object, it can be inferred that :key is a rdf:Statement. This then implies that the rdfs:domain of :uom and :accuracy is also rdf:Statement. Thus if I continue reifying other statements, any predicates associated with the reified statement must have a rdfs:domain of rdf:Statement.

So as a user who wants to add some RDFS-based control over the model, I would introduce a rdfs:subClassOf so that predicates associated with this subClass have a rdfs:domain of this subclass

Triple: :Peter :married :Beth Reified Triple: :marriageKey rdf:subject :Peter ; rdf:predicate :married ; rdf:object :Beth .

:marriageKey a :Marriage
            :when "1980" ;
            :where "Kelby" .

with the following RDFS assertions:

:Marriage rdfs:subClassOf rdf:Statement .

and

:when rdfs:domain  :Marriage .
:where rdfs:domain  :Marriage .

The benefits are that I can combine triple reification with RDFS providing the same benefits that rdfs offers to rdfs:Class to rdf:Statement.

[TallTed]

@peterjohnlawrence (markup added; errant leading : removed)

This then implies that the rdfs:domain of :uom and :accuracy is also rdf:Statement. Thus if I continue reifying other statements, any predicates associated with the reified statement must have a rdfs:domain of rdf:Statement.

Caution! Inference isn't nearly so absolute, in Open World. I submit rather that --

This then implies that the schema:domainIncludes of :uom and :accuracy includes rdf:Statement. Thus if I continue reifying other statements, any predicates associated with the reified statement --

• may have an rdfs:domain of rdf:Statement
• must have a schema:domainIncludes of rdf:Statement

[afs]

Include in the UCR with text as written.

In addition to @TallTed's comment:

Better name might be :MarriageStatement since the domain of :when is not a marriage but a statement about the marriage (it is the stating since the reificiation of itself does not assert the fact).

It also seems that you want to refer to the actual claim made and <<:s :p :o >> will do that.

:key :uom :cm says that the thing denoted by :key has a :uom relationship to :cm.

Both :uom and :accuracy need to be defined so that they take a rdf:statement, or triple term, as domain, and that the property means that it augments the meaning of the statement (domain of discourse).

This is making the original assertion into an n-ary relationship without needing to change the original assertion.

[afs]

:uom and :accuracy must not be the natural language implied reading in :key :uom :cm but instead define the property meaning to refer to the predicate of the reification.

schema:domainIncludes is a disjunction of terms ("may"), RDF/RDFS is conjunction logic. They don't play well together so schema:domainIncludes is more like documentation as far as RDFS is concerned; it can be included as an inference rule. A whole different discussion about schema.org. Nothing new here.

[TallTed]

@afs - I think you meant to say "it can't be included as an inference rule." Please, we all have to be extremely careful about typos in discussions such as this. One missing negation (like this) can lead to days, weeks, even months of agreement at the top of our lungs, not to mention long-lasting confusion for ourselves and others.

But in that case, I'm at a loss as to what you meant by "In addition to @TallTed's comment:" which seems to accept my earlier comment (as opposed to arguing against it, as in this later comment from you).

In either case, I wasn't suggesting schema:domainIncludes as an inference rule, so much as saying that inferring an inference rule (e.g., "must have an rdfs:domain of rdf:Statement") is potentially dangerous/problematic. (These swans are all white, therefore all swans are white, therefore that black bird is not a swan; potential FAIL.)

[afs]

My offer has been to gather use cases together, and like all the ones in the document, they are as the contributor wrote them. Analysis is another step for the group if it wishes to.

"In addition" was without agreeing or disagreeing with your comment.

schema:domainIncludes has its own (not RDFS) meaning - describing that as inference seems fair.

I would be grateful if you would remove the personal comments as they have no places on a use case contribution.

[afs]

@peterjohnlawrence - thank you for the use case. It has been added to the use cases record in the group documents.

https://w3c.github.io/rdf-star/UCR/rdf-star-ucr.html#rdfsSupport