Rename "RDF*" - avoiding regular expression wildcard in name

[akuckartz]

Copied from w3c/EasierRDF#76

The name "RDF*" has the negative property that it is not just a string, but also a regular expression. Some search engines make it difficult or impossible to search for "RDF*" without interpreting the name as a regular expression.

Some suggestions:

• RDF star
• RDFx

@hartig commented in w3c/EasierRDF#76 (comment)

I don't think it is a good idea to rename RDF* at this point. However, I understand the issue related to search engines. A possible way to address this issue is to include keywords such as "RDF star", "RDFstar", "SPARQL star", etc, in the metadata sections of the documents about the approach; this way, search engine can pick up these keywords and, then, searches for these keywords will end up showing the right hits.

I think it is not to late to rename the specification by replacing "RDF*" with "RDF star". Also:

• Quite a few articles about RDF* already write RDF star instead
• This repository is named rdf-star
• html metadata keywords are almost never provided on the web today and it is questionable that search engines use them
• html metadata keywords can not be provided for PDF files etc.

[abrokenjester]

Freewheeling here: how about "RDF edge properties"?

[HolgerKnublauch]

It probably depends on how close the outcome of this work resembles the original RDF* proposals. RDF* is now an established term but with this comes a long history and that may eventually be misleading.

I do like the idea of naming it after what it really does, as Jeen's Edge Properties (which is a bit long though).

[gatemezing]

I still go for RDF* for the name. However, we can find ways to solve issues with the search engines by adding as much as possible alternative keywords/structured data so as to help them "understand" better.

[VladimirAlexiev]

Rename it to "RDF star". Now is the time.

• Just because RDF* is used in papers does not mean we should perpetuate that unfortunate name . Search for RDF* in Google scholar and Semantic scholar and you'll see what I mean
• we can't use * in Mime types so that's another reason

"Edge properties" does not work. What will we say, "sparql with edge properties" and "sparql results XML with edge properties"? Come on

[HolgerKnublauch]

Historical question: what was the reason/meaning behind the * anyway?

Wouldn't RDF plus be a more meaningful alternative?

[hartig]

@HolgerKnublauch Calling it RDF+ was indeed the first thing that came to my mind when I was looking for a name. However, I quickly dismissed this idea for the following reason. Using the name of some form of language and adding a + to it is something that I have seen being used in the literature to denote some positive fragment of the language (i.e., the language without any features to express negation). I know that RDF is not strictly a language, and it also does not really have negation features, but still, I wanted to avoid giving such signals by using a +. Moreover, SPARQL is a language and it does have negation features; so, to me, the name SPARQL+ would be something that I would introduce when I was to talk about the positive fragment of SPARQL.

Now to the reason behind the *. To me, again in the context of languages, the * indicates some form of recursion or repetition (as in the Kleene Star operator). In this sense, it felt natural to use for an extension of RDF / SPARQL in which triples / triple patterns can be nested.

[HolgerKnublauch]

@hartig thanks for the explanations, which make sense.

This doesn't mean we should give up looking for alternatives. The * makes most sense written as-is because it's the Kleene operator, less so spelled out as "star" which to me can be misinterpreted a bit arrogantly or at least looses the context. Having said this I have no better suggestion at the moment, and there is of course some benefit in continuity.

[pfps]

As far as I can see, Google handles RDF* as well as it handles most other technical names. I don't see why RDF* poses a problem.

[akuckartz]

This is not just about Google.

[pfps]

OK, only 86% about Google.

https://www.statista.com/statistics/216573/worldwide-market-share-of-search-engines/

[blake-regalia]

The * was a mistake, best to get rid of it now. All search engines have problems with "RDF*". I have always had to resort to using "rdf-star" and throwing in more contextual words to get the right hits. I don't care so much what it is called, as long as it does not contain any special characters. Take a moment to reflect on all the libraries, packages, tools, etc., that have special characters in their names. Can't think of any? Well, that's because it's a bad idea.

[akuckartz]

In addition to public Internet search engines there exist other search engines which (even more likely) are having problems with such wildcard queries.

[VladimirAlexiev]

@pfps Search for RDF* in Google scholar and Semantic scholar and you'll see the problem.

It return papers by people named "RDF Harris" and the like.

[TallTed]

(I hadn't reached #20 in my long slog through the work I've missed in the past year (but I had reached a level of frustration during that slog)... the below is moving my thinking over here.)

RDF* is an unsearchable string, but searches for RDF do bring it to light occasionally.

