Re: Alternate proposal for new terms for g-snap, g-box and g-text

On Thu, Jul 21, 2011 at 08:22:46AM +0100, Andy Seaborne wrote:
> 
> 
> On 21/07/11 02:24, Antoine Zimmermann wrote:
> >Le 21/07/2011 03:11, Lee Feigenbaum a écrit :
> >>On 7/20/2011 8:37 PM, Guus Schreiber wrote:
> >>>
> >>>
> >>>On 21-07-2011 02:08, Ian Davis wrote:
> >>>>I think re-introducing the word "graph" into these new terms
> >>>>perpetuates the confusion led to the need for g-* terms in the first
> >>>>place. We recognise that "graph" has subtly different semantics
> >>>>between sparql and rdf concepts so let's avoid that term.
> >>>>Here's my suggestion, which I think are unambiguous:
> >>>>
> >>>>g-snap: "(mathematical) set of triples"
> >>>>g-box: "container of a set of triples"
> >>>>g-text: "serialization of a set of triples"
> >>>>
> >>>>One step further could lead us to coin a new term: TripleSet
> >>>>
> >>>>g-snap: "TripleSet"
> >>>>g-box: "TripleSet Container"
> >>>>g-text: "TripleSet Serialization"
> >>>
> >>>Nice proposal. But I think some will object to the use of the term "set"
> >>>for something that is not (necessarily) a mathematical set.
> >>>
> >>>Small variation (but admittedly somewhat ugly):
> >>>g-snap: "Triple Set"
> >>>g-box: "Triple Container"
> >>>g-text: "Triple Serialization"
> >>
> >>At some point I feel we are splitting hairs, but I significantly prefer
> >>
> >>RDF Graph
> >>RDF Graph container
> >>RDF Graph serialization
> >>
> >>...to minting new terms.
> >>
> >>Just because people commonly use RDF graph as shorthand for RDF graph
> >>container does not motivate me to abandon such a normal and
> >>well-established term.
> >
> >Huge +1
> 
> +1

+1, although perhaps we could consider the following (mixing Ian's and your proposal :) ):

g-snap: TripleSet
g-box: Graph
g-text: Serialisation

It seems to me like the most intuitive: graph maps very well with what the SPARQL spec means by it, the tripleset is indeed a set, and the serialisation is, well, a serialisation.

Best,
y
> 
> RDF 2004 uses "graph".  We need a very big reason to change and to
> me that would be "RDF 2" territory and not RDF 1.1.
> 
> >
> >>
> >>Lee
> >>
> >>>
> >>>Guus
> >>>
> >>>>
> >>>>A TripleSet is immutable. A TripleSet Container contains exactly one
> >>>>TripleSet at a time but could be a different TripleSet at different
> >>>>times so a TripleSet Container is mutable. A TripleSet Serialization
> >>>>serializes exactly one TripleSet.
> >>>>
> >>>>A quick Google search suggests TripleSet is not a term in common use
> >>>>for other systems.
> >>>>
> >>>>In terms of spec changes: replace every occurrence of RDF Graph in the
> >>>>RDF specs with the term TripleSet
> >>>>
> >>>>I think it would be useful to talk about some of the characteristics
> >>>>of these concepts e.g. equivalence
> >>>>
> >>>>Two TripleSets are equivalent if they conform to the bijection defined
> >>>>at
> >>>>http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-graph-equality
> >>>>
> >>>>
> >>>>
> >>>>(i.e. they differ only in the identity of their blank nodes).
> >>>>
> >>>>Two TripleSet Containers are equivalent if their contained TripleSets
> >>>>are equivalent
> >>>>
> >>>>Two TripleSet Serializations are equivalent if they parse to
> >>>>equivalent TripleSets
> >>>>
> >>>>In terms of those "terrible TAG/REST terms":
> >>>>
> >>>>A URI can denote a TripleSet Container. Dereferencing that URI should
> >>>>return a representation consisting of the TripleSet Serialization for
> >>>>the TripleSet currently contained by the TripleSet Container. A user
> >>>>agent parses the representation to derive the TripleSet which they
> >>>>will most likely place into a local TripleSet Container.
> >>>>
> >>>>In terms of SPARQL, a dataset consists of TripleSet Containers:
> >>>>
> >>>>( C, ( Ui, Ci ) )
> >>>>
> >>>>A more concise name for TripleSet Containers would be a nice to have.
> >>>>Talis has been using the term Metabox for this concept for a long time
> >>>>(no prior art, I only recognise the equivalence today :). I don't
> >>>>think that's a great term to use, but perhaps TripleBox might work?
> >>>>
> >>>>Now, sorry to do this to you all, but I am away on holiday after
> >>>>tomorrow so I won't be around to get into any discussion this email
> >>>>may generate. I weighed up whether to send it now or wait and decided
> >>>>it was best to get something sent earlier. I'll pick up any
> >>>>conversation in a couple of weeks.
> >>>>
> >>>>Ian
> >>>>
> >
>

Received on Thursday, 21 July 2011 09:13:05 UTC