Re: Branding?

On 7/28/11 2:58 AM, Dave Longley wrote:
> On 07/28/2011 12:20 AM, Kingsley Idehen wrote:
>> The trouble with JSON-LD is that it implies a spec for constructing 
>> Linked Data using JSON.
>
> This is confusing to me. My view is that the spec we're talking about 
> is for constructing Linked Data using JSON. That it may also offer a 
> few more features that handle what you don't strictly consider Linked 
> Data doesn't seem to me to be a reason to drop the name entirely. I'm 
> just not convinced by your argument that naming the spec JSON-LD would 
> create a narrative that would mislead people and wreak havoc.

"LD" meaning Linked Data re. this spec is ultimately confusing.

"LD" meaning Labeled and Directed, as I've stated earlier, works fine.

"LDG" meaning Labeled and Directed Graphs also works.

>
>> "Linked Data" is the end product of a specific kind of directed graph 
>> based structure. This structure can be used as a powerful vehicle for 
>> whole data representation.
>
> Ok, I agree.

Great.

>
>> You are treating Linked Data and graphs as the same thing.
>
> That's not my intention. My intention is to see Linked Data as a 
> directed graph that is primarily populated with URIs that resolve to 
> representations of their referents at web scale, but may also contain 
> URIs that resolve to representations of their referents at local scale 
> for the cases where creating a web-scale URI would be a detriment to 
> the data or the Web developer.

That's a hybrid *kind* or directed graph. Its end product is 
subjectively compatible with Linked Data consumers and serializers, but 
isn't pure Linked Data e.g., making the critical Follow-Your-Nose 
pattern portable across data spaces.

> I'm interested in keeping forced skolemization out of the way of Web 
> developers by allowing them to use unlabeled nodes without them having 
> to care about it. And, if they do have a need for skolemization, I'd 
> like there to be an algorithm that is part of the spec that solves the 
> problem for them automatically and in one place. I think that's, more 
> or less, what we have so far and what is reflected in the latest 
> implementations of JSON-LD.
>
>> Why is "LD" so vital beyond the fact (as I've claimed repeatedly) 
>> that this is an awkward attempt to ride the Linked Data wave.
>
> I've said that it isn't vital -- in my first message. My position is 
> quite the opposite of yours, though, in that it seems very awkward to 
> me that it is vital to you that we change the name. 

"LD" doesn't have to mean "Linked Data" as stated above. Thus, you 
aren't changing the name. In addition, you aren't inadvertently muddying 
the waters re. Linked Data.

> Please keep in mind that the spec was already named JSON-LD and now 
> you're trying to make a case that we should rename it; not the other 
> way around.

I having only been trying to make one case: the Name of the spec should 
clearly reflect what it seeks to deliver. In doing so it should be 
cognizant of its own goals and target audience.

>
> From my perspective, we've written a specification that is primarily 
> for people to start contextualizing their JSON so that it can be used 
> at web scale. A lot of people think of that as "Linked Data".

Well it isn't. And a lot of people know that too.


> Therefore, it's just easier if we include that in the name. If there's 
> some small part of the spec that pollutes what constitutes a more 
> perfect Linked Data definition to you, then I honestly don't see that 
> as a serious reason to rename the spec. 

The fact that I am vocal about the Linked Data matter doesn't mean I am 
the sole person with a gripe. But once again, do we continue to debate 
this matter when "LD" is now going to me: Labeled and Directed?  Of 
course, if you and Manu don't want "Labeled and Directed" we can crack 
on and debate this matter to logical conclusion. At this juncture, I am 
assuming the matter is closed since "LD" stays but doesn't explicitly 
mean: Linked Data.

> Meaning, if I felt the same way, I don't think I'd consider it vital 
> to rename the spec. Furthermore, I've argued that the loose 
> definitions you previously offered don't preclude the use of unlabeled 
> nodes in Linked Data. This has since changed a little once you alluded 
> to a requirement that URIs be web-scale rather than local, but prior 
> to that, your argument was not valid.

The Web's Global Data Space dimension is the destination. Linked Data is 
the critical foundation that provides an unobtrusive bridge between the 
Web's Information and Data Space dimensions. This is the crux of the 
matter. URIs resolve in both dimensions, the difference is granularity, 
in one case its coarse (Name & Addresses == Data Source Name) and in 
another its fine-grained (Name resolves to Address which is the Data 
Source Name).
>
> Since you've added the web-scale requirement, I've argued that I don't 
> see a reason to create a concept (or try to pin down an amorphous one 
> that has been floating about) that doesn't allow for people to express 
> data as it already naturally occurs. That is, some data is local and 
> some is global. Some global data references local data. Some currently 
> local data should become global, but it doesn't make sense for *all* 
> local data to be considered global. 

There are other ways, in the Linked Data realm for making data global or 
local, public or private.

> Therefore, an effort to attempt to get people to make their local data 
> that *should* be global ought not force or coerce them to make their 
> rightly local data also global. That would produce the same original 
> mistake: the creation of improperly scoped data.

The issue is indirection. How many levels of indirection? Linked Data is 
about: Name->Address->Data. That's it. If you want 
Name->Pseudoname->Local Address->Data, that's fine but it isn't what 
Linked Data is about re. the Web's data space dimension.  You have 
indirectly Linked Data.

>
> All of this means that whatever concept we come up with to describe 
> this emerging world of web-scale information ought to accurately 
> include all of these types of data.

"LD" as Labeled and Directed addresses that. Add "G" for Graph and its 
even clearer i.e., JSON-LDG or just JSON-LD.

> If that isn't Linked Data and you don't see any way that it could be, 
> then you're right that Linked Data is the wrong name. 

Yes, re Web scale Linked Data. Yes, when this is about the Web's data 
space dimension.

> It also means that Linked Data is just the same trap, but only in 
> reverse, that our data has been caught in previously.

No it isn't. The AWWW is "deceptively simple" and immensely potent. If 
we can reduce confusion during the Web's evolution the real power of 
AWWW will shine through. There is so much more to come, potentially.

The game here boils down to breaking down data silos via powerful data 
virtualization. AWWW is best suited to addressing this age-old challenge.

>
>> I don't think so at all. We need more Venn Diagrams as collateral for 
>> helping people understand concepts and boundaries.
>
> I don't think we have to make this that complicated. I'm not against 
> someone drawing up as many Venn Diagrams as they want to, but I don't 
> think that they should be necessary to get moving with JSON-LD.

I think they help. Anything aimed at clarity ultimately helps some 
audience.

>
>> It is supposed to be about JSON as a vehicle for constructing and 
>> serializing Linked Data. I don't quite get the "practical markup to 
>> support Linked Data in JSON" statement. Are other markups (including 
>> those that are JSON based) for creating Linked Data impractical then?
>
> Here's what is impractical: Telling a JSON Web developer that some of 
> their data won't work with a JSON-LD processor and some of it will -- 
> when the only parts that won't work are unlabeled nodes.

