context clobbers geo: URL scheme

[VladimirAlexiev]

The same issue as lanthaler/vCardOntology#1 applies here.
When you define "geo" as a term in a context, you clobber the absolute geo: URI scheme.
I haven't found all places where this happens, but here are some in this repo:

• contexts/place: "geo": "http://schema.org/geo"
• various examples incl http://json-ld.org/spec/latest/json-ld/#h-advanced-context-usage eg28

[gkellogg]

The ability to re-define terms is a feature, not a bug. In this regard, it's not unlike the scoping of variables in modern programming languages.

Please provide the corrective action you believe is necessary, or close the issue if you're satisfied with this response.

[gkellogg]

Further more on your issue, this is not unlike defining an http or https term, which can have the same behavior. You can always undefine a term in a more local context as follows:

{
  "@context": {
    "geo": null
  }
}

[VladimirAlexiev]

Let me ask this: would you be happy if W3C published ANY context officially that included terms http, file or mailto? How's the geo URI scheme inferior to those three?

scoping of variables in modern programming language

Yes, JSONLD terms and Turtle prefixes are similar to local var names. But they are more, since you cannot practically work with full URLs without giving them names (prefixes).

• Standardizing those names is a GOOD THING, eg @cygri's http://prefix.cc does that for RDF prefixes.
• Publishing official JSONLD contexts is a GOOD THING, and is almost necessary for making interoperable JS code that works with those JSONLDs.

The problem is that @lanthaler's vcard and @danbri's schema contexts have gone too far: instead of writing "vcard:geo" and "schema:geo", they facilitate the JS programmers to write just "geo". But that is ambiguous:

• it clashes with the geo: URI scheme
• it clashes with the vcard and schema understanding of that term

http://prefix.cc doesn't make such mistake because it introduces short names only for whole ontologies (or classes of resources), but not for specific terms within.

• eg dbr: is http://dbpedia.org/resource/
• eg dbc: is http://dbpedia.org/resource/Category:
• but it would not accept eg sofia: for http://dbpedia.org/resource/Sofia (and it would be silly to ask for such name to be added)

So the vcard and schema contexts are not anymore usable globally: you cannot use them together, or which one wins is dependent on the order you include them. I guess people could fix such bugs by overriding as you propose, but why make bugs in the first place?

Corrective actions:

• small one: remove geo from the context
• big one: do not use colon-less terms for properties or classes. schema:geo and schema:Person are good, geo and Person are bad. But this is a BIG change from Schema's philosophy of making it simple for webmasters to publish data, and I don't think @danbri would agree

[VladimirAlexiev]

would be silly to ask for such name to be added

Because for me Sofia could mean my city, but for an Italian ski fan it could mean Sofia Goggia.

IMHO we should aim for globally shared names only of big things (ontologies) not the things inside (properties)

[niklasl]

