gw and hyf context why "@type": "@id" for classes aliases?

[sgrellet]

After discussion with Abdel, we don't understand why we keep repeating "@type": "@id" for each elementwe declare in both those contexts

example "HY_Catchment": { "@id": "hyf:HY_Catchment", "@type": "@id" },

[dblodgett-usgs]

I copied that from the example contexts I think. Is that not correct?

[sgrellet]

looks weird to us as, usually the @type that goes along the @id is to provide the type of what is at the other end of the @id (URI). and hyf:HY_Catchment is not of type @id. Either we put some IT oriented type (we point at an owl:Class or a skos:Concept) or leave it or ... ? @afeliachi was in favour of dropping it

[lieberjosh]

The @id’s are on different sides of the colon

"@id https://github.com/id": "hyf:HY_Catchment” means HY_Catchment: replaced by hyf:HY_Catchment: (an IRI) "@type https://github.com/type": "@id https://github.com/id” means the string assigned to hyf:HY_Catchment should also be an IRI, e.g.

-> “IRI”: “IRI”

"hyf:HY_Catchment": "https://opengeospatial.github.io/ELFIE/usgs/nhdplusflowline/huc12obs/070900020601.geojson https://opengeospatial.github.io/ELFIE/usgs/nhdplusflowline/huc12obs/070900020601.geojson"

—Josh

On Feb 21, 2018, at 5:04 PM, sgrellet notifications@github.com wrote:

After discussion with Abdel, we don't understand why we keep repeating "@type https://github.com/type": "@id https://github.com/id" for each elementwe declare in both those contexts

example "HY_Catchment": { "@id https://github.com/id": "hyf:HY_Catchment", "@type https://github.com/type": "@id https://github.com/id" },

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/opengeospatial/ELFIE/issues/160, or mute the thread https://github.com/notifications/unsubscribe-auth/AExWhniSgbaPFkt-5wpJuU98zhy90yl8ks5tXJMJgaJpZM4SOaGg.

[lieberjosh]

On Feb 21, 2018, at 5:45 PM, Joshua Lieberman jlieberman@tumblingwalls.com wrote:

The @id’s are on different sides of the colon

"@id https://github.com/id": "hyf:HY_Catchment” means HY_Catchment: replaced by hyf:HY_Catchment: (an IRI) "@type https://github.com/type": "@id https://github.com/id” means the string assigned to hyf:HY_Catchment should also be an IRI, e.g.

-> “IRI”: “IRI”

"hyf:HY_Catchment": "https://opengeospatial.github.io/ELFIE/usgs/nhdplusflowline/huc12obs/070900020601.geojson https://opengeospatial.github.io/ELFIE/usgs/nhdplusflowline/huc12obs/070900020601.geojson”

or verbosely "hyf:HY_Catchment": {“@id”: "https://opengeospatial.github.io/ELFIE/usgs/nhdplusflowline/huc12obs/070900020601.geojson https://opengeospatial.github.io/ELFIE/usgs/nhdplusflowline/huc12obs/070900020601.geojson”}

—Josh

On Feb 21, 2018, at 5:04 PM, sgrellet <notifications@github.com mailto:notifications@github.com> wrote:

After discussion with Abdel, we don't understand why we keep repeating "@type https://github.com/type": "@id https://github.com/id" for each elementwe declare in both those contexts

example "HY_Catchment": { "@id https://github.com/id": "hyf:HY_Catchment", "@type https://github.com/type": "@id https://github.com/id" },

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/opengeospatial/ELFIE/issues/160, or mute the thread https://github.com/notifications/unsubscribe-auth/AExWhniSgbaPFkt-5wpJuU98zhy90yl8ks5tXJMJgaJpZM4SOaGg.

[afeliachi]

Actually HY_Catchment is class. Declaring it this way confuse it with properties. That's what @sgrellet is talking about here. I edited the title to be more explicit.

[lieberjosh]

The JSON-LD processor should not be confused, but perhaps the reader of the shorthand version might be.

On Feb 21, 2018, at 5:52 PM, afeliachi notifications@github.com wrote:

Actually HY_Catchment is class. Declaring it this way confuse it with properties. That's what @sgrellet https://github.com/sgrellet is talking about here. I edited the title to be more explicit.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/opengeospatial/ELFIE/issues/160#issuecomment-367505046, or mute the thread https://github.com/notifications/unsubscribe-auth/AExWhuGyxefAeoioViMKOEst1vKDisSlks5tXJ4ngaJpZM4SOaGg.

[afeliachi]

yes absolutely, it is syntactically correct for the processor, and for a reader it is confusing, But shouldn't we differentiate between classes(or types) and properties when declaring aliases in the context files so they would not be misused?

[dblodgett-usgs]

So... what should we do with this? Someone make a decision and implement the fix. Please?

[abhritchie]

Sorry, not sure why this was closed ...

[abhritchie]

How's this for a decision? Notwithstanding the fact that the value of aliasing classes in contexts not clear, to be consistent with the original elf-* JSON-LD contexts and example documents, and also to minimise the size of the contexts and their potential to confuse:

1. Classes should not be be declared in context documents and instead be encoded as Compact IRIs in @type values in data objects.
2. Compact IRI (CIRIE?) namespaces are declared in the context.
3. Properties should be declared in context documents.
4. Context bindings should be simple strings, e.g "key" : "compact:iri". (See issue #161.)

For hyf.jsonld the result would be to keep the 'hyf' namespace binding, remove all the HY_* class bindings and to simplify the property bindings:

{
    "@context": {
        "hyf": "http://opengeospatial/def/ontology/hyf",
        "upstreamWaterBody": "hyf:upstreamWaterBody",
        "downstreamWaterBody": "hyf:downstreamWaterBody"
    }
}

Resulting data object:

{
    "@context": [
        "elf-contexts",
        "https://opengeospatial.github.io/ELFIE/json-ld/hyf.jsonld"
    ],
    "@id": "https://data.elfie.ogc/id/some/soggy/thing",
    "@type": "hyf:HY_Catchment",
    "name": "Catchy McCatchmentFace",
    "realizedCatchment": "https://data.elfie.ogc/id/someother/soggy/thing"
}

[abhritchie]

Is this:

1. Acceptable;
2. Too disruptive to the code you've written?

I'm happy to update all of the contexts for consistency if we agree.

[dblodgett-usgs]

This is acceptable to me, yes. My one naive questions is, if the classes aren't listed in the context, how would we expect a client to know about them and their validity in the context of a given JSON-LD document?

[lieberjosh]

It’s certainly possible to overthink this. Contexts are not schemas, just aliasing devices with a few shortcuts like @container, @id, etc. Any real attempt to use them as schemas is going to be arbitrary and unsatisfactory. The best they can do is make JSON- LD documents more compact, give a sense of available entities, and point to actual schemas such as ontologies.

Josh

[dblodgett-usgs]

I'm not really following how this answers the question. I thought that, as you say we, could use contexts to "give a sense of available entities".

[afeliachi]

I tend to join @dblodgett-usgs on this matter. If we want the contexts to be the reference to what could be used by a client, without expecting them to lookup the original vocabularies, I think declaring terms for classes remains important. @lieberjosh contexts are certainly not schemas, but IMHO since we're binding them to real ontologies, it is important to keep some consistency, especially that we expect that the data would be consumed as Linked data. By looking at the practice of some contexts such as schema.org context (for instance), classes terms are declared simply by specifying their relative or direct IRI (equivalent to the @id part only).

I suggest something as simple as this:

{
    "@context": {
        "hyf": "http://opengeospatial/def/ontology/hyf",
        "HY_Catchment": "hyf:HY_Catchment",
        "upstreamWaterBody": "hyf:upstreamWaterBody",
        "downstreamWaterBody": "hyf:downstreamWaterBody"
    }
}

Resulting data object:

{
    "@context": [
        "elf-contexts",
        "https://opengeospatial.github.io/ELFIE/json-ld/hyf.jsonld"
    ],
    "@id": "https://data.elfie.ogc/id/some/soggy/thing",
    "@type": "HY_Catchment",
    "name": "Catchy McCatchmentFace",
    "realizedCatchment": "https://data.elfie.ogc/id/someother/soggy/thing"
}

[lieberjosh]

As far as I can tell, this is exactly what I was suggesting the contexts be limited to. I would suggest, however, that whatever practice of interpreting contexts is adopted here, be written down since there isn’t really a consistency of practice to go by.

[abhritchie]

I'll update the contexts according to @lieberjosh and @afeliachi's proposal. With a note that I'm doing it with a degree of concern that while the result is fine our logic isn't.

[sgrellet]

Great that we come to an 'agreement' on this. Yes, we will have to document this in the ER. But we have elements from the issues (ex : also in #68 )

[afeliachi]

A final solution should take into account the question of type coercion (#161).

[dblodgett-usgs]

I think this is done? Can @abhritchie @afeliachi and others confirm and close.