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

I think it has been established that most use cases can be characterized as annotating tokens, not types (if that still isn’t common wisdom then that would be a very important discussion to have first). 

So, what does each approach need to annotate a token? If a token identifier is not provided, it needs to define one. RDFn, RDF standard reification and singleton properties provide such an identifier out of the box, RDF-star has to rely on the user being disciplined enough to create one via an extra statement. If such a token identifier can only identify individual triples but not also graphs, then we need two different mechanisms: one for triples, one for graphs. Ergo we get a quin solution, no matter if those five elements are expressed in one statement with five elements or two statements with four elements or in four statements with three elements, etc.
Only if we use named graphs to also annotate single triples does RDF remain a quad solution in practice. If, as some suggest, named graphs are off-limits to any sound annotation application, then it becomes a quin solution where the fourth element may be a statement identifier or another (sound, not RDF 1.1 named graph) graph identifier. I’m just pounding on this a little bit so that everybody understands that the proposition that named graphs are off limits would have indeed a pretty high cost ('would' as I don’t think that this position has a good chance to survive).

> On 27. Nov 2023, at 21:56, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
> 
> 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.  

IMO there is, as both lead to a five-element formalism: triple + triple-id + graph-id (no matter how many statements are involved in expressing those five element, see above).

> RDF-star has unasserted triples, which RDFn appears to lack.  

Yes indeed, that is a difference, however one that is orthogonal to the main task, which is annotation.

> RDFn uses graphs with multi-edges, which RDF-star does not provide.

As I said in my first mail already: RDF-star needs to provide a facility to annotate tokens, otherwise it can’t meaningfully address the vast majority of use cases. That it only does so in a very informal and underspecified way doesn’t make it a completely different approach, just a lesser one.

The most useful perspectve in my opinion is an at least vague idea of what is needed. Then one can compare approaches by what they provide (or need to add) to address that need. Otherwise one gets those strange comparisons where having a formalization, even if its irrelevant, is considered a bonus. 

Thomas

> 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 Monday, 27 November 2023 21:38:09 UTC