IETF Logo Mail Archive

Re: [core] SenML and link-format in RDF (was: Re: Designs to resolve streaming issues in SenML)

Michael Koster <michaeljohnkoster@gmail.com> Wed, 27 January 2016 18:54 UTC

Return-Path: <michaeljohnkoster@gmail.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5DD01B2B3B for <core@ietfa.amsl.com>; Wed, 27 Jan 2016 10:54:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level:
X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, WEIRD_QUOTING=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1ZGyr9xZWmR for <core@ietfa.amsl.com>; Wed, 27 Jan 2016 10:54:04 -0800 (PST)
Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A79B61B2B3A for <core@ietf.org>; Wed, 27 Jan 2016 10:54:04 -0800 (PST)
Received: by mail-pa0-x22e.google.com with SMTP id uo6so9136521pac.1 for <core@ietf.org>; Wed, 27 Jan 2016 10:54:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=GXyfuS18WxvpAcxbkWDMkEK1XvgNBM+DxqdN3cnkNxo=; b=lI6gSyIqW1+a0eMgCXmbNks5U+q0D/PdqHuEfGWypAR0XOQe2un437zcuIs4VG++WY xhc00qrig4VvspUDfVk4dJcaDvMQP4ZnyzpVc9WvLG/ja911YCQ92xPFsHAiP2F32tSC 6bMkEKcf+xuA2dykxlruDQmw8P4McItQqJs9Ys/3e4xJ4FxuRRN0RUVhzpVQVMNqc3Uz b/IwR5mnKc41Sb1dZajCWNI5eJuudMM54OEm1Ypc2uLpGYqbbn1jJ3/lHf0Fg7APASyb w9QzQ9X762DuJVnYWxbko2NZ8bjG5ewjSXtzDv6PK8qAdSQ+UZpPeH/kItKwYrwx405U IpBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=GXyfuS18WxvpAcxbkWDMkEK1XvgNBM+DxqdN3cnkNxo=; b=Zr1LljcBfXVVdRnltbkVEQX1Pk69ZlpdQ3e8OJuPE8FmB9Mzv1da4tAVxQwlXDCo6F Rrenm9W30rWwiLumCyFo0028OenG1jURGsH/1iD2DPMLR3wFzsRdksprCBDIc9cbu1wV 2GVR2zmpoFZ2xyi4y90DCy1AOkAA5heUIzQXkE8kXdinq6Q5JoBwgdTqYqVFIniz0d8d 0ENc8H9dcxWY+B30JiGCArYhMurC78DIQx0d2TVW4Xa7hv8bZ7f4621apJeToQI14V/w wj2o+aK6URkva95WoTm+FTYn56N/tPZtjOsFTpBIjCiteKCCpW+HzHfjFgTDHnZRYSso oyGw==
X-Gm-Message-State: AG10YOT7t4ZajQqsIgoIXYKgcBXgJ4TGQJIVXXdYZHMQYYPfZBzmW3nQ1syQJoM1VT5Tfw==
X-Received: by 10.66.102.106 with SMTP id fn10mr45345059pab.60.1453920844358; Wed, 27 Jan 2016 10:54:04 -0800 (PST)
Received: from [172.27.14.129] (58-97-125-4.static.asianet.co.th. [58.97.125.4]) by smtp.gmail.com with ESMTPSA id dg1sm10745875pad.18.2016.01.27.10.54.02 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jan 2016 10:54:03 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_E8AFC253-260F-42D4-AE5F-65B19A80DF95"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Michael Koster <michaeljohnkoster@gmail.com>
In-Reply-To: <C9B07CA3-EAE9-45B9-AA2F-8A769C782A40@gmail.com>
Date: Thu, 28 Jan 2016 01:54:00 +0700
Message-Id: <E95D553E-0E70-4125-AA9A-46504574D0BE@gmail.com>
References: <20160118110500.GA7789@hephaistos.amsuess.com> <1B2E05E6-1FA3-4AC4-95ED-E6045B6F94E0@gmail.com> <20160118165811.GF7454@hephaistos.amsuess.com> <EDC3E5A7-1577-4E03-8376-8766A1A65064@gmail.com> <20160126120126.GD7789@hephaistos.amsuess.com> <E9C89242-C1D4-4426-B018-566FA2FC35BC@gmail.com> <20160126164036.GE7789@hephaistos.amsuess.com> <786991F1-1E38-4337-BCB8-C6D6D0E6092C@gmail.com> <20160127070519.GF7789@hephaistos.amsuess.com> <2CD6395A-0B3B-4C48-B173-14FF8A90C2F0@gmail.com> <20160127081941.GY7454@hephaistos.amsuess.com> <C9B07CA3-EAE9-45B9-AA2F-8A769C782A40@gmail.com>
To: Christian Amsüss <c.amsuess@energyharvesting.at>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/DQY4a1lhhXgcW5jVVb4QMq8HGN4>
Cc: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, core <core@ietf.org>
Subject: Re: [core] SenML and link-format in RDF (was: Re: Designs to resolve streaming issues in SenML)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Jan 2016 18:54:07 -0000

Excuse me, I was wrong. On reading the draft https://tools.ietf.org/html/draft-ietf-core-links-json-04 <https://tools.ietf.org/html/draft-ietf-core-links-json-04>
there is clear normative text in the draft that requires multiple valued parameters to be represented as 
JSON arays (sec 2.2):

   If a Link attribute ("parmname") is present more than once in a
   "link-value", its values are then represented as a JSON array of JSON
   string values; this array becomes the value of the JSON name/value
   pair where the attribute name is the JSON name.  Attributes occurring
   just once MUST NOT be represented as JSON arrays but MUST be directly
   represented as JSON strings. 

There is no example of this in the draft, nor is there a formal syntax production to show it, but the text is clear.

Sorry for the confusion.

Michael

> On Jan 27, 2016, at 6:24 PM, Michael Koster <michaeljohnkoster@gmail.com> wrote:
> 
> 
>> On Jan 27, 2016, at 3:19 PM, Christian Amsüss <c.amsuess@energyharvesting.at> wrote:
>> 
>> On Wed, Jan 27, 2016 at 02:32:15PM +0700, Michael Koster wrote:
>>>> That, and string splitting (when it comes to parsing the "l" entries'
>>>> "rt" attributes).
>>> 
>>> I don't see where any string splitting is needed. The "l" entries are all JSON parseable, as are the rt attribute values.
>> 
>> The rt and if attributes of application/link-format requires that all
>> resource types assigned to a resource be stored in a single rt=""/if=""
>> attribute in a space separated fashion (rfc6690 3.1, as is also the case
>> for rel per rfc5988), and draft-ietf-core-links-json-04 makes no attempt
>> to split those up (2.2).
>> 
> 
> Oh, I see. I think this is an omission in the document. As I understand, it is the 
> intention for the JSON serialization of links with multiple attribute values to use 
> JSON arrays to represent those values.
> 
> I will discuss with the draft editor and confirm this.
> 
> My examples are built from JSON serializations that use array type to represent 
> multiple attribute values.
> 
>> If resource types were to be used in a way they can be queried in an RDF
>> context, the statements produced from <x>;if="core.s some.delayable"
>> should at least contain[1]
>> 
>> <x> <http://thingschema.org/schema#if> <http://thingschema.org/if#core.s> .
>> <x> <http://thingschema.org/schema#if> <http://thingschema.org/if#some.delayable> .
>> 
>> because a statement like
>> 
>> <x> <http://thingschema.org/schema#if> "core.s some.delayable" .
>> 
>> would again mean shifting the load of string parsing into the RDF
>> domain, where the expectation is that reasoning can be done based on URI
>> metadata and not on string parsing. (Again, the analogy of the
>> relational database comes into my mind: You wouldn't want to have
>> resource types you'll query for in a space-separated text field of a
>> database).
>> 
>> Also, again drawing the parallel to RDFa, when this HTML document
>> test.html is parsed as RDFa (eg. using the rapper tool that is aware of
>> the registered describedby relationship)
>> 
>> <html prefix="demo: http://example.com/demo"><link rel="demo:next describedby unspecified" href="./next-address" /></html>
>> 
>> then the resulting statements are
>> 
>> <./test.html> <./unspecified> <./next-address> .
>> <./test.html> <http://example.com/demo#next <./next-address> .
>> <./test.html> <http://www.w3.org/2007/05/powder-s#describedby> <./next-address> .
>> 
>> 
>> Best regards
>> Christian
>> 
>> 
>> [1] If it turns out that JSON-LD is unsuitable for this task anyway, as
>> I have the impression which I'm trying to convey, then I'd even propose
>> introducing URI CURIEs into link-format, so we have strong meaning for
>> some.temperature:
>> 
>> <http://example.org/some/v1#>,rel="ns",curie="some";
>> <x>;if="core.s some.delayable";rt="some.temperature"
>> 
>> would be interpreted (for a predefined meaning of core) as
>> 
>> <x> <http://thingschema.org/schema#if> <http://thingschema.org/core#s> .
>> <x> <http://thingschema.org/schema#if> <http://example.org/some/v1#delayable> .
>> 
>> but details of that are for if and when it turns out that I am right
>> about JSON-LD's applicability.
>> 
>> -- 
>> Christian Amsüss                      | Energy Harvesting Solutions GmbH
>> founder, system architect             | headquarter:
>> mailto:c.amsuess@energyharvesting.at  | Arbeitergasse 15, A-4400 Steyr
>> tel:+43-664-97-90-6-39                | http://www.energyharvesting.at/
>>                                     | ATU68476614
>

v2.27.8 | Report a Bug | By Email | System Status