No, come on! Who said that?

Here's what I am saying: when "LD" means "Linked Data" it just muddies 
the waters re. understanding what "Linked Data" is about as outlined in 
TimBL's meme. The aforementioned meme was aimed at leveraging AWWW en 
route to unveiling the Web's Data Space dimension via Linked Data 
bearing (carrying) resource -- basically, clickable data that's 
follow-your-nose pattern friendly.

Now Linked Data itself won't come from thin air, and we can't expect 
people to always craft it by hand. Thus, structured data delivered via 
directed graph based data representation is important too. This is why 
OData from Microsoft, Graph and Open Graph initiatives from Facebook, 
and most recently, schema.org are extremely important. The more 
structured data you have on the Web the easier it becomes to produce 
Linked Data via transformation [1].

> They exist naturally in JSON and could be handled by the processor 
> appropriately (as the current implementations do). It's impractical to 
> coerce a Web developer to write a custom skolemization algorithm to 
> create web-accessible URIs for types of data where it simply makes no 
> sense to do so. 

I don't think I've inferred that in anyway.

> A Web developer is going to try and make the bulk of their data 
> "Linked Data" and then run into corner-cases where it just doesn't 
> make any sense -- and it's going to be impractical for them to have to 
> handle it.

You are repeatedly making some really subjective comments on behalf of 
an extremely broad audience.

A developer or end-user needs a clear and simple set of instructions for 
constructing and publishing Linked Data. They need to know that they can 
achieve this goal using a variety of serialization formats.

> This will happen because *not all data is global, but a lot of global 
> data links to non-global data*. We shouldn't say that this data has to 
> be discarded or changed right out of the gate. It is impractical to 
> force developers into a box when they just want to use Linked Data for 
> most of their needs and get going.

I am really not saying that. You sorta mangling what I am saying.

>
>> Why on earth do you deem anything view contrary to yours (or Manu's 
>> for that matter) as "theoretical" or "impractical" ? Dare I ask about 
>> your ownership of "pragmatism" and all things goal oriented and 
>> achievable i.e., practical?
>
> This is hyperbole. 

It isn't, read the threads i.e., rewind some. Even further, do it across 
mailing list, we do have a Web after all. You veer to this kind of name 
calling when there's disagreement.

> We're having a specific discussion about your perceived need to rename 
> a technical specification that is presently called "JSON-LD". I'm 
> simply not buying your argument is all.

