IETF Logo Mail Archive

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

Christian Amsüss <c.amsuess@energyharvesting.at> Wed, 27 January 2016 08:19 UTC

Return-Path: <c.amsuess@energyharvesting.at>
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 210CA1B35DD for <core@ietfa.amsl.com>; Wed, 27 Jan 2016 00:19:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Level:
X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 xKVr_cHby5Z9 for <core@ietfa.amsl.com>; Wed, 27 Jan 2016 00:19:46 -0800 (PST)
Received: from prometheus.amsuess.com (prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EAC01B35DC for <core@ietf.org>; Wed, 27 Jan 2016 00:19:45 -0800 (PST)
Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 9E312419FF; Wed, 27 Jan 2016 09:19:43 +0100 (CET)
Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 952DD2D; Wed, 27 Jan 2016 09:19:42 +0100 (CET)
Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 68D1F2E; Wed, 27 Jan 2016 09:19:42 +0100 (CET)
Received: (nullmailer pid 32680 invoked by uid 1000); Wed, 27 Jan 2016 08:19:41 -0000
Date: Wed, 27 Jan 2016 09:19:41 +0100
From: Christian Amsüss <c.amsuess@energyharvesting.at>
To: Michael Koster <michaeljohnkoster@gmail.com>
Message-ID: <20160127081941.GY7454@hephaistos.amsuess.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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="mFWIsQnH1d6uRhsN"
Content-Disposition: inline
In-Reply-To: <2CD6395A-0B3B-4C48-B173-14FF8A90C2F0@gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/2k2W_CT9EQBfQJRwypYtdEdONbo>
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 08:19:48 -0000

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).

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