A partial defense here is that we included a limitation on prefix expansion in JSON-LD so that protocols followed by "://" do not get expanded even if there is a term defined that equals the protocol. From the spec [1]: Prefixes are expanded when the form of the value is a compact IRI represented as a prefix:suffix combination, the prefix matches a term defined within the active context, and the suffix does not begin with two slashes (//). Therefore identifiers that are hierarchical IRIs, such as those beginning with "http://" and "https://", *will not* be changed even if there are "http" and "https" terms defined in a context. (This was originally deviced for CURIEs in RDFa 1.1 [2]). However, this does not help "geo:" and other non-hierarchical schemes (such as "mailto:"). I do see the cognitive cost of using other's contexts and not being sure if a protocol is overshadowed by a term there (since even it it is missing now, it could be added in the future). This is only an issue for non-hierarchical IRIs of course, and Gregg is absolutely right that if you use external contexts *and* non-hierarchical protocols, you can "protect" them by re-declaring the relevant terms. Still, it does seem rather cumbersome to have to use e.g.: "@context": ["https://schema.org", {"hasGeo": "schema:geo", "geo": null}] for such geo data. I do not know how common that needs to be though. I recall a suggestion I had long ago that would allow terms to be defined ending with ":" to be treated specifically as prefix tokens, to distinguish between those and regular terms. It's probably not the best concrete design for such a purpose, but we might want to revisit such a course if this situation is considered too troublesome. An alternative design could treat terms as prefix declarations if the bound value ends with one of the reserved (gen-delims / sub-delims) of RFC 3987 [3]. Note that in either case, this mechanism would separate prefix and non-prefix terms internally, and never use the latter for prefix expansion. AFAIK, there is little to no value in having prefix and term declarations occupy the same space, other than (authoring) convenience. A rule that treated them as separate (somehow) might be beneficial. If there are really cases in the wild where a term is sometimes used as a prefix and sometimes just as a term, we need to make the mechanism explicit (such as requiring prefix terms to be declared with the colon included (a bit ugly), or e.g. using this delim-rule). I can see how this wouldn't be the easiest thing to accept. I just like us to consider the consequences either way. Best regards, Niklas [1]: https://www.w3.org/TR/json-ld/#compact-iris [2]: https://www.w3.org/TR/rdfa-syntax/#s_curies [3]: https://tools.ietf.org/html/rfc3987

…

On Fri, Mar 10, 2017 at 10:22 AM, Vladimir Alexiev ***@***.*** > wrote: would be silly to ask for such name to be added Because for me Sofia could mean my city, but for an Italian ski fan it could mean Sofia Goggia. IMHO we should aim for globally shared names only of big things (ontologies) not the things inside (properties) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#469 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAB0a_s2ad4kyWapNHNLAHZj-EdK3s28ks5rkRZGgaJpZM4MXnbW> .

[gkellogg]

I recall a suggestion I had long ago that would allow terms to be defined ending with ":" to be treated specifically as prefix tokens, to distinguish between those and regular terms. It's probably not the best concrete design for such a purpose, but we might want to revisit such a course if this situation is considered too troublesome.

I think that ship has sailed, and there is too much deployed JSON-LD to make such a breaking change.

An alternative design could treat terms as prefix declarations if the bound value ends with one of the reserved (gen-delims / sub-delims) of RFC 3987 [3]. Note that in either case, this mechanism would separate prefix and non-prefix terms internally, and never use the latter for prefix expansion.
AFAIK, there is little to no value in having prefix and term declarations occupy the same space, other than (authoring) convenience. A rule that treated them as separate (somehow) might be beneficial. If there are really cases in the wild where a term is sometimes used as a prefix and sometimes just as a term, we need to make the mechanism explicit (such as requiring prefix terms to be declared with the colon included (a bit ugly), or e.g. using this delim-rule).

While this could cause some havoc, I think the use of compact IRIs is limited enough that such a restriction could work. For clarification, these delimiters are the following:

  gen-delims     = ":" / "/" / "?" / "#" / "[" / "]" / "@"
   sub-delims     = "!" / "$" / "&" / "'" / "(" / ")"
                  / "*" / "+" / "," / ";" / "="

(We could probably restrict it to "/" and "#" and be good too).

This would also help address the problem of terms being used for prefix definitions that #405 was attempting to address.

This would solve the problem with this particular definition: "geo": "http://schema.org/geo", as it does not end in such a delimiter. This doesn't help the "http" standard prefix: http http://www.w3.org/2011/http#, but as @niklasl points out, this is a hierarchical scheme, where we have separate tests.

I suggest we add this as a 1.1 feature. Note that this won't affect existing contexts, and the problem noted by @VladimirAlexiev is real, but not one that can be addressed in JSON-LD 1.0. The change must come from the context publishers. It is unfortunate that "geo" is used as a term in schema.org that conflicts with the URI scheme, but any change must happen there.

I'll update #405 to add further restrictions to simple terms to make them eligible for being used as Compact IRI prefixes.

[VladimirAlexiev]

If I am in http://example.com/some-file.html perhaps https:another-file.html is a reasonable use of relative URL (and the way I read https://en.wikipedia.org/wiki/Uniform_Resource_Locator, there's no need for slashes, but I may be wrong).

Please comment on:

do not use colon-less terms for properties or classes
I think for Schema and IIIF this ship has sailed (they won't change their practice), but maybe it's a good principle for future context creators.

@azaroth42 : IIIF is fond of calling dct:conformsTo simply profile, and there's zero chance that would change, right?

[azaroth42]

To answer the question ... yes, zero chance that will change.

We considered this and, as per the responses above, found that the likelihood of a profile:// URI appearing anywhere near our context was very close to zero, and combined with the ability to unset prefixes as demonstrated, meant we were satisfied with leaving it. We made a script to check the contexts that we haven't inadvertently done it again though, as we did recognize the issue.

We recommend against using relative URIs. The only real value is if you move your URIs around, and that's a bad practice anyway. Any savings in terms of representation length is solved more easily by the good practice of transport level compression.

[azaroth42]

See this thread: https://lists.w3.org/Archives/Public/public-linked-json/2015Dec/0004.html

[VladimirAlexiev]

The above is about ActivityStreams clobbering the tag: URI scheme https://tools.ietf.org/html/rfc4151.

I agree I wouldn't often use relative HTTP URIs, though the saving is not in doc length but in maintainability (you can rehost the doc without changes).

I think the important point of this discussion is that IMHO contexts should use names-with-colon for properties and classes, not bare names. Eg

• "iiif:profile" makes it more clear that is IIIF's idea of what a profile is (namely dct:conformsTo)
• "exif:height" makes it clear that is the EXIF property of that name.

The IIIF context is very well put together and convenient for devs. But it has many conflicts with the Schema context so the two cannot be easily used together. But maybe I'm wrong... I can still use "exif:height" vs "schema:height", and avoid using the conflicted term "height", right?

[azaroth42]

Using just prefixes completely misses the main value of JSON-LD -- that its context indirection allows the creation of APIs out of LOD that developers find easy to understand and use. It is explicitly to be convenient for developers that means developers use it to build products without worrying about the underlying model at all. I doubt very much you will find anyone at all who thinks that abandoning the primary and many-times-demonstrated advantage of JSON-LD is a good idea.

And yes, you can use exif:height, schema:height as keys if you wish. Even the full URI if you want.

[VladimirAlexiev]

The tel: URL scheme is also broken in vcard, see this thread https://twitter.com/ontotext/status/844156511811223552.

build products without worrying about the underlying model

Seems to me that clobbering two URL schemes, one of them widely used, brings trouble for devs, rather than making their lives easier.