Re: A rant about the terminology debate

On 8/24/12 4:00 PM, Antoine Zimmermann wrote:
>
>
> Le 24/08/2012 18:09, Sandro Hawke a écrit :
>> On 08/24/2012 07:32 AM, Kingsley Idehen wrote:
>>> Sandro,
>>>
>>> How would you map g-box, g-snap, and g-text in formal relational DBMS
>>> terminology? Such a mapping would help many. Basically, mapping to
>>> relations, sets of tuples, and notation.
>>>
>>
>> I'm not really fluent in RDBMS theory terminology. I do know the
>> terminology database app developers use, though, I think -- the kind of
>> stuff you find in the Oracle or MySQL manuals (talking about "tables"
>> instead of "relations"). In that terminology, I'd say:
>>
>> g-box: table (or view)
>> g-snap: dump of a table (or view)
>> g-snap: not something one normally deals with; either:
>> - a state of a table; or
>> - a value which is the set of all the rows in a table.
>>
>> This is more of an analogy than a real correspondence, since a table row
>> is not the same thing as an RDF triple, in general. (You could make a
>> Subject/Property/Value table, but the data typing of the value wouldn't
>> work right, in general.)
>
> RDF Graphs (aka g-snaps) represent the abstract structure on which RDF 
> systems work. For relational databases, the abstract structure is more 
> complex as you can't separate the data from the schema.
>
> A possible correspondence would be:
>
> RDF Graph <-> Relation

Yes, a Table isA Relation. A Relation is a Graph. RDF simply expects 
tuples to be in 3-tuple form. In addition, keys aren't extensions of 
records which is the case re. the extensional relational tables oriented 
DBMS.

> Set of triples <-> Multiset of tuples

Yes.

> RDF Dataset <-> Collection of relation (a database?)

Table since its a Named Relation.

>
> What's funny is that in the world of relational databases, they've 
> been using über-overloaded words like "relation", "view", "table", 
> "schema" for decades without problem. 

Exactly!

> Especially, we at least use the word "graph" paired with "RDF" to 
> define unambiguously "RDF graph", while in relational algebra, the 
> concept called "relation" is not even disambiguised with a qualifier. 
> But it works and nobody complains.
>
Yep!

> From the point of view of experts in relational DBs, we probably look 
> ridiculous with our battle on terminology. 

Tell me about it! And the contempt has just piled up over the years. As 
I've stated many times, I've hard serious discussions with many RDBMS 
product founders and technical leads. Most just can't make sense of RDF, 
and that's more to do with terminology mapping than anything else.

> People using RDBs don't even care about the names of the abstract 
> concepts, they use "table" and "row" because tuples and relations look 
> like rows and tables when displayed. 

Yes!

> In the RDF world, people don't care about the names of the abstract 
> structure and use the word "graph" alone because RDF graphs look like 
> graphs when displayed. And it is perfectly fine!

Yes, but they can be presented in Tabular form which then makes visual 
reconciliation easier for RDBMS folks.

For someone who was lucky enough to live through the RDBMS market 
bootstrap, I know first hand what worked for the RDBMS and continues to 
be a struggle re. RDF.  In the early RDBMS days, terminology (even when 
ambiguous) was uniformly accepted by all players. Thus, production of 
tutorials and other technical marketing collateral was easy. This never 
happened for RDF, and I don't want to open up another rant thread about 
this matter -- esp., as I truly believe we are making serious progress 
right now en route to fixing these legacy issues once and for all.

>
> I'm 100% with Richard on this issue and I propose that we make the 
> following resolution:
>  1. if a term is normatively defined by RDF 1.0, we adopt it for RDF 
> 1.1 without any change;
>  2. if a term is normatively defined by SPARQL and we want to put the 
> concept in RDF 1.1, we adopt it without any change;
>  3. for all terms that do not have a normative definition yet in 
> either RDF or SPARQL, we leave the discussion open to settle on a term.

Okay.

[SNIP]

Links:

1. http://bit.ly/NpUDXL -- why Turtle matters .

Kingsley

