Re: JSON-LD bnode canonical naming algorithm

On 06/01/11 22:17, glenn mcdonald wrote:
> I know somebody who is named Bob. I am related to somebody that has 
> high cholesterol I know somebody, that likes somebody who owns a dog.
> What is that thing that has a tail with spikes in it?
> 
> Why are these important statements to support?

These types of constructs - being able to identify the unnamed in a
statement - are a common part of communication. This is true not just in
English, but in almost every modern language. Language is important
because it constrains the things that we can talk about. There is a
balance, of course, but the line may need to be drawn on the far side of
bnodes - including them instead of excluding them.

> Why are they more important than simliar statements that RDF and 
> Linked Data already do not support, like:

The link between normalizing bnodes and not being able to represent what
you typed below is not clear. As far as I can tell, those are two
independent features. It sounds like your argument is: because we don't
have feature X that we should also not have feature Y. If there is no
link between those two features, then that same argument could be
applied to remove all features from any technology if they are missing
just a single feature. What's the link?

That being said, there are many ways to model the information below in
RDF. Most of what you propose are logical assertions, not necessarily
pure data. How you reason over the data is the important part to your
statements. Here is just one sloppy way to do it (off of the top of my
head):

> Everybody I know loves pizza.

ex:concepts/EverybodyIKnow
   a
      ex:KnowledgeConcept.

#me
   foaf:knows
      ex:concepts/EverybodyIKnow .

ex:concepts/EverybodyIKnow
   ex:loves
      ex:food/Pizza .

> If you love pizza, you'll definitely love calzones.

ex:concepts/PizzaCalzoneTruism
   a ex:Truism ;
   ex:if [ex:concepts/Anybody ex:loves ex:food/Pizza] ;
   ex:then [ex:concepts/Anybody ex:loves ex:food/Calzones] .

> You can never have too much pizza or too little tornado damage.

ex:concepts/PizzaTornadoTruism
   a ex:Truism ;
   ex:maximize ex:food/Pizza .
   ex:minimize ex:catastrophe/Tornado .

> There's no way to tell if a pizza is really good without eating it, 
> but maybe we should wait until the tornado passes.

ex:concepts/PizzaTasteTornadoCautionTruism
   a ex:Truism ;
   ex:potentialAssertion ex:concepts/LackOfImminentTornado ;
   ex:afterAllAssertions
      [ex:food/Pizza ex:goodTasteRequirement ex:bodilyFunction/Eating] .

> Not to mention that the six degress of Kevin Bacon game would be 
> impossible to represent in Linked JSON!
> 
> So what? We could represent the /data/ for the game very easily. It 
> just involves actors and films. You'll have a hard time representing
>  Asteroids or Volleyball in Linked JSON, either. Who cares?

I don't understand what you're saying here. You seem to be saying "we
can model anything easily", but then it seems as if you're saying "we
can't represent concepts easily".

To approach it from a different angle - you are typing English sentences
- RDF is subject, predicate, object. Anything you type can be modeled as
subject, predicate, object because you're using subject, predicate,
object to express it. What am I missing here?

> We're just trying to make an interchange format for graph-shaped 
> data. At least that's what I think we ought to be doing. Or doing 
> first, at least.

I agree with you. :)

I think we have already done that with JSON-LD. Why do you think we have
not done that?

> So in the end this seems like a classically circular argument to me: 
> We must support blank nodes because there are things you can say
> with blank nodes.

That's not the argument. The argument is that there is data out there
that we want to model in Linked JSON that can be more easily represented
with blank nodes than with anything else that has been discovered in the
past 30 years. The design benefits outweigh the drawbacks.

> Blank nodes as existential quantification get into expressing
> logical assertions, not just serializing data.

Expressing logical assertions are not the only use for blank nodes.
There are more practical uses that we're concerned with - where a
dereferenceable IRI doesn't make sense, but graph equality is a
requirement. For instance, not everything needs a dereferenceable IRI in
a transient, digitally-signed contract for the immediate exchange of
virtual goods for cash. Creating IRIs here is a nuisance with
considerable maintenance overhead. It would be nice if it were
automatic. And that's just a use case for PaySwarm
(http://payswarm.com). I'm sure there are plenty more.

> I maintain that this is weird. Triply so when you consider that RDF 
> /doesn't/ have universal quantification, implication, or any of the 
> /other/ obvious peers from logic.

RDF is a data model - it's not the logical layer that you use to
interpret that data model.

> Has anybody ever criticized CSV for lacking existential
> quantification? XML? JSON itself?

No, but "existential quantification" is not the goal. The goal is to be
able to express data without specifying the subject. You can do this in CSV:

,likes,Pizza

and this in XML:

<thing>
   <property>likes</property>
   <object>Pizza</object>
</thing>

and this in JSON:

{
   "likes": "Pizza"
}

If you want to normalize statements like that, you can't do it without
naming the unnamed entities. What am I missing?

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarm Developer Tools and Demo Released
http://digitalbazaar.com/2011/05/05/payswarm-sandbox/

Received on Thursday, 9 June 2011 22:24:14 UTC