fluidinfo: A SemWeb Like a Wiki[pedia] or Like a Google?

Apparently fluidinfo is the new grey (elephant) and we are the blind explorers.  Me too.

  • John Blossom, in a 2011-03-24 post, “Will Fluid Flow to Reality?”, sees Fluidinfo having to contend with Google.  The comparison is with the Google properties served by APIs.  While there might be a collision of some sort, I don’t think the comparison is apt.  For one thing, we don’t have to take any active part in Google’s aggregation of data and delivery of search results.  With Fluidinfo, we (or software that acts for us) are the submitters of “semantic” metadata and we are the ones that have to identify the kinds of our items and what other Fluidinfo-represented entity the data items are related/relevant to.  In effect, we are the curators and the aggregation belongs to Fluidinfo, not us. 
    • If this is the semantic web, it means we are its crowd-source curators and I don’t see how that scales from Fluidinfo as we know of it today.  We have other things to do in our lives and having someone else derive the semantic web is confounded by fine-grained nature of Fluidinfo and the permissions model at that level.  On the other hand, it is shocking that Fluidinfo structures aren’t seen as easily related to RDF.
    • In passing, it is clear that Fluidinfo is not a Facebook competitor either.  Certainly Facebook holds relationships and connections for us, the appeal being their relevance to our personal social interests.  But we don’t have to curate much and the privacy/permissions model is Facebook’s, not ours.  Nowhere does Facebook expose anything as fine-grained as the individual attribute and relationship items of Fluidinfo.  That’s all behind the curtain. 
    • I can imagine a Facebook-like system having a Fluidinfo-style database somewhere underneath, but it would not be exposed to its users and I doubt the service would every expose a Fluidinfo API.  I can’t conceive of the property rights delegating or elevating in any way for that to work.
  • Dylan Love, in his 2011-03-14 summary of Tim O’Reilly’s SXSW interview by Jason Calconis, suggests that Fluidinfo is comparable to Wikipedia on a larger scale. 
    • I disagree that Fluidinfo is like a wiki[pedia], even though the developers imagine differently.  For one thing, Fluidinfo entries are editable by anyone.  You can only edit your own little bits.  In addition, wikis are versioned and the curation of a wiki involves managing the structure and providing a means of navigation and discovery.  The dance is very different as is the support to discovery of places to put things, other places to hook up to.  Fluidinfo’s not even a wiki based on micro-content, since the micro-level permissions would be a nightmare.
    • Although it is not clear how well the FluidDB handles unstructured text in sizable chunks, I can imagine Fluidinfo usage for a kind of FriendFeed that has annotations of others, some private to others, some shared with the originator of an object, some shared with those who can see that object, etc.

The Fluidinfo team is rapidly constructing demonstrations of what can be done, with impressive results.  There are new tools that might help one understand the kinds of structures being used, such as the Fluidinfo Explorer.

It appears that, as much as I am wary of Fluidinfo, the way to wrestle this elephant to the ground is to try it.  Fluidinfo … Like a Virgin?

Enhanced by Zemanta
Advertisements
This entry was posted in Computers and Internet, ecostructure, nfoWorks, Social Networking, trust and tagged , , , , , , . Bookmark the permalink.