As I stated earlier, we end this argument if "LD" means Labeled and 
Directed. If not, we crack on....
>
>> In my world view Names matter a lot. I prefer unambiguity over 
>> ambiguity via Naming conventions, especially when the goal is to be 
>> "deceptively simple" .
>
> There is nothing "deceptively simple" about requiring every Web 
> developer with an unlabeled subject to come up with their own 
> customized skolemization algorithm for assigning it an arbitrary name 
> and web-accessible URI that will likely never be dereferenced. In my 
> view, this just generates superfluous management overhead for Web 
> developers. It is better to pollute the concept of Linked Data than it 
> is to force Web developers to pollute the Web with arbitrary URIs. If 
> unambiguity is needed for unlabeled nodes in order to compare graphs, 
> then let's indicate what the Naming convention is for Web developers 
> and give them an API call to do it so the problem only has to be 
> solved once.
>
>> If no such Resolver exists then you don't have Linked Data delivered 
>> by the graph type you are proposing.
>
> Right, but I said that the Resolver exists. 

We've made proxy URIs since 2006. I have resolvers for many schemes. If 
you can make ProxyURIs for your blank nodes that are portable, then 
great. Basically, I should be able to take your data set to another data 
space and de-reference the URIs (from there)  and it all works, if so, 
great! You have Linked Data.

> The Resolver for a blank node identifier just returns the graph of 
> which it is a part. That is the only graph that references it. This 
> Resolver is simpler than an HTTP Resolver -- which must use the HTTP 
> protocol to go out and fetch a referring graph. But, I grant you, this 
> is not a web-scale Resolver.

We go to the pain of making web-scale Resolvers across multiple URI 
schemes. We take on that burden of living within the confines of what 
Linked Data is about.

>
>> Yes, but without blank nodes in the conversation we don't even 
>> introduce the term: skolemization.
>
> Just because we decide not to talk about unlabeled nodes doesn't mean 
> that a Web developer won't run into them.

Of course they will, and at that point you have a "cure" ready. Until 
then, why not let them get going first?

> What it does mean is that they will have no direction as to what to do 
> in that situation. 

It doesn't, my statement above, and what I've said in other posts do not 
imply the characterization above. Remember, my comments about the "front 
door" and skolemization?

> They'll just have to come up with their own customized skolemization 
> algorithm. Let's solve the problem once -- and, we won't even have to 
> mention skolemization to a Web developer just like we'd both prefer.

Basically a moot point, certainly if "LD" means Linked and Directed.

> This is because they'll be able to use their data, including unlabeled 
> nodes, without ever having to think about assigning a name or using an 
> automatically assigned name. The JSON-LD tools will just "work" -- 
> which is what I consider "deceptively simple".
>
>> I don't understand how an IRI that resolves to the representation of 
>> its referent can in any way be construed as being devoid of meaning. 
>> "I am who I am" dates back to biblical times :-)
>
> When I say that there are examples of local data that don't have 
> meaning outside of that which they are a part, I don't mean entirely 
> devoid of meaning. I mean that if you don't know what the data is for 
> then you can't use the data in the way it was intended.
>
> Consider the URI: 'http://foo.com/z123'

Use a real example i.e., one that resolves and doesn't make sense. The 
URI above genuinely doesn't make any sense in the context of Linked Data.
>
> When you resolve this URI, you get a graph containing the subject 
> 'http://foo.com/z123', a digital signature predicate (a URI), and a 
> base64-encoded literal value as the object. Of what use is this 
> information? 

Use a real example. If it resolves it makes sense of the "I am who/what 
I am" variety. If it doesn't, then in the context of Linked Data it make 
no sense.

> Clearly it's a digital signature for something, but for what?

You've lost me without a real example. Make a real example and the 
answer will hit you.

> Why would I ever refer to this subject without including the thing 
> that it is a signature for?

You tell me :-)  If it resolves, you won't need to tell me anything. 
Make a real example that resolves.


> How does giving it a name so that I can refer to it in this way a 
> useful exercise? 

Well until you perform the exercise it cannot make any sense, as I've 
outlined above.

> Isn't there a further requirement to force local data to be considered 
> useful Linked Data?

Identifiers (Names) resolve to descriptions of their referents. If you 
get a description its makes sense.

> It seems to me that I must not only provide arbitrary names and 
> web-accessible URIs, but I also have to create reverse references. 

I don't know where that's come from. They help, but aren't mandatory.

> And that means I'll need to create more predicates (and thus, more 
> URIs). Sounds like a headache to me, when I could have just said: No 
> one is ever going to make sense of this digital signature outside of 
> the thing it is a signature for; therefore, only the signed thing 
> needs a web-accessible URI. And, if I could do that, everything would 
> "just work", there's no extra effort needed by me.

If you make a real Linked Data example this would be much more 
meaningful re. supporting your point. Right now this is a lexical space 
style adventure that doesn't shed real light on the issue at hand. Give 
me a data space example i.e., make a resolvable URI, of the Linked Data 
variety, that is meaningless.

