What i'm saying is that the amazon format IS machine readable. The format ALWAYS comes after the title information. It is in a predictable location, as designated by the tags.
Look at HTML, we have the syntax for HTML, which ideally is an XML format. Then the semantics of how the syntax is to be interpreted is located in a browser, or, if the designer wants to specify more closely what things mean, they use Cascading Style Sheets.
There, there's your semantics.
Why do we need a universal hammer, to be able to beat all data formats into a fixed semantic framework? So long as you have a syntax that gets at the properties that someone is concerned with, i don't understand why we need some sort of new semantic frame work. The current framework is as expressive as you want it to be. If you want your docs to be more expressive in terms of meta-data, go for it. There's nothing holding you back. In fact i'd gander theres more than enough meta-data out tehre to do what you want -already-. That's my point.
Next, we have the option of making complex parsers, or making our data extremely complex. I'd say make the tools complicated, and leave the data alone, that way data creation isn't hard, and anyone can do it. Complex tools only need to be made once.
And i never said anything about error prone searching or parsing algorithms. the point is to make tools that actually work My point is that all data that is easy to transform into RDF format, is already machine processable, so why do we need RDF? If we have coherent local semantics (i.e. how CSS works), a global semantics is redundant so long as the local semantics are handled in an intellegent way.
This is the problem with SGML. SGML asks you to specify too much crap to be comprehensible. The point of using XML is that you only need to specify those things that you're going to use. It's task oriented, without other cruft. I understand the problem of interoperability local formats (try playing with phonesets for acoustic data, that's a hairy problem), but the problem of interoperable formats doesn't go away when you attempt to integrate everything into any global format. Different formats are useful for different things (as you've pointed out), and may in fact be mutually exclusive. But all switching to a new format does, is bring all of these things to a head, as opposed to offering a solution for how they are to be resolved.
So what i'm saying is, easily convertable data formats are already interoperable without a new global data format, or require minimal mutilation, and those things that are not easily convertable, we are still left with no recourse, unless you want to kludge them together the best you can.
Again, i'm not convinced.
Furthermore, how is collecting a bunch of book marks, any different from what google does? And what's more, i trust google's method of associating links people put on webpages more than i do statistics on people's personal filing systems for book marks.
Posts: 4482 | Registered: May 2000
| IP: Logged |
posted
Tom, not really true. Unix systems and windows have minimal metadata attributes (file extensions and ?? Or do you consider the default application stuff metadata? That's really system stuff, it's not an actual aspect of the file.). Apple had rudimentary metadata.
BeOS had true metadata. You had, say a contact file for a person? One piece of metadata for it could be, say, a picture of the person. Emails could be just the message, with all the To:, From:, etc., data as metadata attributed to the file (Which also much easier viewing of the message from any app). You could also do searches on the metadata.
Lately some OSes and filesystems have gotten to where BeOS was (and BeOS has been dead for 2-3 years now), and windows won't be close (or surpass it) until 2005 (Longhorn) at the earliest.
Of course, my message was just a way to point out that Longhorn's stuff isn't conceptually groundbreaking.
posted
Alright fugu, so you're more concerned with a query format, rather than some sort of overarching semantic format
Posts: 4482 | Registered: May 2000
| IP: Logged |
posted
The formats are only easily convertible at the source. If y ou're not at the source, to aggregate that data from all those sources would take huge parsing libraries. Instead of one small RDF parsing library.
Posts: 15770 | Registered: Dec 2001
| IP: Logged |
posted
fugu my question is, how do I utilize this powerful pedigree type system when no one that has any relevance for my serach is using it? It seems pretty pointless.
Just for grins, I'll give you the name of my dog's father: Ch. Phi Vestavia Nautilus PT
and his mother: Ch. Kingsbury's Copyright
How do I use your semantic system to get to the rest of the pedigree?
posted
Anna, that's sort of the issue issue that things like XML are, in part, trying to address. Right now, it might not mean much, but using an open flexible system like XML increases the likelihood that going forward, your data can be easily translated to whatever systems are created that can do this.
Whether it's a Vet app that uses lineage to track birth defects/genetic diseases, a canine family tree application, or maybe a dog show results application that can easily display who else in a dog's family tree was a winner, and when, and who was the breeder or trainer, etc...
You can find that now using multiple repositories that often are redundant, and not easily converted from one format to the next. having a single format allows the applications more flexibility in WHAT it wants to do with the data, rather than HOW it needs to prepare some data for use.
posted
Pod -- no, its just that it can serve as a query format. However, it is also a semantic format.
Consider RSS. RSS is a part pf the semantic web, and is in all version related to RDF (in some it is RDF).
Why are so many websites providing RSS feeds? After all, all the information in the RSS feeds is already available on the websites.
They are providing RSS feeds because RSS feeds are a better encoding for certain purposes, such as being read by an RSS reader. For an RSS reader to have to be able to parse any site in existence and determine the semantic articles, their subjects, their descriptions, what their primary link on the web is, their author, their date of publication, et cetera is ridiculous
That's what you're saying semantic web applications should have to do when you're saying the information is already out there and applications should just have to understand it as it is.
Posts: 15770 | Registered: Dec 2001
| IP: Logged |
posted
I'd certainly use such a browser if I had options that allowed me to: turn off that behavior, submit anonymously if I wanted, choose where the information went, and customize what information was sent (folder-based exclusion, for instance).
All of which would be easy to implement.
Posts: 15770 | Registered: Dec 2001
| IP: Logged |
posted
I guess I'm just not getting it. I was trying to understand, really. But for it to be useful for me, seems virtually impossible, since the people who are actually making web pages that I check aren't doing the kind of programming necessary to make it work.
posted
Its in its infancy. There are only three major semantic web technologies right now, Dublin Core Metadata (DC), RSS and Friend Of A Friend (FOAF) (well, other than RDF, which all are closely related to).
Consider HTML. Everybody didn't start making web sites overnight. In fact, many people said the same thing about HTML -- that it was too arcane for any normal person to actually use.
You're talking about an application in a very specialized domain -- dog pedigrees. Its not useful to you right now because frankly, not much attention has been given to applying it to dog pedigrees. Its in its infancy. Its presence is not a magic bullet. A lot of work is still required to make it work. However, the way RDF works makes it so most of that work needs only be done by the vocabulary designers, rather than those using the vocabularies.
It would not be hard at all to imagine, for instance, when an RDF vocabulary has been created for dog pedigrees, that there was a simple tool for creating pedigrees -- you either enter a name or select an already entered name for a dog's parents, then enter a name for the dog. Rinse, repeat. You could import RDF files using the pedigree vocabulary from other people, and their dogs would appear on the list of possible dogs to choose as parents. Et cetera. There would of course be birthdates and other data involved; I'm not sure of exactly what sorts of things are kept track of in dog pedigrees, but you get the idea. Then at the end the person would export a file for their dogs called pedigrees.rdf and put the following in their html, in the head tag
posted
I understand that dog pedigrees are a bit arcane.
But right now I can just google and at least find what I need with a bit of hunting.
I don't know, can't you make this semantic web AI some how so it can learn the information from existing web pages? It seems like that would be a lot less tedious then requiring everybody in the world to start programing in this, when most people can barely manage html.
posted
The idea is not to have everyone in the world start programming RDF, but to have the tools they already use in programming do it for them, or at the worst have easy to use tools, such as this one:
If you have a blog, you're probably already using RDF without knowing it. If you have a livejournal, you're already using RDF. Et cetera. Applications are enabled to create RDF, people don't type it out by hand.
Posts: 15770 | Registered: Dec 2001
| IP: Logged |
posted
ok that makes more sense... you just sort of sneak it into the code behind the scenes and the people that are using it never really know it exists even if they reap the benefits.
On the other hand that would make people like Tom more paranoid than they already are.
posted
Google searches work well for returning single datapoints, but not for finding multiple datapoints.
Consider if your grocery store has an online database. Perhaps you want to know what kinds and the prices of chocolate chips they carry. Easy enough, you'd go to the site and find the chocolate chips.
But what if you want to compare prices from all the nearby grocery stores? Well, first you have to look up all the nearby grocery stores, then you have to visit all their sites, then you have to compare the prices manually.
If there was an online business location database that spoke RDF, which returned globally unique URIs for each grocery store chain (just the homepage of the store would work), and each grocery store's website spoke RDF, an RDF enabled application for browsing for different kinds of stores and services would be able to understand and execute a query like: find the types and prices of chocolate chips available at grocery stores within 10 miles, and group by type.
The really cool thing is, that application wouldn't have to know about the particulars of each grocery store's system at all! That's whats holding such applications up from being ubiquitous -- there are occasional applications that only need to draw from one or two websites, such as for movie information, but the difficulty is in parsing the content of the site. With RDF, parsing the content of the site becomes trivial and programmers can focus on ways to allow people to make complex and useful queries instead, and on presenting those queries in useful ways (on a map, et cetera).
Posts: 15770 | Registered: Dec 2001
| IP: Logged |
Printer-friendly view of this topic
![[Wink]](wink.gif)
My point is that all data that is easy to transform into RDF format, is already machine processable, so why do we need RDF? If we have coherent local semantics (i.e. how CSS works), a global semantics is redundant so long as the local semantics are handled in an intellegent way.
