Re: RDF Thrift : A binary format for RDF data

Aw, how did I miss that - sorry, and thanks.
(I think I tend to skip stuff in boxes :-( )

So now I need to ask, is
Content type: application/spatql-results+thrift
correct? :-)

On 15 Aug 2014, at 20:06, Andy Seaborne <andy@seaborne.org> wrote:

> 
> 
> On 15/08/14 18:08, Hugh Glaser wrote:
>> Thanks, Richard.
>> Yeah.
>> But it can be useful if you agree to mint the same MIME type as other people :-)
>> Would one use "application/rdf+thrift” or "application/rdf+x-thrift”, for example?
>> If I remember correctly, the x- usually indicates an unregistered type, but if the type is expected to get registered one day, then people often use the x-less one in anticipation, for future-proofing.
>> 
>> It is especially useful to use an agreed type if you want to consume other peoples’ services/data (or let them consume yours).
>> Of course I realise that is rather unusual in the SemWeb world, but it does happen ;-)
> 
> 
> http://afs.github.io/rdf-thrift/rdf-binary-thrift.html#graphs-and-datasets
> 
> suggests:
> 
> Content type: application/rdf+thrift
> File extensions: rt, trdf
> 
> 	Andy
> 
>> 
>> Best
>> Hugh
>> On 15 Aug 2014, at 17:15, Richard Lewis <richard.lewis@gold.ac.uk> wrote:
>> 
>>> Hi Hugh,
>>> 
>>> While there is a process for registering media types, it's not
>>> necessary for media types to be deposited in some central store in
>>> order to build hypermedia applications using them. In fact, it's quite
>>> common to mint media types specifically for certain applications.
>>> 
>>> If your application design follows RESTful principles, there will be
>>> an application state (or probably multiple states) in which the client
>>> can discover the media types of resources he/she may want to
>>> retrieve. So if you want to make "application/rdf+thrift" (for
>>> example) available for some resources in your application, you can go
>>> right ahead; just make sure you tell the client is told that it's
>>> available.
>>> 
>>> Just my 2p.
>>> 
>>> Richard
>>> 
>>> At Fri, 15 Aug 2014 16:36:44 +0100,
>>> Hugh Glaser wrote:
>>>> 
>>>> Hi Andy,
>>>> Thanks.
>>>> Looks very useful.
>>>> 
>>>> This may be a stoopid question… :-)
>>>> As I am able to use this for network data exchange, presumably I can request it using conneg over http when resolving URIs.
>>>> So I would need a MIME type.
>>>> I see application/x-thrift is required in http://wiki.apache.org/thrift/ThriftIntegrationConventions?highlight=%28application%2Fx-thrift%29
>>>> 
>>>> 
>>>> So now the possibly stooped bit…
>>>> Is there a recommended variant for RDF-Thrift?
>>>> Because I might want to ask for the Thrift version of another content-type, such as non-LD JSON.
>>>> 
>>>> It looks like the same problem as RDF+XML, since I might want another XML content-type of the document.
>>>> 
>>>> Best
>>>> Hugh
>>>> 
>>>> On 15 Aug 2014, at 15:19, Andy Seaborne <andy@apache.org> wrote:
>>>> 
>>>>> RDF Binary using Apache Thrift
>>>>> 
>>>>> This is a binary format for RDF graphs, datasets and SPARQL result
>>>>> sets that is fast to process. [1]
>>>>> 
>>>>>  http://afs.github.io/rdf-thrift/
>>>>> 
>>>>> includes the on-the-wire description as well as an implementation.
>>>>> 
>>>>> Using Apache Thrift makes it considerably less work to integrate
>>>>> into existing systems and toolkits, or to build custom
>>>>> processing. [2]
>>>>> 
>>>>> 	Comments and feedback welcome,
>>>>> 	Andy
>>>>> 
>>>>> [1] The largest gain is on reading data, with rates x3 faster than
>>>>> parsing N-Triples.
>>>>> 
>>>>> [2] Apache thrift has a large number of implementations across a
>>>>> range of languages: http://wiki.apache.org/thrift/LibraryFeatures
>>> --
>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>>> Richard Lewis
>>> Computing, Goldsmiths' College
>>> t: +44 (0)20 7078 5203
>>> @: lewisrichard
>>> http://www.transforming-musicology.org/
>>> 905C D796 12CD 4C6E CBFB  69DA EFCE DCDF 71D7 D455
>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>> 
> 

-- 
Hugh Glaser
   20 Portchester Rise
   Eastleigh
   SO50 4QS
Mobile: +44 75 9533 4155, Home: +44 23 8061 5652

Received on Friday, 15 August 2014 20:40:46 UTC