Skip to content
This repository has been archived by the owner on Feb 15, 2020. It is now read-only.

Evolution approach to compound literals. #22

Open
afs opened this issue Aug 6, 2019 · 4 comments
Open

Evolution approach to compound literals. #22

afs opened this issue Aug 6, 2019 · 4 comments

Comments

@afs
Copy link

afs commented Aug 6, 2019

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 w3c/EasierRDF#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
Copy link
Member

iherman commented Aug 6, 2019

@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
Copy link
Author

afs commented Aug 7, 2019

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

@pchampin
Copy link
Collaborator

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
Copy link
Author

afs commented Aug 29, 2019

@pchampin -- w3c/sparql-dev#34 for example.

Also expressions in CONSTRUCT (made up syntax)

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants