Re: retronyms, Abstract/Maintained Graph (was Re: A radical proposal.)

On Aug 22, 2012, at 6:11 PM, Richard Cyganiak wrote:

> Sandro,
> 
> I suggest that of all the terms mentioned below, only the terms "abstract graph", "abstract named graph", and "mutable named graph" are needed. ("Mutable" works much better than "maintained" for me.)
> 
> I don't think we ever need to talk about g-boxes that are not named, so "mutable graph" is in fact unnecessary.
> 
> "Abstract graph" is the old RDF graph.
> 
> "Abstract named graph" is what SPARQL calls "named graph" today. The "graph" here is immutable and abstract, but we need to be aware that the relationship is, technically speaking, not "naming".
> 
> "Mutable named graph" is the thing that a graph IRI denotes in the semantics. It's a kind of resource. Technically speaking, the "named" thing is not an RDF graph. It's just a resource with an associated graph. For formalising this, I think I like the "graph extension" approach that Alan proposed today in the call, as it has precedent in the way classes and properties are formalized in the Semantics.

And I don't think I followed this suggestion during the telecon. Is there a written account of it anywhere?

Pat

> 
> I'm not sure whether we need "frozen named graphs". We might want to defer that to domain vocabularies IMHO, because the creators of such vocabularies can then surround the term with appropriate additional terminology.
> 
> 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
>> 
> 
> 
> 

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973   
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Thursday, 23 August 2012 06:20:19 UTC