W3C home > Mailing lists > Public > public-linked-json@w3.org > July 2011

Re: JSON-LD Telecon Minutes for 2011-07-04

From: Gregg Kellogg <gregg@kellogg-assoc.com>
Date: Tue, 19 Jul 2011 14:18:41 -0400
To: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
CC: Kingsley Idehen <kidehen@openlinksw.com>, "public-linked-json@w3.org" <public-linked-json@w3.org>
Message-ID: <885BC0EE-4340-4307-8372-BBB3528E2B36@kellogg-assoc.com>
Of course, we all should be familiar with the use of these terms, and I believe that that's pretty much the intent of this definition, particularly in our context. Perhaps I'm being a bit a bit extreme, but SHOULD is not intended to allow people with no good reason to avoid doing it. Taken from an implementer's view, how much consideration need be given to violations of SHOULD. In our case, by saying "Items SHOULD be named with an IRI", it may mean that implementation will not handle the case where they don't consistently, and I can certainly see that there would be resistance to adding special processing rules to handle this case.

Could the Payswarm use case be done without using unnamed nodes; I think so, but it does mean that the author needs to create a number of IRIs that are not really intended to be independently dereferencable. What's the information I would expect to have returned when dereferencing an IRI for a signature? Does a signature have any meaning outside of the serialization of the graph that it signs?

Taking an example from SQL, if I have a JOIN table linking two other tables having unique identifiers columns, does the JOIN table, itself, also need an unique identifier? It only makes sense in the context of the tables which it joins, not on it's own. Consider a music case from The Music Ontology:


ex:FunkyPlaylist a olo:OrderedList ;
   dc:title "Funky Playlist"^^xsd:string ;
   dc:description "A playlist full of funky legends"^^xsd:string ;
   dc:creator <http://foaf.me/zazi#me> ;
      olo:length 2 ;
      olo:slot [
         olo:index 1 ;
         olo:item ex:SexMachine
      ] ;
      olo:slot [
         olo:index 2 ;
         olo:item ex:GoodFoot
      ] .

ex:SexMachine a mo:Track ;
   dc:title "Sex Machine"^^xsd:string ;
   dc:creator <http://dbpedia.org/resource/James_Brown> .

ex:GoodFoot a mo:Track ;
   dc:title "Good Foot"^^xsd:string .

Slots are needed to describe ordering of tracks, given that the tracks may be in multiple slots. This couldn't be rendered in JSON-LD, unless each slot were given an IRI of it's own, which would seem to be gratuitous, and only necessary to call the graph purely Linked Data.

Gregg

On Jul 19, 2011, at 10:21 AM, Ted Thibodeau Jr wrote:


On Jul 19, 2011, at 11:50 AM, Gregg Kellogg wrote:

If the JSON-LD spec says "Items SHOULD be named with an IRI" this might imply that the processing steps do not need to consider the case when it's not, or that authors using unnamed items (or even items named with literals, for example) are somehow wrong. If an author conceivably COULD name all nodes with an IRI that means that they MUST.


Please see --

  http://tools.ietf.org/html/rfc2119

SHOULD has an explicit semantic meaning.

Be seeing you,

Ted




--
A: Yes.                      http://www.guckes.net/faq/attribution.html
| Q: Are you sure?
| | A: Because it reverses the logical flow of conversation.
| | | Q: Why is top posting frowned upon?

Ted Thibodeau, Jr.           //               voice +1-781-273-0900 x32
Evangelism & Support         //        mailto:tthibodeau@openlinksw.com
                            //              http://twitter.com/TallTed
OpenLink Software, Inc.      //              http://www.openlinksw.com/
       10 Burlington Mall Road, Suite 265, Burlington MA 01803
                                http://www.openlinksw.com/weblogs/uda/
OpenLink Blogs              http://www.openlinksw.com/weblogs/virtuoso/
                              http://www.openlinksw.com/blog/~kidehen/
   Universal Data Access and Virtual Database Technology Providers
Received on Tuesday, 19 July 2011 18:57:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:30 UTC