-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rename "RDF*" - avoiding regular expression wildcard in name #20
Comments
Freewheeling here: how about "RDF edge properties"? |
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). |
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. |
Rename it to "RDF star". Now is the time.
"Edge properties" does not work. What will we say, "sparql with edge properties" and "sparql results XML with edge properties"? Come on |
Historical question: what was the reason/meaning behind the * anyway? Wouldn't RDF plus be a more meaningful alternative? |
@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. |
@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. |
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. |
This is not just about Google. |
OK, only 86% about Google. https://www.statista.com/statistics/216573/worldwide-market-share-of-search-engines/ |
The |
In addition to public Internet search engines there exist other search engines which (even more likely) are having problems with such wildcard queries. |
@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. |
(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, |
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. |
I would say, then, that
|
@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. |
@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 ... |
That somehow was the intent of w3c/sparql-dev#114 ;-) |
Can we try to conclude this issue? Proposal: the work of this group is "RDF-star", the motivating original work by Olaf is "RDF*". |
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) |
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. |
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." |
This has been discussed in today's call: https://w3c.github.io/rdf-star/Minutes/2021-02-05.html#item03 |
Closing this issue as the implementation of the decision will be managed in #89 Thanks to all participants in this discussion! |
Copied from w3c/EasierRDF#76
@hartig commented in w3c/EasierRDF#76 (comment)
I think it is not to late to rename the specification by replacing "RDF*" with "RDF star". Also:
RDF*
already writeRDF star
insteadrdf-star
The text was updated successfully, but these errors were encountered: