Re: Stream-based processing!?

On 10/02/2011 04:33 PM, Markus Lanthaler wrote:
>>> I wanted to ensure that conversion to RDF processing was able to be
>>> performed as a one-pass process [...]
>>> one-pass. I called this stream-based processing, but perhaps we should
>>> re-name it to one-pass processing. What word captures the requirement
>>> that conversion to RDF only requires one pass and a very small memory
>>> footprint?
>
> I think one-pass conversion to RDF would be much better, yes.

Okay, I'll try to remember to change it in the spec on the next editing 
pass.

>>> We could also require serializations ensure that @context is listed
>>> first. If it isn't listed first, the processor has to save each
>>> key-value pair until the @context is processed. This creates a memory
>>> and complexity burden for one-pass processors.
>
> Agree. I think that would make a lot of sense since you can see the context
> as a kind of header anyway.

Yes, but the key word here is "require" - a JSON-LD document would be 
invalid if the @context was placed anywhere but the first key in the 
JSON object. I think this is going too far, even though it makes 
implementations easier. People writing JSON-LD processors may not always 
have access to the serialization mechanism. That is, I don't think we 
could use most JSON serialization libraries across implementation 
languages to ensure @context is listed first. This could end up 
requiring JSON-LD serialization writers to roll their own, which would 
probably hurt adoption.

It would probably be better to make the SAX-based implementations cache 
items until they see both @context and @subject than to require all 
authors to express their JSON-LD in a particular way that requires them 
to understand how JSON-LD processors work.

>> I can go along with requiring @context to be listed first in a
>> serialization of JSON. But if we're going to say that, we should also
>> say that @subject (were we going change it to just @iri?) MUST also
>> precede other key/value pairs. @subject is also required to generate
>> triples and should therefore precede any other uses of it. We could
>> then infer that if a key is found which is not @context or @subject,
>> that it represents an unlabeled node.
>
> I think that goes too far. I see the context as a header as said above but I
> wouldn't like to have to worry about the order of other elements.

I agree. In fact, I don't think that @context should even be required to 
be the first element for the reasons listed above. The only people it 
would help are the SAX-like JSON-LD processor implementers... and that 
lot is already masochistic as it is... they'd probably revel in the 
challenge. :P

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Standardizing Payment Links - Why Online Tipping has Failed
http://manu.sporny.org/2011/payment-links/

Received on Sunday, 2 October 2011 20:44:49 UTC