Re: Blank nodes must DIE! [ was Re: Blank nodes semantics - existential variables?]

I'm probably not following this very well, but will comment nevertheless :-)

I say: if there are literals in RDF that have structure, that structure *must* be the same as the host language.

When I am processing an RDF graph, I have an RDF processor in my system - please don't make me have to have another different processor to deal with literals.
This is what worries me in particular about JSON literals.
When I am for example processing a resolved URI RDF document in n3 or rdf-xml, the literals should be in the same format - after all that is what I connegged, presumably.
The same is true processing SPARQL output.

Unless the literal is completely opaque - but in that case, we shouldn't be discussing its structure!

Which leads to a wider question.
For example
> Any engine that operates with quantities needs to understand that. ’25.4’ and ‘mm’ cannot be separated
I don't see why not.
I may well want to ask what units the quantity is in.
If there is structure to a literal, it is precisely because you may want to find out what the units are, what the latitude is, what is the coordinate system, etc..
So you can do things, such as compare them, or plot them on a map, etc..

So we have structured "literals" that are represented in RDF, it seems.
Which is pretty much where we started in with the bnode suggestion, although it doesn't require things to be bnodes, of course.
And those "literals" aren't really literals any more - they have all become very specialised, with lots of implied or specific semantics, it seems.

The atomicity thing is another angle - again, hopefully it is more generic than just relating to a restricted set of what someone has thought classify as literals.
It would be nice to have that sort of thing, presumably, but why restrict it to these strange "literals"?

I find myself wondering whether Dan's comments couldn't be recast as something like a Named Graph that is either there or not there (asserted or not asserted), and may have attributes that tell you whether it conforms to "literal" (or other) standards, perhaps with shapes and shape languages.
Someone has probably already done this, AFAIK.

So I don't see the need to change RDF & literals in any way.
[For this - I could suggest other things I think would be an improvement, but not here :-) ]

Cheers
Hugh

> On 17 Jul 2020, at 00:57, Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au> wrote:
> 
> Yeah, the atomicity of the chunk is the point. This even applies to quantities. 25.4mm is identical to 1” – they are the same thing. Any engine that operates with quantities needs to understand that. ’25.4’ and ‘mm’ cannot be separated. Coordinates are slightly more complex but it comes down to the same thing. A single element within a set of coordinates that describes a position in space is not independent of the other numbers in the tuple, or of the coordinate reference system within which they are expressed. One value should never be used independent of the others. Exactly the same position on the earth will be denoted by three different numbers if embedded in a different coordinate reference system. You can only ‘reason’ over them as a group, not individually.
>  
>  
> From: Dan Brickley <danbri@danbri.org> 
> Sent: Thursday, 16 July, 2020 23:58
> To: Jeen Broekstra <jeen@fastmail.com>
> Cc: Semantic Web <semantic-web@w3.org>
> Subject: Re: Blank nodes must DIE! [ was Re: Blank nodes semantics - existential variables?]
>  
> …
>  
> I believe the big appeal of putting it all into the zone we call "literals" is that you get a kind of atomicity; that chunk of data is either there, or not there; it is asserted, or not asserted. With a triples-based (description of a ) data structure you have to be constantly on your guard that every subset of the full graph pattern is at least sensible and harmless, even when subsetting these chunks is often confusing or misleading for data consumers. I can't help wondering whether notions of graph shapes from shacl, shex (and sparql) could be exploited to create an RDF-based data format which had atomicity at the level of entire shapes.
>  
> Dan
>  
>  
>  
>  
> Jeen

-- 
Hugh
023 8061 5652

Received on Friday, 17 July 2020 12:54:59 UTC