Naming issues / conflicts / duplicate services

[LVerneyPEReN]

Hi,

It seems there are a few naming issues with the recent import of tosback data.

For instance, there is both a Google Play and a Play service which seems to identify the same actual service : https://github.com/ambanum/OpenTermsArchive/blob/master/services/Play.json vs https://github.com/ambanum/OpenTermsArchive/blob/master/services/Google%20Play.json.

Also, it is not clear to me what the correct naming should be for such services. Some are prefixed with the parent platform, some are not. For instance Stadia which I would have expected to be Google Stadia : https://github.com/ambanum/OpenTermsArchive/blob/master/services/Stadia.json.

Thanks!

EDIT Same for Alexa / Amazon Alexa

[clementbiron]

Thank you for pointing out these naming conflicts.

According to the Google Play about page service name is Google Play not Play. I'm not very comfortable with the mechanics of importing and the implications it may have, so @martinratinaud do you think we can delete Play.json file ? (before copying "importedFrom": "https://github.com/tosdr/tosback2/blob/f762cd4bbb2571272985fed009201a23300ba9b2/rules/play.google.com.xml", to Google Play.json)

I think Stadia service is well named because it's branded Stadia as you can see in the ToS but it might be useful to use the same naming convention as the other Google services. @MattiSG what do you think ?

Alexa is branded as Alexa (also see the ToS) not Amazon Alexa. But we can ask ourselves the same question as for Stadia.

Have you read the section of the condtribution guide which explains well how to name services ? Also, check out the wiki about this.

We will probably organize a contribution evening in next november during the "Mois de l'innovation publique de la DITP", and it would be great to meet there?

[LVerneyPEReN]

We will probably organize a contribution evening in next november during the "Mois de l'innovation publique de la DITP", and it would be great to meet there?

Sure, let me know about it and happy to meet there!

[martinratinaud]

@clementbiron @LVerneyPEReN I think I'm not the best person to answer this question but if I were to be asked, I'd say it will raise problems. All history will be associated to "Play" and not "Google Play" so it would need an history rewrite.

Maybe @Ndpnt can confirm?

[Ndpnt]

Hi,

According to the Google Play about page service name is Google Play not Play.

So like @clementbiron said, the service is naming itself Google Play, thus we should name it the same way.

I think Stadia service is well named because it's branded Stadia as you can see in the ToS but it might be useful to use the same naming convention as the other Google services.

For the same reason, Stadia should be named Stadia and not Google Stadia. The naming convention here is consistent, as the idea is not to prefix all the time the service name with parent platform but to stick to the actual service name.

Alexa is branded as Alexa (also see the ToS) not Amazon Alexa. But we can ask ourselves the same question as for Stadia.

Same here, Alexa is the actual service name.

Have you read the section of the condtribution guide which explains well how to name services ? Also, check out the wiki about this.

Yep, we try to explain that in these two documents, but maybe it is not clear enough?

[Ndpnt]

@clementbiron @LVerneyPEReN I think I'm not the best person to answer this question but if I were to be asked, I'd say it will raise problems. All history will be associated to "Play" and not "Google Play" so it would need an history rewrite.

Maybe @Ndpnt can confirm?

Yep, it would need an history rewrite.

[LVerneyPEReN]

The naming convention here is consistent, as the idea is not to prefix all the time the service name with parent platform but to stick to the actual service name.

Ok but I feel like this limits discoverability and put quite a lot of constraints on some (re)use cases.

Typically, one might want to have a longitudinal analysis of terms across various services of a single platform. This requires maintaining a list on the side and pointing to the right terms folders. Additionnally, some terms might apply "per platform" (ie per owner) and not "per service". Would they be duplicated in each relevant service?

A tree-like structure might actually be closer to the administrative reality here, and better for later uses.

For my typical use case, I should only focus on services owned by an online platform. I want to have a clear view of added/removed services in this field and of any changes in terms for these services (and only these ones).

My solution so far is to maintain a JSON tree doing the mapping, something like:

"Owner": {
                "Service Name": {
                        "_ota_service": "Chrome and Chrome OS.json"
                },
                ...
}

but it is quite fragile :/

[MattiSG]

The documentation on how to name services can always be improved. Following https://github.com/OpenTermsArchive/engine/issues/995, it is in the docs repository 🙂

A formal RFC for a naming scheme could also be accepted, if the problem statement can be refined 🙂

As for the existing conflicts listed in this issue, they should be addressed directly in the contrib collection.

For triaging purposes, I close this issue as it stands since it does not reflect the current repository setup.