On Sun, Aug 24, 2014 at 10:51 PM, eberhard speer jr. <[email protected]> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Werner, > > please note I'm talking about the 'response' to a request [1] : these > are not properties as such in the DDR but properties to be added to > the response from a DDR, and thus should be defined. > > So you mean the "client" not the data here...? > So, yes, the data is included in the XML header, but should be > transmitted in the response to a request [2]. > > I also forgot to mention the most obvious : > > timestamp : ISO 8601 UTC time stamp when the response was generated. > > GUID : it is a common concept in the industry and the point is *not* > for anyone to generate them -- allthough, I'll gladly explain how it's > done in java ;-) > The point is : replication instead of duplication. > And yes, I do have them in 'my' existing data, I fail to see the > point, unless of course it pertains to 'your' data... > And if a guid is oh so upsetting, I'm open to any [industry > 'standard', cross-platform] method you propose to ensure that a > response has a constant 'globally' unique id that will not change > while the rest of the data around it might, and will change. > > I'm very aware of e.g. the UUID class in Java, but some of that seems to be mixing up the actual device repository with session information. Entries now have an id that shall be unique within an entity like "Device", e.g. id="SAMSUNG-SGH-i780" What value would a "guid" field add here? The semi-human readable ID seems OK, why do we need another one? I think where entirely new structures are what you have in mind, it is better to draft actual pseudocode in the Wiki or a similar document, that is easier to see where each attribute is intended to be used than just by mail. WDYT? Werner > esjr > > > [1] http://www.w3.org/TR/DDR-Simple-API/#sec-Service-query-methods > [2] http://www.w3.org/TR/DDR-Simple-API/#sec-Service-getDataVersion > [3] http://www.w3.org/TR/NOTE-datetime > > On 24/08/2014 21:09, Werner Keil wrote: > > On Sun, Aug 24, 2014 at 7:29 PM, eberhard speer jr. > > <[email protected]> wrote: > > > > Hi, > > > > since we're adding anyway ;-) here are some more 'new' properties > > I'd like to propose : > > > > ddr_ : properties pertaining to the DDR responsible for the > > 'response' > > > > ddr_vocabulary : Vocabulary Name [example : DeviceMap] ddr_api : > > version number of the API used to create the response ddr_version : > > data resources version number ddr_date : release data of the data > > referenced in version number > > > > > > > > > >> I suppose these are mostly for the header (where they are already > >> more or less maintained right now) or would you put a version of > >> the resource data with every single device entry? The > >> "ddr_vocabulary" sort of exists, it was added by OpenDDR and I > >> think it's called "from" or similar. That contains values like > >> "ODDR" or (if we add new ones) "DeviceMap". > > > >> I don't think it is very heavily referred to, mostly meta-data, > >> so if it makes sense for better understanding such a field could > >> be named differently, e.g. ddr_vocabulary, too. > > > > > > > > > > guid : a *unique* identifier use-case : user queries DDR, gets a > > response, [user may save the response], later user re-queries the > > DDR and gets a *different* response. The guid tells the user both > > are responses to the same request, when properties [or their > > number] change over time. > > > > > >> Do you have all of these in your existing data, too? E.g. where > >> would we generate such guid (which except a few cases is a rather > >> MS/.NET feature btw;-) > > > >> Most others I don't see the "use-case" of these, they sound > >> fairly dynamic, e.g. for a particular session. That is nothing a > >> single device "class" would hold, would it? > > > >> Maybe you can explain these 3 a bit more. > > > >> Thanks Werner > > > > > > > > Comments ? > > > > esjr > >> > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (MingW32) > > iQEcBAEBAgAGBQJT+lBkAAoJEOxywXcFLKYcqEwIAIdF+j28oJY3higpyHcKbjgd > NuKmlc+qUqlGfOEm6QCCAQjPWLvbhZBYUS5YA6/OQ/gd+qCbOxkCy2FPDlpYLTCA > 993CjmTk71kUS2+4YjeZ98dMUr6NldIgBd+vi32sbaBJbRcmF7AoyslpAxq7j+nR > 7XkJ2Pfkql4+Km17LGEs/VveCyOwIgGLrxf8lhCLsA80jcqArEbYdS2Mpo8+aILs > McTesvgX0vFLYnGEiChoKNy66zWyr/OI7MtP0Y1AYpccDBsasNoC+ILpESDNGD5r > T51SfBK46jzyQ8YUWlmqoZ4fhVFMpBSaCOZYpA6Bj0tU5NxJY6/rXDT2rL4Yk3s= > =8viV > -----END PGP SIGNATURE----- >
