Re: expansion algorithm 5.1.2.7

> On Jun 22, 2018, at 2:40 PM, Dorian Taylor <dorian.taylor.lists@gmail.com> wrote:
> 
> 
>> On Jun 22, 2018, at 2:22 PM, Gregg Kellogg <gregg@greggkellogg.com> wrote:
>> 
>> Any such inference is at the RDFS layer. For processing, you may find it easier to coerce most things to arrays, but that’s up to your implementation.
> 
> Got it. I really should have said something like “term which ought to expand to an IRI which under typical downstream circumstances would be expected to refer to an rdfs:Class or subclass thereof” but I thought it a bit too lawyery. I see that §5.1.2.9.4.4 asserts that the value associated with `@type` should be a string or array of strings.

That’s properly pedantic!

>> Sounds about right.
> 
> Thanks; I think writing out my own bullet-list interpretation also helped me understand what’s going on here. By my reading, if you specify `@type` in a hash/dictionary/whatever, and that type has its own context, then by all rights the other members of the hash should be evaluated with the amalgamation of those contexts. If there is more than one context, then any clobbering that might happen will happen in lexical order.

Yes, although “clobbering” may be a bit harsh, as you wouldn’t normally expect scoped contexts to interfere with each other.

> Does this mean that the keys in the §5.1.2.7 loop should also be sorted lexically?

Yes, keys should be sorted; I thought there was an issue for this, but I don’t see it, nor do I see such text in the spec. In the expansion algorithm, sort expanded values of `@type` lexicographically when applying scoped contexts. In compaction, sort lexicographically on compacted IRI to apply scoped contexts.

I’ll make sure the WG gets an issue for this.

Gregg

> --
> Dorian Taylor
> Make things. Make sense.
> https://doriantaylor.com
> 

Received on Saturday, 23 June 2018 18:17:22 UTC