Evolution approach to compound literals.

afs commented 5 years ago

If there is a solution that is transparent to intermediate systems storing and publishing RDF, then roll-out is going to be smoother.

A non-syntax-change way to have more information about literals is in the style of SKOS-XL: encode the information in triples. This is mentioned in https://github.com/w3c/EasierRDF/issues/22.

Vocabularies are the "extension" mechanism for RDF. Processors at each end need to understand such vocabularies but intermediate storage and RDF syntax does not.

There is value in having a standard for dir-literal which would cover a defined way to treat RDF 1.1 rdf:langString in this new vocabulary, and a reverse mapping giving a view in language tags of the richer literal description.

Syntax extensions can evolve to make these compound literals more readable.

The advantage is that it is not a required-everywhere change to RDF, or any syntax of RDF, and data can be carried across any RDF system without every system being changed.

The disadvantage is that it is "yet-more triples" and what were literals become blank nodes/IRIs.

iherman commented 5 years ago

@afs just to make it clear to the non-rdf reader, what you propose is to define two predicates (probably in the RDF namespace) and directly encode the 'localizable string' structure:

[] ex:predicate [
   rdf:value "Sometext" ;
   rdf:language "en" ;
   rdf:direction "ltr' ;
] .

(possibly adding a rdf:LocalizableString type). Is that correct?

afs commented 5 years ago

Yes, though I wasn't thinking so much about what the predicates would be, only that they can capture all sorts of characteristics.

pchampin commented 5 years ago

One could even imagine some kind of dedicated inference, of the form

CONSTRUCT
{
  ?s ?p [
    a rdf:CompoundLiteral;
    rdf:value ?value;
    rdf:language ?language;
  ]
} WHERE {
   ?s ?p ?o.
   FILTER(isLiteral(?o) && lang(?o))
   BIND(str(?o) as ?value)
   BIND(lang(?o) as ?language)
}

in order to force "old style" literals into compount literal, and allow for homogeneous querying...

BTW: this CONSTRUCT query illustrates how cumbersome langStrings are to handle in SPARQL ;)

afs commented 5 years ago

@pchampin -- https://github.com/w3c/sparql-12/issues/34 for example.

Also expressions in CONSTRUCT (made up syntax)

  ?s ?p [  rdf:value $(str(?o)) ; rdf:language $( lang(?o)) ]

w3c / rdf-dir-literal

Evolution approach to compound literals. #22