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

Hi all!

On Tue, Jul 19, 2011 at 8:18 PM, Gregg Kellogg <gregg@kellogg-assoc.com> wrote:

> 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?

This is a very good point. This is why bnodes are useful and
pragmatic. If a resource is meaningful only in its relation to some
entity if which it is a "part" (in some primary composition), it will
reasonably not have a meaningful record of its own, and I see no good
reason for demanding the minting of a URI for it.

I commonly use bnodes in this way in RDF (which is the only linked
data graph model I know and use). Of course, such
"rich/structured/compositional" values aren't very frequent, but they
do occur from time to time (and as I recall, the case of the property
rdf:value is for such things; e.g. where datatyped literals aren't
enough). That said, I always consider if there is potential use for
linking *into* rich structures as well of course, and in such cases
mint URIs for important parts too (commonly using fragment
identifiers).

For "partial knowledge", I sometimes, but rarely, make statements like:

    <> dct:creator [ foaf:name "Some Body" ] .

    <> dct:subject [ skos:prefLabel "Concept Name"@en ] .

And only when I do not *know* more, but find that some information is
more useful than nothing. It isn't perfect, as here there is
*tremendous* value in having links to the person and the concept
respectively. For the person, finding at least a foaf:homepage to link
to improves a lot; for the concept, there's a good chance of finding
something in DBPedia to link to, or for publishing your own SKOS data.

Btw., I personally shun BNode IDs (not that these are under discussion
here AFAIK). I do so because the need to use a bnode as object of more
than one statement is a clear sign that I need to *link* properly to
it (i.e. using URIs). (To me, bnode ids *only* make sense in
serializations like ntriples.)


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

I agree here too (the join table is a good analogy). Though in this
particular case, I remember wondering why they don't use rdf:List
(with first/rest chain of bnodes to express "linked lists"/cons
structures) for all but the most advanced scenarios? Anyway, I
digress.

BNodes have their definite use cases, and I find them very pragmatic.
There *is* the risk of diluting the value of linked data if they're
used without discretion. Always ask if there is conceivable value in
linking to a "subsumed resource" on its own. If you find none, I'd say
go ahead, don't label it, use a bnode.

Best regards,
Niklas
--
<http://neverspace.net/>

Received on Tuesday, 19 July 2011 19:34:34 UTC