>
> Another example of where this would be a pain would be the modeling of 
> any ordered list. Especially when the order might be subject to 
> change. I'm sure there are plenty of other examples where some data 
> that should be at web-scale is linked to data that has no place being 
> there. Directly referring to that kind of data at web-scale simply 
> doesn't make any sense.

But these aren't what Linked Data is about. Again, a Linked Data style 
directed graph is a *kind* of graph. Not the only option for directed 
graph based data representation. Its just an option that very specific. 
You are continuously talking about matters that apply to a broader realm 
of directed graphs. Basically, the realm covered by RDF. My position is 
that Linked Data is a specific *kind* of directed graph, so don't try to 
shoehorn everything into this very specific matter.

>
> If, for some reason, I need to refer to data at web-scale, then I 
> should be using a URI. 
A URI that resolves to a Representation of its Referent. Assuming this 
is in the context of Linked Data, at web-scale.

> But when I don't, please don't make me jump through hoops just because 
> it is purer to make *everything* have a URI. Seems like we're using a 
> hammer to drive in a screw. 

No we aren't. Far from it actually.

> JSON-LD should let me use an unlabeled node and not complain about it.

Yes.  Esp., if "LD" means Labeled and Directed.

> And, if I need that node named in order to compare graphs, I'd like 
> JSON-LD to do it for me. Keep the skolemization algorithm out of my 
> way by giving me an API call to handle it. 

Don't need APIs at the surface re. Linked Data. The logic is inside the 
Data. Thus, a data space could as part of its implementation use an 
algorithm or obtain such from an API. That's in the implementation 
details re. data space box. Nothing to do with the spec for creating 
Linked Data.

> I believe that's what we've spec'd out and implemented so far, and I 
> think it's the right approach.

The only issue I have is with "LD" meaning "Linked Data" and then 
effectively muddying the subject matter.

>
>>
>>> I consider it a pollution of the web to add "Global Data Space IRIs" 
>>> to subjects that have no business being accessed at a global level. 
>>
>> If something shouldn't be accessed at any level you protect it with 
>> ACLs. That's what WebID facilitates.
>
> This is misinterpretation of what I meant by "accessible", my 
> apologies. I'm not talking about security. I meant what I mentioned 
> above; it makes no sense to directly refer to certain subjects at 
> web-scale. They are local to other subjects that do make sense when 
> referred to at web-scale.

Would an Address be an example? Basically, representing all the elements 
of an real-world home or office address.

>
>> Here is another way of looking at this matter: clickable data. When a 
>> user clicks on a URI they get something back. Doing that consistently 
>> at InterWeb scale with blank nodes in the mix is increasingly 
>> problematic as data moves across data spaces.
>
> I think that I would personally be ok with restricting blank nodes so 
> that they don't "move across data spaces". I see their primary use 
> case as being strictly local; there's nothing to click on, and no 
> where to go with a blank node because you're already there.

Yes-ish. It depends on what we are talking about i.e., LD == Linked Data 
or LD == Labeled and Directed.
>
>>
>>> I'm also suggesting that anyone who wants to put an unlabeled node 
>>> in their JSON data because it simply makes sense to do so -- can do it.
>>
>> Sure, but the spec itself doesn't have to cover that. Spec 
>> utilization examples could cover such matters. The context would 
>> clearly state "advanced use" for instance.
>
> I think the spec should be clear that it is permitted, but I have no 
> problem with it being under "advanced use".

That works. And I think the requirements document already deftly 
delivers this, as I stated in my last post.

>
>>
>>> Furthermore, they might *never* have to skolemize it. That's where 
>>> framing comes in. This pushes all of the skolemization into the back 
>>> corner where only an expert might have to know something about it. 
>>> But it's there to cover the cases where it's needed. 
>>
>> Fine, as examples and tucked away in the advanced box :-)
>
> I can agree with this. Like I said, I'm not looking to front page the 
> skolemization algorithm, but it should be in the spec under an 
> advanced section.

Okay.

>
>> It depends on when constitutes the spec. re. use of Linked Data.
>>
>> BTW - I really thought we had closed this matter re. LD. Gregg and 
>> Bradley converted a lot of what I've been pushing for into a 
>> requirements doc [1] that I don't have issues with. I believe this 
>> document cleverly leaves room for blank nodes without any distracting 
>> Ads at the front door :-)
>
> Well, my original message had to do with questioning the reasoning 
> behind changing the spec name -- which seemed to have a lot to do with 
> the use of unlabeled nodes.

My only issue has been with "LD" meaning "Linked Data". I have no 
problems with "LD" meaning "Labeled and Directed" or "LDG" meaning 
"Labeled and Directed Graph". JSON-LD as a Name remains intact. The 
meaning of "LD" is all that's changed. That works :-)



-- 

Regards,

Kingsley Idehen	
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen

Received on Thursday, 28 July 2011 16:23:24 UTC