This evening, while searching for something else, I randomly discovered the existence of the RDF# proposal, which led me to the RDF+ proposal (which is no longer at the URL the RDF# paper linked to, this link takes you into the Internet Archive for it).

(I am not prepared to do a full analysis of either of these. I do wonder whether anyone else has done some comparison, and could add such to this repo...)

Unsurprisingly, neither of the others included a searchable version of their name (e.g., rdf-hash, rdf-plus). Being unsearchable might help explain how they remain apparently unpopular. It doesn't do anything to explain the popularity of RDF*, however, which I continue to believe is in desperate need of a renaming.

(What's the next one to be, RDF**? RDF*+#?)

[afs]

The overlap between RDF and RDF* is large. RDF* is a small extension of RDF for certain use cases.

RDF data is RDF* data.

Treating RDF* as different to RDF seems to serve only to confuse.

RDF* should fade as the extension becomes widely implemented. So while the name RDF* may not be ideal, it isn't a crisis.

[TallTed]

I would say, then, that RDF* should be re-proposed as RDF 1.2 or RDF _some extension_ which words might be shortened for use with Turtle, SPARQL, and all the other things which will require similar extension for full interop.

* is just a problem, no matter how you slice it, and star is not much better.

[VladimirAlexiev]

@TallTed There's a separate group discussing SPARQL 1.2 and a whole lot of issues for consideration https://github.com/w3c/sparql-12/issues.
What features will make it into SPARQL 1.2 is not yet known; and probably there will be repos that implement some of them but not rdf-star, and vice versa.
So I don't believe that replacing the RDF* moniker with a SPARQL version number will work.

[TallTed]

@VladimirAlexiev - Yes. You may note that I have commented on a fair number of those "SPARQL 1.2" issues.

Perhaps a new issue should be opened there to consider adding the "RDF-star extension" to SPARQL 1.2 rather than continuing down the path of creating a new SPARQL* based on SPARQL 1.1 such that SPARQL forks into SPARQL-1.1-star and SPARQL-1.2 ...

[akuckartz]

Perhaps a new issue should be opened there to consider adding the "RDF-star extension" to SPARQL 1.2 ...

That somehow was the intent of w3c/sparql-dev#114 ;-)

[afs]

Can we try to conclude this issue?

Proposal: the work of this group is "RDF-star", the motivating original work by Olaf is "RDF*".

[hartig]

Andy's proposal sounds good to me.

Assuming we achieve a consensus on this proposal, a follow-up question for us would then be to decide how the name change would affect the draft spec. Should the name change be reflected only in the titles of the documents, section headers, etc., or should this also result in the renaming of the concepts that currently have the * in their name (i.e., things such as "RDF* triple", "RDF* graph", "BGP*", etc)? ...and if the latter, what would be good naming pattern to use? ("RDF-star triple" look a bit weird to me)

[TallTed]

The lexical "RFD-star" is at least searchable in most environments and by most tools. Same for "RDF-star triple", "RDF-star graph", etc. This does not hold for "RDF*" nor "RDF* anything".

Assuming acceptance of @afs's proposal, I think it must flow through the entirety of this group's output -- especially but not only including all document titles, headings, text, etc.

My concern about effectively forking RDF, and its serializations, and all compliant/supporting implementations, remains strong.

So, this change is better than none -- but I don't believe it will be the end of the matter.

[TallTed]

@hartig commented in w3c/EasierRDF#76 (comment)

I don't think it is a good idea to rename RDF* at this point. However, I understand the issue related to search engines. A possible way to address this issue is to include keywords such as "RDF star", "RDFstar", "SPARQL star", etc, in the metadata sections of the documents about the approach; this way, search engine can pick up these keywords and, then, searches for these keywords will end up showing the right hits.

This deserved an earlier response... It's also important to keep in mind how web-indexers/search-engines (primarily but not only Google) work, and a piece of that is they typically ignore invisible meta-data in favor of human-visible text so the above suggestion will not work as intended. This can partially be overcome by liberal use of embedded JSON data islands -- but that's not easy for most humans to produce and there's really no way to make-it-so anywhere except on our document outputs -- and even there, I'm not sure whether Respec will respect such embeddings.

Bottom line -- "Nope."

[pchampin]

This has been discussed in today's call: https://w3c.github.io/rdf-star/Minutes/2021-02-05.html#item03

[akuckartz]

Closing this issue as the implementation of the decision will be managed in #89

Thanks to all participants in this discussion!