Allow arbitrary strings as predicates

[HolgerKnublauch]

THIS IS ME BRAINSTORMING ONLY, so don't kill me.

Currently, RDF requires predicates of a triple to be IRIs. I guess that choice was made so that

1. ontologies can attach information such as rdfs:range and rdfs:label to the properties themselves
2. it becomes more likely that predicates are scoped in the context of a namespace and thus don't clash with other namespaces, which means that it is likely that (SPARQL) queries against these properties only find the subjects that we want

But:
ad 1: Global property axioms are not necessary and do not play a role in SHACL where everything is scoped by shapes and classes. And rdfs:range and rdfs:domain are typically horribly misunderstood.
ad 2: Even with unique identifiers people from other graphs may reference your predicate in unexpected ways and your queries still need to filter by subjects.

Even within a single namespace it is quite common that the same URI is used for different purposes. For example, a ex:role property could point from an ex:Agent to a ex:Role or from an ex:Organization to a ex:Role, and both could have different local meanings depending on the context.

So the benefits of URIs as predicates are IMHO overrated.

Proposal: Moving forward, RDF could also allow predicates to be arbitrary strings.

a) That is how most map-based data structures like JSON objects or Python dictionaries operate, meaning that the mapping between RDF and other languages becomes easier. I think property graphs too.

b) Allowing strings would make the syntax more compact. For example one could write

ex:David firstName "David"

c) People don't need to invent artificially "unique" names - their application logic and queries are most likely already checking for the context anyway, e.g.

SELECT ?david
WHERE {
    ?person firstName "David" .
    ?person a ex:Person .
}

is already scoping the use of firstName to instances of Person, making the property uniquely identified at query time. And when mapped to languages like GraphQL or JavaScript, any access to predicates is already scoped to the context object.

As this would be an incremental generalization, existing RDF graphs would not be affected. People are not forced to use strings as predicates.

To minimize the overhead for existing triple stores, string-based predicates could be internally converted to URIs such as

urn:rdfpredicate:firstName

after parsing in Turtle or SPARQL. But in the far future, there could also be an RDF that uses no URIs as predicates, with all frequently used predicates mapped to shorter names. Turtle and SPARQL have already started going down this route by introducing 'a' as abbreviation for rdf:type. They could also add 'label' as alias for rdfs:label or 'superClass' as alias for rdfs:subClassOf.

Also note that schema.org and wikidata use the same namespace for all predicates, so basically it's the same as if no namespace exists in their worlds.

[dbooth-boston]

Interesting idea. I think there are two ways this could be interpreted: as globally scoped predicates that have minimal semantic commitment; or as some kind of locally scoped predicates. As shown, it looks like you are treating them as globally scoped.

If they are globally scoped, then inference rules that use them must qualify their intended scope, such as by indicating the class of the subject, as you describe.

If they are locally scoped, then we'll need ways to manipulate scopes, such as we have in programming languages. For example, when a library is imported it pulls a set of identifiers into the current scope, or allows an identifier from a foreign scope to be bound to an identifier in the current scope.

I wonder what other pros and cons there might be of treating them as globally scoped vs locally scoped.

[amirouche]

In my experience 'predicates as strings' is more approachable, and less interoperable.

[HughGlaser]

I think the issue is perhaps tied up with the question of literals as subjects too.
That is issue #21
Note that that issue discusses literals as predicates a bit too.
Of course each of these steps takes RDF further away from Linked Data.
Even so, personally I quite like such relaxation of the URI requirements.

[HolgerKnublauch]

Yes there is some overlap with #21. For many of the customers that we see, the concept of Linked Data is not relevant as they only operate on controlled enterprise graphs. Also I believe even from a Linked Data perspective, having simpler property names shouldn't be a problem because it is far more relevant that the subjects and objects are URIs than the predicate.

[namedgraph]

I don't understand how typing one less character (property instead of :property) can justify thousands of manhours of specification and implementation work this change would incur on the ecosystem.

[amirouche]

Did you consider a mini-rdf on top of what RDF can be implemented?

[HolgerKnublauch]

@namedgraph: I believe one goal of an EasierRDF project is to align better with what most software people are used to. Backward compatibility is desirable but by definition difficult to achieve forever.

In the case of allowing strings as predicates, there is at least one simple approach, namely to convert them into special URIs, allowing existing infrastructure to be re-used without issues - urn:rdfpredicate:firstName

With this approach, the only software changes would be to the Turtle and SPARQL parsers, to convert these strings into special URIs.

[chiarcos]

Another way of implementing this would be to automatically wrap every subject (or predicate) string into a blank node with that exact value. I guess this will be very much hated by most here, but it would have a valid RDF 1.1 interpretation. Am Sa., 25. Nov. 2023 um 11:18 Uhr schrieb Holger Knublauch < ***@***.***>:

…

@namedgraph <https://github.com/namedgraph>: I believe one goal of an EasierRDF project is to align better with what most software people are used to. Backward compatibility is desirable but by definition difficult to achieve forever. In the case of allowing strings as predicates, there is at least one simple approach, namely to convert them into special URIs, allowing existing infrastructure to be re-used without issues - urn:rdfpredicate:firstName With this approach, the only software changes would be to the Turtle and SPARQL parsers, to convert these strings into special URIs. — Reply to this email directly, view it on GitHub <#106 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AATZWSJMABT36NGMTCYFAGTYGHAZDAVCNFSM6AAAAAA7SSEMFCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRWGI3TGMZYGA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[chiarcos]

Am Sa., 25. Nov. 2023 um 12:53 Uhr schrieb Christian Chiarcos < ***@***.***>:

Another way of implementing this would be to automatically wrap every subject (or predicate) string into a blank node with that exact value.

I meant "rdf:value" Message ID: ***@***.***>

…

[namedgraph]

@HolgerKnublauch I disagree. IMO we should make RDF-based software so flexible and powerful (in ways that would be impossible with RDF) so that we can empower the non-software people to work with data in new ways. That is a much broader audience than "software people".

Trying to bring RDF to the general "software people" always ends up in attempts to dumb down RDF, because part of the RDF community seems to think that it's its job to accomodate while the "software people" can't be bothered to put in the effort and learn anything new.

[HolgerKnublauch]

@namedgraph For how many years has the RDF community already tried to convert everyone else, with little success. 20 years now? It remains a niche technology. Maybe success is just around the corner, maybe not.

People coming from other communities just find it alien and too complex. One of the particularly alien concepts is that properties have a global identity. This is basically unknown in any other language. Combine this with the unusual semantics of rdfs:range and rdfs:domain and you can understand why few people want to invest into understanding this stack.

You are saying it would dumb down RDF, but what is actually the value of global identifiers for properties, leaving aside what RDF Schema tried to do: using property definitions to infer the types of subjects and objects without explicitly requiring type triples. What else is there apart from that use case?

[HolgerKnublauch]

Hypothetical syntax that only uses strings in predicate position, while bringing in existing namespace-based predicates:

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix ex: <http://example.org/ns#> .
@alias a: rdf:type .
@alias label: rdfs:label .

ex:JohnDoe
    a ex:Person ;
    label "John Doe" ;
    firstName "John" ;
    lastName "Doe" ;
    age 42 .

[HughGlaser]

A real aside, perhaps:...

I find it gently amusing that the example predicates being used are exactly the ones I would really need to look up (using Linked Data?) to see if I can find out what the author might mean.
I wonder which of firstName and lastName might be a family name, for example?

[HolgerKnublauch]

@HughGlaser not aside at all but important. Like in OWL and SHACL, a property would have its meaning in the context of a class or shape. So in this case, you would look the properties up by following the rdf:type, here ex:Person. It's still linked, self-describing data. This is exactly like you would look up the meaning of fields in a (Java) object or the parameters of a function - you start at the surrounding entity.

[dbooth-boston]

Would all bare predicates then be implicitly scoped to the class of the subject on which they are used? If so, which class if the subject is in multiple classes?