Feed on
Posts
Comments

folksonomy and *structured* metadata?

Feb 3rd, 2005 by Phil Dawes

WARNING: this is a collection of ill thought-out ideas!

With all the talk of tags and folksonomies, I’ve started wondering whether it might be possible to pull a similar trick with structured metadata - i.e. reducing the precision and accuracy of the metadata in return for increasing the simplicity of metadata creation.

I suspect this idea would cause more problems than it would solve, but exploring it is interesting. For example, you could use the same s,p,o triples model as RDF, but with words(tags) instead of URIs.

E.g.

phildawes isa person
phildawes age 29
phildawes worksfor drkw
phildawes fullname “Phil Dawes”
phildawes plays frenchhorn

frenchhorn isa musicalinstrument etc..

Of course we’d have to capture and rely a lot more on context information for ultimately differentiating between two different ‘phildawes’’s etc.., but the payoff for this increased ambiguity would be simpler creation of metadata and potentually a lot more of it.

At work our most important rdf usecase is having an aggregated store of linked data that can be text-searched and navigated. Since the results are always parsed by humans, this tag approach would probably work quite well here.

<20 minutes later>

Ok, I’ve refined the idea a bit. Instead of a single tag for each resource, we could use a collection of tags to disambiguate it a bit. The collection of tags could be in brackets or something:

(d156126 dell desktop pc) price (749.99 uk pounds)
d156126 isa (desktoppc pc personalcomputer)
d156126 ram (512 megabytes)
d156126 harddrive (40 gigabytes)

(The convention in the above is that the first tag in the brackets is the one you will use to identify the resource in other statements.)

I suppose you could use a pattern-matching query language similar to sparql to search through the metadata, albeit with a lot less precision.
Maybe

select ?a

where ?a isa desktoppc
?a price ?b
?a ram ?c AND ?c < 900 AND pound in ?c

(assuming some stemming for pound)

Hmmmm… Reducing the accuracy of the results would probably allow for a lot looser query syntax. I suppose if you take this to its natural conclusion you get a text search, but this is obviously a little more structured than that.

It’s difficult for me to tell if this is worth persuing further or not. Will sleep on it and think more tomorrow.

Posted in Semantic Web, tagtriples | Comments

Viewing 6 Comments

    • ^
    • v
    I've always said the biggest roadblock to RDF adoption isn't it's semantics, but it's syntax. As soon as we agree on 1) a simple, validatable XML format and 2) a simple text format (yes, N3 exists, but it's neither a standard nor free of the ':' character) we'll be rocking.

    Until we're able to have metadata about tags (as this post suggests) then tags are just keywords. Remeber HTML meta keywords anyone? :)
    • ^
    • v
    Maybe n3 is a simple enough option for your needs?
    • ^
    • v
    I had some thoughts related to this in my post Tag the Tags.
    • ^
    • v
    This conversation definitely needed to get started. I have been thinking about this one ever since I started sketching out how to present the data I have been processing to general web users, semantic users, and to the google machine.

    Ultimately, there will be separate presentations of the same data for human consumption and for machine consumption.

    In designing a better human-readable assertion language, we need to understand our priorities. One important design goal beyond readability is speakability.

    I am thinking of a very formal sort of writing which, while somewhat repetitive, achieves the fluidity of the spoken word. The assertions would have to be translatable into rdf without (m)any errors. That won't be easy.

    What I want to do right now is present my semantic data about finance in a way which will encourage mortal contributors to refer to assertions and even add their own. I cannot expect people to use rdf to interact with a web service, nor perform a lot of gui interaction.
    • ^
    • v
    I ABSOLUTELY agree that the real issue with RDF adoption and use by casual developers and 'knowledge-engineers' as well as buy-in to knowledge-capture software systems that focus on RDF metadata is the tremendous visual mess that comprises the pool of available syntaxes for expressing RDF triples and relationships especially in the context of plain-text. It's just not friendly to the eyes or brain. It's also nearly impossible to implement these in the context of a Wiki or other 'casual' editor systems.

    For the last few years I've been experimenting with and working on a 'tags-triples'-like syntax primarily for use with text-based in-line metadata markup, as in Wiki-type knowledge capture systems. I just started a java-based project for this called Juju ( http://juju.sourceforge.net ), which I will be posting source files and tutorials/examples online sometime in the next couple of weeks. The system's parser-engine will allow for customizable/multiple syntaxes depending on the implementation needs, but the essense of it is that you could write a WikiWord like LukeSkywalker and then define the link like LukeSkywalker>>Brother>>LeiaOrgana or on the LukeSkywalker page, since the context is LukeSkywalker already, it would accept a shortcut like DarthVader>>Father. Note that the direction of the chevrons/double-arrows indicates the direction of the Subject>>Predicate>>Object triple-form, so that a reverse arrow means Object< <predicate><<subject. the="The" shortcut="shortcut" form="form" with="with" a="a" forward="forward" chevron="chevron" assumes="assumes" that="that" the="the" missing="missing" item="item" is="is" the="the">>Father means DarthVader>>Father>>LukeSkywalker and LeiaOrgana<<brother means="means" leiaorgana="LeiaOrgana"><</brother><brother><<lukeskywalker. the="The" system="system" right="right" now="now" doesn="doesn"></lukeskywalker.></brother></subject.></predicate>
    • ^
    • v
    my post got truncated -- i don't know if you got the rest in an email or anything, but i'll be subscribing to your rss and will be posting more on juju soon w/ some more complete examples.
close Reblog this comment
Powered by Disqus · Learn more
blog comments powered by Disqus