Re: Consolidating triple/edges -- named occurrence version

In the named occurrence proposal, can the blank node of a named 
occurrence RDF term be used on its own as the named occurrence?

  << _:a | :s :p :o >> :starts 1989 .
  _:a :finishes 1990 .


As the name can be a URI,

  << <http://example/occ1> | :s :p :o >> :starts 1999 .
<http://example/occ1> :finishes 2000 .

In SPARQL: does this match the examples above?

SELECT * {
    ?X :starts ?start .
    ?X :finishes ?finish .
}

If yes,
either
   _:a :finishes 1990 .
is actually
   << _:a | :s :p :o >> :finishes 1990 .

or if
   _:a :starts 1989 .
   _:a :finishes 1990 .
then how does the application find :s :p :o?

In the proposed semantics: [1]

[I+A](r) = IS(r) if r is a iri
[I+A](r) = A(r) if r is a BlankNode
[I+A](r) = [I+A](r.id) if r is a tripleOccurrence

so

[I+A](r) = A(r.id)   if r is a tripleOccurrence
                      and r.id is a blank node
[I+A](r) = IS(r.id)   if r is a tripleOccurrence
                       and r.id is a URI.

This has an impact on implementations and APIs.

Take Apache CommonsRDF [2] as an example.

The accessor function on a graph is

Stream<? extends Triple>
    stream(BlankNodeOrIRI subject, IRI predicate, RDFTerm object)

where subject/predicate/object can be a constant or a wildcard.

So if the application is given <http://example/occ1>, how does it 
determine whether URI is named occurrence and if so, how does it find 
the triple subject/predicate/object?

Scanning all triples to find named occurrences and looking at the id of 
a named occurrence is expensive.

Expecting an addition function x -> triple just for occurrences is a big 
step.

In the triple-term version has rdf:occurrenceOf so there is a triple to 
maps the blank node / URI to the 3-tuple of s,p,o that had the effect of OT.

     Andy

[1] 
https://github.com/w3c/rdf-star-wg/wiki/Semantics:-Andy's-proposal#semantics

[2] Apache CommonsRDF : https://commons.apache.org/proper/commons-rdf/

Received on Monday, 1 January 2024 16:52:23 UTC