Re: [External] : Re: An outline of RDFn -- RDF with (auto- and custom-) names

Well this is new.

Is there some place where the working group can find a complete description of 
RDFn, including concrete syntax, abstract syntax, and semantics?  Access to an 
implementation would be very useful as well.

peter


On 11/28/23 00:49, Souripriya Das wrote:
> Hi Peter,
> 
> RDFn supports unasserted and asserted triples (and quads) as follows:
> 
> 1) Each auto-named triple will be marked either as asserted or unasserted.
> 
>        a) Example 1: Asserted, auto-named triple: (every RDF1.1 triple maps to 
> this type)
>              ex:Cleveland ex:servedAs ex:POTUS .                              
> # asserted, auto-named triple
> 
>        b) Example 2: Unasserted, auto-named triple:
>          << ex:Dukakis ex:servedAs ex:POTUS >> .                       # 
> unasserted, auto-named triple
> 2) Custom-named triples for a given <s, p, o, g> are considered as unasserted 
> UNLESS an asserted auto-named triple exists with the same <s, p, o, g>. Thus, 
> this is a derived attribute for a custom-named triple, but a primary attribute 
> (somewhat like "boolean isAsserted") for an auto-named triple.
> 
>        Example 3: The custom-named triples about Dukakis and Gore in the RDF 
> data below are considered as unasserted, but the custom-named triple about 
> Cleveland is considered as asserted.
> 
>          ex:Cleveland ex:servedAs ex:POTUS .                        # 
> asserted, auto-named
>          ex:Cleveland ex:servedAs ex:POTUS | ex:term2 .  # asserted, 
> custom-named (b/c corr. auto-named triple exists and is asserted)
> 
>              << ex:Dukakis ex:servedAs ex:POTUS >> .      # unasserted, auto-named
>              ex:Dukakis ex:servedAs ex:POTUS | ex:Duk.  # unasserted, 
> custom-named (b/c corr. auto-named triple exists but is unasserted)
> 
>              ex:Gore ex:servedAs ex:POTUS | ex:Gore.        # unasserted (b/c 
> no corr. auto-named triple exists)
> 
> 3) When merging, multiple auto-named (source) triples having the same <s, p, 
> o, g> get merged into a single auto-named triple that will be marked as 
> unasserted UNLESS at least one of the (source) triples was marked as asserted.
> 
> Also, please note that, as mentioned in one of my earlier emails, SPARQL is 
> extended to introduce << ... >> triple-patterns and isAuto(<nameVar>) boolean 
> function to 1) allow matching unasserted triples as well, and 2) distinguish 
> auto-named and custom-named triples when matching, respectively.
> 
> Thanks,
> Souri.
> 
> 
> ------------------------------------------------------------------------------
> *From:* Peter F. Patel-Schneider <pfpschneider@gmail.com>
> *Sent:* Monday, November 27, 2023 3:56 PM
> *To:* public-rdf-star-wg@w3.org <public-rdf-star-wg@w3.org>
> *Subject:* [External] : Re: An outline of RDFn -- RDF with (auto- and custom-) 
> names
> Is RDFn the same as RDF-star?   Well, in the sense that each can encode the
> other, yes.  But this isn't a very useful sense of sameness.
> 
> More interesting is whether there is a natural correspondence between all of
> RDFn and all of RDF-star.  But there isn't, at least so far as I can ascertain
> from the information given to the working group.  RDF-star has unasserted
> triples, which RDFn appears to lack.  RDFn uses graphs with multi-edges, which
> RDF-star does not provide.
> 
> peter
> 
> 
> On 11/26/23 22:08, Souripriya Das wrote:
>> Since I did not hear any comments on RDFn during the first half of our last 
>> meeting that I was able to attend (except, maybe, Gregg might have said 
>> something right at the beginning but I had audio issues on my side), I thought 
>> it may be helpful to mention below a few high-level points about RDFn and how 
>> it is related to RDF-star concepts and syntax: ("statement" here simply means 
>> "a triple or quad"):
>> 
>> 1) RDFn = RDF-star (which, I think, uses implicit naming in some sense, with 
>> << s p o >> as the name) + explicit naming (using IRIs as custom names).
>> 
>> 2) RDFn (with appropriate syntactic shortcut) would appear exactly the same as 
>> RDF-star to a user who does not use multi-edges or statement-sets.
>> 
>> 3) RDFn does not change anything regarding how users work with default graph 
>> and named graphs today.
>> 
>> 4) RDFn requires use of explicit naming if user needs to store multi-edges. 
>> For modeling multi-edges, user does not need to introduce new triples or quads 
>> with special properties like :isOccurrenceOf or :hasOccurrence.
>> 
>> 5) RDFn requires use of explicit naming for modeling statement-sets as well. A 
>> statement-set in RDFn can include (asserted or unasserted) triples from the 
>> default graph and the named graphs. The custom-name of a statement-set can be 
>> used for making statements about it.
>> 
>> Thanks,
>> Souri.
>

Received on Tuesday, 28 November 2023 16:32:57 UTC