5 Responses to fluidinfo: A SemWeb Like a Wiki[pedia] or Like a Google?

  1. Terry Jones says:

    Hi. Thanks for taking time to think and blog about Fluidinfo.

    > In effect, we are the curators and the aggregation belongs to Fluidinfo,
    > not us.

    I’m not sure if I understand. Fluidinfo doesn’t own (or want to own) any of the data it holds. The most important sentence of the Fluidinfo Terms and Conditions is the 3(b) that says your data is your data. http://fluidinfo.com/terms/

    But I have a feeling you mean the Fluidinfo object, onto which the tags are put. The object is like a bucket for tags (and their values). Fluidinfo provides this place, in fact one for everything, but those things are empty of value unless they hold tags. It’s a very interesting question though: who owns the value that is created by the accumulation of information (tags+values) in context. My answer would be that we (i.e., everyone) do. That’s really the point.

    Am I close to understanding what you mean?

    > If this is the semantic web, it means we are its crowd-source
    > curators and I don’t see how that scales from Fluidinfo as we know
    > of it today. We have other things to do in our lives and having
    > someone else derive the semantic web is confounded by fine-grained
    > nature of Fluidinfo and the permissions model at that level.

    I don’t understand this completely either, but I’d really like to.

    > On the other hand, it is shocking that Fluidinfo structures aren’t
    > seen as easily related to RDF.

    It’s easy to look at Fluidinfo from the POV of RDF triples. The combination of an object, a tag and its value gives you a triple. A library was written by Xavier LLora as a gateway of RDF infomation into/out of Fluidinfo. You lose information about users and permissions, but if you’re ok with that then there’s no problem. Would you like me to dig up a reference to that work?

    > I disagree that Fluidinfo is like a wiki[pedia], even though the
    > developers imagine differently. For one thing, Fluidinfo entries
    > are editable by anyone. You can only edit your own little bits.

    Did you mean “not editable”?

    The wikipedia analogy is only an analogy. There are 3 things that Fluidinfo has that make it more suitable for use by applications: permissions (on tags), typed data, and a query language. There are some aspects of the wikipedia analogy that are strong – e.g., we have an object for everything, just as Wikipedia has a page for everything. The use of that object/page is not enforced (well, if you ignore Wikipedia’s editors), it is a convention. Structure and organization is allowed to emerge, etc.

    > In addition, wikis are versioned and the curation of a wiki involves
    > managing the structure and providing a means of navigation and
    > discovery.

    Fluidinfo has/can have those things too (though not versionining at its lowest level – you can very simply add a versionining layer for tags or even objects that need that, though – subject to perms, of course).

    > The dance is very different as is the support to discovery of places
    > to put things, other places to hook up to.

    Yes, agreed. That’s a hard problem.

    > Fluidinfo’s not even a wiki based on micro-content, since the
    > micro-level permissions would be a nightmare.

    And very slow. The permissions are pitched at a simple level, and involve some tradeoffs (I’m not 100% happy with them, but I think they’re pretty nice, and I spent an enormous amount of time thinking about them.).

    > Although it is not clear how well the FluidDB handles unstructured
    > text in sizable chunks

    In theory it’s no problem, though right now really big chunks are going to cause some difficulty (not in storage, I mean in streaming them efficiently). We’ll improve that soon (by which I mean “in 2011”), depending on how important it is for users.

    > I can imagine Fluidinfo usage for a kind of FriendFeed that has
    > annotations of others, some private to others, some shared with the
    > originator of an object, some shared with those who can see that
    > object, etc.

    Yes, that’s right/possible/good.

    > The Fluidinfo team is rapidly constructing demonstrations of what
    > can be done, with impressive results.

    Thanks, we’re trying.

    > There are new tools that might help one understand the kinds of
    > structures being used, such as the Fluidinfo Explorer.

    We didn’t write the explorer BTW, though we do give its author (Pier-Andre Parent) lots of feedback :-) And we began to pay him to add features to it, provided it was open source.

    > It appears that, as much as I am wary of Fluidinfo, the way to
    > wrestle this elephant to the ground is to try it. Fluidinfo
    > … Like a Virgin?

    LOL :-)

    It’s good to be wary. From my own POV, I think Fluidinfo is something that would be better as some kind of public utility, and open sourced. I’d love to figure out how to get there in some sensible way. I sold my apartment to make it all happen, after trying to do it in other contexts (mainly academic). It hasn’t been easy. This isn’t a sob story though, and I hope there will be a way to push Fluidinfo in the best possible direction. I’m very idealistic about it all, and at the same time would also like to get my apartment back one day. I’d love to find a way to satisfy both goals – also hard. But well worth fighting for.

    Anyway, I like the way you think, and thanks for bothering(!), and would be happy to discuss more. Why not drop by #fluidinfo on irc.freenode.net and say hi. Or, mail terry at fluidinfo com.

    Terry

    • orcmid says:

      I think this comment is longer than my post. I need to respond to a few bits, but I need to think about it a little.

      Yes, I did mean to say “not editable.” There’s something dramatically different than the wiki case here, because I can only edit my material (and the license needs to be fixed with regard to what I can read). In order to accomplish collaborative curation, a wiki feature, we need an out-of-band arrangement in order to keep significant bits in sync. Wiki is loose in the other direction, where you need an out-of-band arrangement or a sheriff to prevent revision collisions/wars.

      Still thinking about it …

    • orcmid says:

      And thanks for your thoughtful reply. It definitely provides more to think about, and suggests to me some places where I need to sharpen my own thinking.

  2. Hi,

    I’ll jump in too…

    You say, “On the other hand, it is shocking that Fluidinfo structures aren’t seen as easily related to RDF.”

    It’s not true and I hope Terry’s response goes some way to address this.

    My point in the blog post is that I simply didn’t have the time or patience to wade through a tag soup of namespaces, XML, OWL, SPARQL and all the other semantic-web technology in order to get the data I wanted.

    It’s telling that it was easier/simpler/faster to extract the required information from O’Reilly’s website with a scraper than use their existing semantic-web based API.

    I concede that this is also a reflection of my particular skill-set but I think it’s fair to say that learning semantic-web tech is not a quick and easy thing to achieve and many people simply don’t have the time.

    For me, one of the most important aspects of Fluidinfo is that it is very simple to use and easy to learn. While I applaud and share the aims and objectives of the semantic-web “movement” I think it is just too complex to fly.

    Why..? Well, the semantic-web has been the “next big thing” for over a decade – ever since TBL’s original Scientific American article and we’re still waiting for significant mainstream adoption.

    • orcmid says:

      I think I conflated something, and it also creeps into demonstrations of Fluidinfo.

      You’re right, I was reacting to the observation about RDF and setting up the O’Reilly book list “API” (and please stop using API for everything).

      I agree that tearing apart RDF can be quite daunting. On the other hand, once it is all converted into triples, I would expect there is some way to transform it into Fluidinfo and the reverse.

      I’m a bit puzzled whether there is not a natural fit with RDF triples and I wonder if the use of URIs in RDF collides with the URI-like use of domain names in Fluidinfo (sort of URIs without the “http://”). Now I’m curious. Is it an use case that RDF triples can be represented in Fluidinfo and be recovered unscathed?

      I am not surprised that you have tools for screen scraping information that is structured as nicely as the catalog, especially if you can have it enumerated, rather than having to know each ISBN. The individual catalog pages have everything needed in their <head> elements, which is also handy, I grant you.

      I think it is valuable to separate the extraction process from the injection process. Then we can examine how the extracted material of interest is structured (in some data structure) and how that is turned into data conveyed in individual requests using the Fluidinfo API. I’m actually not familiar enough with the Fluidinfo API and the model behind it to appreciate that just yet but that is the place I would want to look to understand what was involved.

      I look forward to further tutorial and demonstration cases on the Fluidinfo site. Thanks for the feedback.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s