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

On Mon, Jul 13, 2020, at 11:46, Cox, Simon (L&W, Clayton) wrote:
>  1. JSON literals is specified in https://w3c.github.io/json-ld-syntax/#the-rdf-json-datatype – the `rdf:JSON` datatypes

I'd forgotten about that. Excellent point. 

>  1. Alongside `xsd:dateTime` used of structured literals for coordinates was specified in GeoSPARQL many years ago https://www.ogc.org/standards/geosparql - the `geo:wktLiteral` and `geo:gmlLiteral` datatypes
> The latter are widely used already in the GIS community, and the rdf:JSON datatype will also make GeoJSON a tractable alternative.

> 

> The argument for moving some kinds structured data over to the other side of the RDF|Data boundary is that the operations that are generally carried out on those are (in this case) geometric/algebraic rather than logical, and thus use different engines.


Don't get me wrong: I am not against using structured formats (such as JSON) as literal values if and when it makes sense to do so (though since such literals are opaque from RDF/SPARQL's point of view, it's still a choice that should be used with restraint). 

I was merely questioning whether any of this requires changes to the RDF model itself: it's already possible to do this within the bounds of the current standard, as both your examples illustrate. Whether the JSON datatype gets accepted as part of the rdf syntax namespace is a matter of nomenclature, not a fundamental modeling issue. 

Arguably we might want to consider extensions to SPARQL to handle JSON-structured literals more elegantly - GeoSPARQL is a good example of doing exactly that for (a.o.) WKT strings I guess. The SPARQL 1.2 community group <https://www.w3.org/community/sparql-12/> is collecting extension / improvement proposals. 

Cheers,

Jeen

PS Anthony I just saw your response - fwiw I don't think your suggestion was useless at all! It's just that I have the impression that in general, people in this discussion who are trying to "fix" blank nodes are experiencing a bit of an XY problem.

> 

> *From:* Jeen Broekstra <jeen@fastmail.com> 
> *Sent:* Monday, 13 July, 2020 11:26
> *To:* semantic-web@w3.org
> *Subject:* Re: Blank nodes must DIE! [ was Re: Blank nodes semantics - existential variables?]

> 

> 

> 

> On Mon, Jul 13, 2020, at 01:28, Anthony Moretti wrote:

>> I'm not sure where to post this because there are some subthreads and it's hard to judge, if somebody would prefer that let me know, but it seems relevant to bnodes so posting it here.

>> 

>> In one subthread ("Datatypes") Pat says:

>> 

>>> I just wish we had allowed datatypes which used more than one character string, so that (for just one example that caused way too much hassle) language-tagged strings, but also things like latitude+longitude or number+ unit (5 inches, 27 cm, 3.5 kg) could have been handled naturally. Right now it is not easy to say in RDF that the Thames is 215 miles long, and also that 215 miles is the very same thing as 346 km. But this kind of thing is ubiquitous.

>> 

>> So maybe, rather than a literal or a bnode, RDF could just incorporate some JSON? Can put it all on one line like a literal or bnode, and can use nesting too.

> 

> Saying "incorporate some JSON into RDF" is a bit like saying "incorporate some nice words into the alphabet". They're at slightly different conceptual levels.

> 

> I'm not against revisiting the structure of RDF literals and/or seeing what we can do to make things like units of measurement more easily represented. But making JSON objects first-class citizens does not really solve anything, I think.

> 

> For example: how does this bit of JSON fit into the conceptual model? How is it stored, and how is it queried and/or referenced? Is it a single node in the graph? Then how is it different from just having a literal with a JSON string as its lexical value? Or if it's a node with several associated properties, how is it different from just having any collection of statements with a shared subject (blank node or IRI) that together form the object value?

> 

>> Example triples (I've removed string quotations etc. because this is just rough pseudocode):

>> 

>>  france name {type: LanguageTaggedString, value: France, language: English}

>>  place1 geoCoordinates {type: GeoCoordinates, latitude: 0.0, longitude: 0.0}

> 

> At the syntax level, this is *literally *(hah) what blank nodes already give you: assuming the above is pseudo-Turtle, pretty much all you've done is replace the square brackets with curly ones:

> 

>  :france :name [ :type :langString; :value "France"; :language "English" ] .

>  :place1 :geoCoordinates [ :type :GeoCoordinates; :latitude 0.0; :longitude 0.0 ] .

> 

>  1. 
> Jeen