[TagCommons-WG] mechanisms for sharing tag data

[Nitin Borwankar]

Tom Gruber wrote:

> Having identified what might be possible, we can move to looking at 
> how to accomplish it -- the mechanisms for sharing.
>
>  
>
> Here is a quick list of ways that people have shared data on the web:
>
> -          point-to-point translation of static data files with a 
> proprietary data formats
>
> -          point-to-point integration using data derived by crawling 
> and screen-scraping sites
>
> -          point-to-point integration using an API (REST, Web Service, 
> etc) that assumes a particular data model and encapsulates the format 
> in code
>
> -          point-to-point integration accessing databases with 
> documented schemas
>
> -          common content formats, such as microformats and I-tags
>
> -          common database schemas using a standard schema definition 
> language
>
> -          common ontologies and RDF for interchange
>
>  
>
> Notice that there are two kinds of sharing -- point-to-point and 
> through a common mechanism.  You can still write point-to-point 
> mappings using a common mechanism, but the difference is the common 
> mechanism is N-to-1 to a canonical format/model, where the others 
> mechanisms require many-to-many mappings.   For example, to map from 
> one system's API to another, you have to know the contract and 
> assumptions of each system at operational, format, and semantic levels. 
>
>  
>
> Within the common convention approaches, the formats are more 
> constrained than the database schemas, which are more constrained than 
> the ontologies.  In other words, the level of abstraction is going up 
> from formats to schemas to ontologies, and therefore the differences 
> in contract and assumptions are going down.  Still, one could provide 
> mechanisms at the format level to account for semantic distinctions, 
> and enforce them with a social contract.  For instance, microformats 
> encode "semantic" (nonpresentational) information in the HTML "class" 
> element, such as <div class="vcard">, where the string "vcard" is 
> known by convention to mean that the markup in the div element is a 
> format-level representation of a contact.
>
>  
>
Hi Tom,

I think multiple mechanisms are needed.  I work in areas where 
ontologies are not used but formats and database schemas are.
One thing we could and should first agree upon is a glossary so that, at 
the least,  words mean the same thing across all these mechanisms.

Tag,
Tagging,
Tag Source,
Item,
Item type,
Agent,
Tag Source Namespace,
Tag Collection/ Tag Bundle
.....


I am wary of acccepting a single database schema at this stage ( even 
though I think the ones suggested at tagschema.com are quite useful ;-) 
) or a single ontology.
Let's instead agree on common  *interfaces* without, at this stage, 
insisting on one common internal representation or the other.

So from my view point we should start at the outside - a REST interface 
and work our way in.
A REST interface would need a set of operations and a format for 
returned data.
Once we agree on what the "fine structure" of  a tag is or at least what 
part of it we can agree upon, then lightweight data structures expressed 
in YAML ( or JSON ) fall out of that.  So we would have to work at the 
"intersection" of our respective models, first.

This would encourage data providers to expose their data in compliance 
with the "TagCommons REST API and formats" and data consumers that write 
apps
to use it, without all of us *first* having to agree on database schemas 
or ontologies.  That agreement may never happen or need to happen and 
those conversations
can sometimes go on for ever or quickly become closed conversations.

Clearly this cut at the "TagCommons REST API and format" would be a 
"least common denominator" interface, which would allow us to make 
progress while we thrash out the differences in schemas and ontologies. 
The key design challenge is to incorporate extensibility of the data 
formats so that we could add elements to the tag structure in future 
without breaking this interface.

In my mind the key catalyst to future interoperability is to do 
something concrete and incremental,  like a REST API,  that mobilizes 
*syntactic* mashups using a common
interface, first.

Once applications can speak to each other in a common language *then* 
they can discuss the meaning of 'meaning'.

> Thanks.  It would be great if we could do this phase in a week or so.
>
Could you be more specific in which of the stated tasks you include in 
"this phase" ?



Nitin.

>  
>
> Best,
>
> Tom
>
>  
>
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>WG mailing list
>WG at tagcommons.org
>http://lists.tagcommons.org/listinfo.cgi/wg-tagcommons.org
>  
>


-- 
Nitin Borwankar

http://greener.com
Find, Learn, Act .... Greener, the search engine for the planet

http://tagschema.com
Implementation of tag database applications

nitin at borwankar.com
510-872-7066