>
>
> --AZ.
>>
>> -- Sandro
>>
>>> Kingsley
>>>>
>>>>> Best,
>>>>> Richard
>>>>>
>>>>>
>>>>> On 24 Aug 2012, at 03:53, Sandro Hawke wrote:
>>>>>
>>>>>> On 08/23/2012 11:22 AM, Richard Cyganiak wrote:
>>>>>>> On 23 Aug 2012, at 16:00, Sandro Hawke wrote:
>>>>>>>>> You proposed to redefine "graph" by splitting it into two
>>>>>>>>> separate concepts, a mutable and an immutable one.
>>>>>>>>>
>>>>>>>>> I propose to instead redefine "named graph" in the same way, by
>>>>>>>>> splitting it into two separate concepts, a mutable and immutable
>>>>>>>>> one.
>>>>>>>> You lost me here, sorry. What's the use case for an immutable
>>>>>>>> named graph?
>>>>>>> I guess I should have said "abstract named graph", sorry if that
>>>>>>> caused confusion. Abstract IRI-graph-pairs. The thing that SPARQL
>>>>>>> queries operate over.
>>>>>>>
>>>>>>>> And it sounds like you're suggesting "mutable named graph" as the
>>>>>>>> official term for g-box. Is that right?
>>>>>>> Almost. My definition of "mutable named graph" would be:
>>>>>>>
>>>>>>> "A *mutable named graph* is a resource, denoted by an IRI, that
>>>>>>> has a mutable association with an (abstract, immutable) RDF graph.
>>>>>>> The RDF graph is also known as the *state* of the mutable named
>>>>>>> graph."
>>>>>>>
>>>>>>> The key points are:
>>>>>>>
>>>>>>> 1) we insist that it is a resource, so the kind of thing denoted
>>>>>>> by IRIs
>>>>>>> 2) we insist that it is actually denoted by some IRI
>>>>>>> 3) it essentially has a mutable slot that contains an RDF graph
>>>>>>>
>>>>>>> This means it can cover both the terms "RDF space/g-box" and the
>>>>>>> term "(name, slot) pair" from the diagram in [1].
>>>>>>>
>>>>>>> I repeat my assertion that there is no need to ever talk about
>>>>>>> unnamed g-boxes.
>>>>>> Yeah, this makes sense, but it's not my first or second choice in
>>>>>> naming proposals. Probably wouldn't help to go into why/why not at
>>>>>> this point.
>>>>>>
>>>>>>>>>> I think the key elements are : (1) we stop using "RDF Graph" as
>>>>>>>>>> the
>>>>>>>>>> canonical, precise term for a g-snap;
>>>>>>>>> I disagree; "RDF graph" is a perfectly fine term.
>>>>>>>> I wish. I can live with it, but I think it's hardly "fine".
>>>>>>>> People use it wrong all the time; they say "RDF graph" and mean a
>>>>>>>> mutable and/or distinct set of RDF triples.
>>>>>>> I think by actually defining proper terms for these other things,
>>>>>>> and by clarifying that "graph" can mean "any of the above", we
>>>>>>> make a solid step towards improving the situation.
>>>>>> I think you're saying "RDF graph"==g-snap; "graph"=g-snap/or/g-box.
>>>>>>
>>>>>> I have a problem with this. I think people will need some way
>>>>>> linguistically to distinguish "graph" in the RDF world from "graph"
>>>>>> in the wider world, and the natural way to do that is to add the
>>>>>> modifier, "RDF". So people will instinctively say "RDF graph" to
>>>>>> clarify they mean "graph" in the RDF sense (not a bar chart or
>>>>>> something). But with your proposal, they've now accidentally
>>>>>> changed to talking about g-snaps.
>>>>>>
>>>>>> I think people rarely mean to only be talking about g-snaps, and
>>>>>> when they do, they can/should put the word "abstract" in there. I
>>>>>> also think the presence or absence of the modifier "RDF" shouldn't
>>>>>> affect the semantics of the term -- people should be able to use it
>>>>>> when they want to clarify they're talking about RDF, without it
>>>>>> otherwise affecting the meaning.
>>>>>>
>>>>>> -- Sandro
>>>>>>
>>>>>>> Best,
>>>>>>> Richard
>>>>>>>
>>>>>>> [1] http://www.w3.org/2012/08/RDFNG.html#fig1
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> I'm not saying we have to solve this problem, or that we can, but
>>>>>>>> I think it would be helpful if we could and I think this proposal
>>>>>>>> is our best bet.
>>>>>>>>
>>>>>>>> -- Sandro
>>>>>>>>
>>>>>>>>> But we can stress that "RDF graph" is an abstract, unnamed,
>>>>>>>>> immutable graph, and that when we talk about "graphs" in general
>>>>>>>>> then we may sometimes mean named ones that may or may not be
>>>>>>>>> mutable.
>>>>>>>>>
>>>>>>>>>> (2) we pick terms for g-box and g-snap that convey the idea
>>>>>>>>>> that they are two different kinds of "graphs";
>>>>>>>>> I disagree; I believe that there is never any need to talk about
>>>>>>>>> *unnamed* g-boxes; all the g-boxes we want to talk about are
>>>>>>>>> named. Therefore, a term like "mutable named graph" is
>>>>>>>>> sufficient to say all that needs to be said about g-boxes.
>>>>>>>>>
>>>>>>>>>> (3) we use "graph" if/when we don't mind being ambiguous about
>>>>>>>>>> g-box/g-snap.
>>>>>>>>> I'd rephrase that: We can use "graph" if/when we don't mind
>>>>>>>>> being ambiguous about
>>>>>>>>> g-snap/abstract-named-graph/mutable-named-graph. For example
>>>>>>>>> when we say, "SPARQL Update can be used to copy data from one
>>>>>>>>> graph to another". In that case we mean mutable-named-graph.
>>>>>>>>>
>>>>>>>>>> On your details.... let me start with: to you, can you have a
>>>>>>>>>> named
>>>>>>>>>> graph that's not in a dataset (or graph store)?
>>>>>>>>> As defined in SPARQL (named graph == IRI-graph-pair), no.
>>>>>>>>>
>>>>>>>>> But if we allow a term such as "mutable named graph", then yes.
>>>>>>>>> A Turtle document on the Web is a "mutable named graph", in that
>>>>>>>>> sense. It doesn't have to be in any particular dataset. Well,
>>>>>>>>> it's in the Web, and for me it makes sense to speak of the
>>>>>>>>> entire web as a "mutable RDF dataset".
>>>>>>>>>
>>>>>>>>> Best,
>>>>>>>>> Richard
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> I don't usually hear the term used outside SPARQL, so I don't
>>>>>>>>>> have much of an ear for that usage.
>>>>>>>>> -- Sandro
>>>>>>>>>
>>>>>>>>>> Best,
>>>>>>>>>> Richard
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 22 Aug 2012, at 18:07, Sandro Hawke wrote:
>>>>>>>>>>
>>>>>>>>>>> On 08/21/2012 03:33 AM, Andy Seaborne wrote:
>>>>>>>>>>>> On 20/08/12 16:30, Sandro Hawke wrote:
>>>>>>>>>>>>> If it wouldn't cause SPARQL too many problems, I'd suggest
>>>>>>>>>>>>> we should do
>>>>>>>>>>>>> the same with dataset, and even allow a dataset to be a kind
>>>>>>>>>>>>> of graph, I
>>>>>>>>>>>>> think, so that the world at large can use the word term "RDF
>>>>>>>>>>>>> dataset"
>>>>>>>>>>>>> for any collection of RDF data (whether or not it's
>>>>>>>>>>>>> segmented into named
>>>>>>>>>>>>> graphs).
>>>>>>>>>>>> That would be problematic. "RDF Dataset" is a specifically
>>>>>>>>>>>> defined term. "Dataset" we can be loose about (c.f. VoiD) ;
>>>>>>>>>>>> "RDF Dataset" is stressing the tie to a particular
>>>>>>>>>>>> definition. You might as well mix properties and triples if
>>>>>>>>>>>> you're going to mix things of different "shape".
>>>>>>>>>>> In the telecon, I mentioned on irc the term "bacronym" but
>>>>>>>>>>> what I meant was "retronym". These are terms like "cow milk"
>>>>>>>>>>> that arise once some term ("milk") becomes ambiguous (eg
>>>>>>>>>>> because of soy milk, almond milk, rice milk, etc). See
>>>>>>>>>>>
>>>>>>>>>>> I take the "radical proposal" to be the recognition that some
>>>>>>>>>>> terms are ambiguous and we need to make retronyms to
>>>>>>>>>>> disambiguate them.
>>>>>>>>>>>
>>>>>>>>>>> Here's a revised proposal:
>>>>>>>>>>>
>>>>>>>>>>> - We pick terms like "Abstract RDF Graph" (gsnap) and
>>>>>>>>>>> "Maintained RDF Graph" (gbox) that fit the retronym model. It
>>>>>>>>>>> makes it easy, when someone says "graph" or "RDF Graph", to
>>>>>>>>>>> think/ask, "do you mean abstract or maintained?" (I don't find
>>>>>>>>>>> these terms quite as ontologically comfortable as g-snap and
>>>>>>>>>>> g-box/space/data-source, because it makes them both be
>>>>>>>>>>> subclasses of "graph", but I think this approach works better
>>>>>>>>>>> for the community.)
>>>>>>>>>>>
>>>>>>>>>>> - We clarify that in all W3C specs to date, "RDF Graph" means
>>>>>>>>>>> "Abstract RDF Graph"
>>>>>>>>>>>
>>>>>>>>>>> - Going forward, we avoid using the term "RDF Graph", using
>>>>>>>>>>> either Abstract Graph or Maintained Graph (with or without
>>>>>>>>>>> "RDF" in there). Or just "graph" when we don't care which kind.
>>>>>>>>>>>
>>>>>>>>>>> I think that much of the confusion around the term "named
>>>>>>>>>>> graph" comes from a lack of clarity around whether what is
>>>>>>>>>>> meant is a "named abstract graph" or a "named maintained
>>>>>>>>>>> graph". I think the latter is much more common; the difference
>>>>>>>>>>> doesn't manifest in SPARQL 1.0 because it doesn't consider the
>>>>>>>>>>> idea of data changing. In my mind, this proposal is our best
>>>>>>>>>>> chance for being able to coherently keep using the term "named
>>>>>>>>>>> graph", which seems to be very popular.
>>>>>>>>>>>
>>>>>>>>>>> BTW, I think we might also want to define "Frozen" graph,
>>>>>>>>>>> which is a maintained graph in the sense that it exists in a
>>>>>>>>>>> computer's storage, but which is required to never change.
>>>>>>>>>>> This is, I think, mostly what PROV wants to use.
>>>>>>>>>>>
>>>>>>>>>>> -- Sandro
>>>>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen