Re: [whatwg] Fuzzbot (Firefox RDFa semantics processor)
Martin Atkins wrote: One problem this can solve is that an agent can, given a URL that represents a person, extract some basic profile information such as the person's name along with references to other people that person knows. This can further be applied to allow a user who provides his own URL (for example, by signing in via OpenID) to bootstrap his account from existing published data rather than having to re-enter it. So, to distill that into a list of requirements: - Allow software agents to extract profile information for a person as often exposed on social networking sites from a page that represents that person. - Allow software agents to determine who a person lists as their friends given a page that represents that person. - Allow the above to be encoded without duplicating the data in both machine-readable and human-readable forms. Is this the sort of thing you're looking for, Ian? Much of the above section could be applied to any other RDF vocabulary with a bit of search and replace, but I'll leave that to others since FOAF is the only RDF vocabulary with which I have any experience. Why we must restrict the use case to a single vocabulary or analyze all the possibile vocabularies? I think it's be better to generalize the problem and find a unique solution for human/machine. I tried to expose this here... http://lists.w3.org/Archives/Public/public-html/2009Jan/0082.html ...where the fundamental problem is described in this way: - User agents must allow users to see that there are semantic-links (connections to semantically structured informations) in a HTML document/application. Consequently user agents must allow users to follow the semantic-link, (access/interact with the linked data, embedded or external) and this involves primarily the ability to: a) view the informations b) select the informations c) copy the informations in the clipboard d) drag and drop the informations e) send that informations to another web application (or to OS applications) selected by the user. -- Giovanni Gentili
Re: [whatwg] Fuzzbot (Firefox RDFa semantics processor)
Giovanni Gentili wrote: Why we must restrict the use case to a single vocabulary or analyze all the possibile vocabularies? I think it's be better to generalize the problem and find a unique solution for human/machine. The issue when trying to abstract problems is that you can end up doing architecture astronautics; you concentrate on making generic ways to build solutions to weakly constrained problems without any attention to the details of those problems that make them unique. The solutions that are so produced often have the theoretical capacity to solve broad classes of problem, but are often found to be poor at solving any specific individual problem. By looking at actual use cases we can hope to retain enough detail in the requirements that we satisfy at least some use cases well, rather than wasting out time building huge follies that serve no practical purpose to anyone.
Re: [whatwg] Fuzzbot (Firefox RDFa semantics processor)
James Graham: The issue when trying to abstract problems is that you can end up doing architecture astronautics; you concentrate on making generic ways to build solutions to weakly constrained problems without any attention to the details of those problems that make them unique. I think the right level, like in my proposal, is greatly under astronautics but no so low as single vocabularies. -- Giovanni Gentili
Re: [whatwg] Fuzzbot (Firefox RDFa semantics processor)
Giovanni Gentili wrote: James Graham: The issue when trying to abstract problems is that you can end up doing architecture astronautics; you concentrate on making generic ways to build solutions to weakly constrained problems without any attention to the details of those problems that make them unique. I think the right level, like in my proposal, is greatly under astronautics but no so low as single vocabularies. I rather disagree. How we interact with information depends fundamentally on the type of information. If the information is a set of geographical coordinates, for example, the set of useful interactions are rather different to those for a bibliographic entry. Trying to pretend that the two problems are just interchangeable instances of the same semantically structured information problem is likely to hide the important distinctions between the two problem domains.
Re: [whatwg] Fuzzbot (Firefox RDFa semantics processor)
Martin Atkins wrote: ... If it is true that RDFa can work today with no ill-effect in downlevel user-agents, what's currently blocking its implementation? Concern for validation? It seems to me that many HTML extensions are implemented first and specified later[1], so perhaps it would be in the interests of RDFa proponents to get some implementations out there and get RDFa adopted, at which point it will hopefully seem a much more useful proposition for inclusion in HTML5. In the short term the RDFa community can presumably provide a specialized HTML5 + RDFa validator for adopters to use until RDFa is incorporated into the core spec and tools. It would seem that it's much easier to get into the spec when your feature is proven to be useful by real-world adoption. ... What he said. Although I *do* believe that in the end we'll want RDFa-in-HTML5, what's really important right now is *not* RDFa-in-HTML5 but RDFa-in-HTML4. Define that, make it a success, and the rest will be simple. Best regards, Julian
Re: [whatwg] Fuzzbot (Firefox RDFa semantics processor)
Martin Atkins wrote: * Some sites are already publishing XFN and/or hCard so consuming software would need to continue to support these in addition to FOAF-in-HTML-somehow, which is more work than supporting only XFN and hCard. Mitigating this though is GRDDL which allows the hCard+XFN to be parsed using a subset of FOAF (e.g. http://weborganics.co.uk/hFoaF/) and thus merged with FOAF available as RDF/XML, RDFa, etc. -- Toby A Inkster mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk
Re: [whatwg] Fuzzbot (Firefox RDFa semantics processor)
On Jan 11, 2009, at 14:01, Toby A Inkster wrote: RDFa *does not* rely on XML namespaces. RDFa relies on eight attributes: about, rel, rev, property, datatype, content, resource and typeof. It also relies on a CURIE prefix binding mechanism. In XHTML and SVG, RDFa happens to use XML namespaces as this mechanism, because they already existed and they were convenient. Convenience is debatable. In any case, it is rather disingenuous to say that RDFa doesn't rely on XML Namespaces when all that has been defined so far relies of attributes whose qname contains the substring xmlns. In non-XML markup languages, the route to define CURIE prefixes is still to be decided, though discussions tend to be leaning towards something like: html prefix=dc=http://purl.org/dc/terms/ foaf=http://xmlns.com/foaf/0.1/ address rel=foaf:maker rev=foaf:madeThis document was made by a href=http://joe.example.com; typeof=foaf:Person rel=foaf:homepage property=foaf:nameJoe Bloggs/a./address /html Unless this syntax were also used for XHTML, the above would be in violation of the DOM Consistency Design Principle of the W3C HTML WG. This discussion seems to be about should/can RDFa work in HTML5? when in fact, RDFa already can and does work in HTML5 - there are approaching a dozen interoperable implementations of RDFa, the majority of which seem to handle non-XHTML HTML. Those implementations violate the software implementation reuse principle that motivates the DOM Consistency Design Principle. (The software reuse principle being that the same code path be used for both HTML and XHTML on layers higher than the parser.) The prefix mapping mechanism of CURIEs has been designed with disregard towards this software reuse principle (in use in Gecko, WebKit and, I gather, Presto) that should have been known to anyone working on Web-related specs far before DOM Consistency was written into the Design Principles of the HTML WG. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Fuzzbot (Firefox RDFa semantics processor)
Calogero Alex Baldacchino wrote:
The concern is about every kind of metadata with respect to their
possible uses; but, while it's been stated that Microforamts (for
instance) don't require any purticular support by UAs (thus they're
backward compatible), RDFa would be a completely new feature, thus
html5
specification should say what UAs are espected to do with such new
attributes.
RDFa doesn't require any special support beyond the special support
that is required for Microformats. i.e. nothing. User agents are free
to ignore the RDFa attributes. In that sense, RDFa already works in
pretty much every existing browser, even going back to dinosaurs like
Mosaic and UdiWWW.
Agents are of course free to offer more than that. Look at what they
do with Microformats: Firefox for instance offers an API to handle
Microformats embedded on a page; Internet Explorer offers its Web
Slices feature.
For what concerns html serialization, in particular, I'd consider
some code like [...] which is rendered properly
Is it though? Try adding the following CSS:
span[property=cal:summary] { font-weight: bold; }
And you'll see that CSS doesn't cope with a missing ending tag in
that situation either.
If you miss out a non-optional end tag, then funny things will happen
- RDFa isn't immune to that problem, but neither is the DOM model,
CSS, microformats, or anything else that relies on knowing where
elements end. A better comparison would be a missing /p tag, which
is actually allowed in HTML, and HTML-aware RDFa processors can
generally handle just fine.
considering RDFa relies on namespaces (thus,
adding RDFa attributes to HTML5 spec would require some features from
xml extensibility to be added to html serialization).
RDFa *does not* rely on XML namespaces. RDFa relies on eight
attributes: about, rel, rev, property, datatype, content, resource
and typeof. It also relies on a CURIE prefix binding mechanism. In
XHTML and SVG, RDFa happens to use XML namespaces as this mechanism,
because they already existed and they were convenient. In non-XML
markup languages, the route to define CURIE prefixes is still to be
decided, though discussions tend to be leaning towards something like:
html prefix=dc=http://purl.org/dc/terms/ foaf=http://xmlns.com/foaf/
0.1/
address rel=foaf:maker rev=foaf:madeThis document was made by
a href=http://joe.example.com; typeof=foaf:Person
rel=foaf:homepage property=foaf:nameJoe Bloggs/a./address
/html
This discussion seems to be about should/can RDFa work in HTML5?
when in fact, RDFa already can and does work in HTML5 - there are
approaching a dozen interoperable implementations of RDFa, the
majority of which seem to handle non-XHTML HTML. Assuming that people
see value in RDFa, and assuming that the same people see value in
using HTML5, then these people will use RDFa in HTML5. The question
we should be discussing is not should it work? (because it already
does), but rather, should it validate?
--
Toby A Inkster
mailto:m...@tobyinkster.co.uk
http://tobyinkster.co.uk
Re: [whatwg] Fuzzbot (Firefox RDFa semantics processor)
Toby A Inkster wrote: Calogero Alex Baldacchino wrote: The concern is about every kind of metadata with respect to their possible uses; but, while it's been stated that Microforamts (for instance) don't require any purticular support by UAs (thus they're backward compatible), RDFa would be a completely new feature, thus html5 specification should say what UAs are espected to do with such new attributes. RDFa doesn't require any special support beyond the special support that is required for Microformats. i.e. nothing. User agents are free to ignore the RDFa attributes. In that sense, RDFa already works in pretty much every existing browser, even going back to dinosaurs like Mosaic and UdiWWW. Agents are of course free to offer more than that. Look at what they do with Microformats: Firefox for instance offers an API to handle Microformats embedded on a page; Internet Explorer offers its Web Slices feature. If it is true that RDFa can work today with no ill-effect in downlevel user-agents, what's currently blocking its implementation? Concern for validation? It seems to me that many HTML extensions are implemented first and specified later[1], so perhaps it would be in the interests of RDFa proponents to get some implementations out there and get RDFa adopted, at which point it will hopefully seem a much more useful proposition for inclusion in HTML5. In the short term the RDFa community can presumably provide a specialized HTML5 + RDFa validator for adopters to use until RDFa is incorporated into the core spec and tools. It would seem that it's much easier to get into the spec when your feature is proven to be useful by real-world adoption. [1] canvas, keygen, frames and script are examples of this phenomenon.
Re: [whatwg] Fuzzbot (Firefox RDFa semantics processor)
Toby A Inkster ha scritto:
Calogero Alex Baldacchino wrote:
The concern is about every kind of metadata with respect to their
possible uses; but, while it's been stated that Microforamts (for
instance) don't require any purticular support by UAs (thus they're
backward compatible), RDFa would be a completely new feature, thus html5
specification should say what UAs are espected to do with such new
attributes.
RDFa doesn't require any special support beyond the special support
that is required for Microformats. i.e. nothing. User agents are free
to ignore the RDFa attributes. In that sense, RDFa already works in
pretty much every existing browser, even going back to dinosaurs like
Mosaic and UdiWWW.
Agents are of course free to offer more than that. Look at what they
do with Microformats: Firefox for instance offers an API to handle
Microformats embedded on a page; Internet Explorer offers its Web
Slices feature.
Well, at the beginning of this thread the possible need to interchange
RDF metadata and merge triples from different vocabularies was suggested
as a use case for RDFa serialization of RDF, and this would hint a
requirement for supporting an RDFa processor in every conforming UA.
This also opens a question about what else might be needed beside
collecting triples (is an API to build custom query applications enough,
or should some query feature be provided by browsers? are there possible
problems involved (like possible spam through fake metadata in cached
ads)? possible solutions to prevent or moderate it?).
If, otherwise, nothing special must be done by browsers with RDFa
attributes, and instead their main use is for script or plugin or
server-side computations, or for free support by UA, these ones would
be no way different from any other kind of custom attributes (thus
should a validation requirement be let's accept every attribute?),
herein included data-*, but for the /intended use/, which may make the
difference but is something only a human can understand, and no
validator can check (from this point of view, validating RDFa
attributes, whatever else attribute, or just html5 attributes and custom
data-* ones would be the same, as validating would not be a concern as
it isn't for proprietary CSS extensions).
For what concerns html serialization, in particular, I'd consider
some code like [...] which is rendered properly
Is it though? Try adding the following CSS:
span[property=cal:summary] { font-weight: bold; }
And you'll see that CSS doesn't cope with a missing ending tag in that
situation either.
If you miss out a non-optional end tag, then funny things will happen
- RDFa isn't immune to that problem, but neither is the DOM model,
CSS, microformats, or anything else that relies on knowing where
elements end. A better comparison would be a missing /p tag, which
is actually allowed in HTML, and HTML-aware RDFa processors can
generally handle just fine.
That's definetely *not* the same issue. As I've replied in a previous
mail, people *do not* need proper styling to understend prose, they just
need to understand the prose language, then their /brains/ will cope
with the rest, thus the above example results in some acceptable
graceful degradation (it may or may not be the wanted presentation,
depending on where the closing /span was to be positioned (it wouldn't
be the right presentation in this case), but it is not too harmful
anyway). Bots based on metadata, instead *do need* reliable metadata to
work properly, unless they're made smart enough to debug the code
they're fed (should Artificial Intelligence be a requirement? - no
sarcasm here).
If broken/wrong presentation caused by a missing end tag had ever been
an issue, html-serialization would have been deprecated in favour of
xml-one (if something really problematic happened, authors would
notice it on their very first test by opening a page in a browser,
whereas an extensive and complete debug for triples might be an odd
problem in a large document). In contrast with that, any break in
metadata semantics caused by html-serialization can only be a sever
issue for a metadata-based bot (because it needs accurate metadata,
while a non-very-accurate presentation is not a great concern for human
beings in most cases, and if no particular presentation is attached to
those spans, but instead they're used just to add semantics through
metadata, as it happens to embedd RDF through RDFa attributes, a
side-effect may arise), thus html-serialization may be more prone to
side-effects than xml-serialization (which stops on validation errors,
being in turn a possible cause for side-effects with metadata), from
this point of view -- that is, since RDFa semantics is more reliable in
a more well-formed document, xml-serialization might help to debug some
errors, while it is not a strict requirement for content presentation,
and instead finding more or less emboldened
Re: [whatwg] Fuzzbot (Firefox RDFa semantics processor)
On Sun, 11 Jan 2009, Toby A Inkster wrote: RDFa doesn't require any special support beyond the special support that is required for Microformats. i.e. nothing. User agents are free to ignore the RDFa attributes. In that sense, RDFa already works in pretty much every existing browser, even going back to dinosaurs like Mosaic and UdiWWW. Is this true? One of the problems I thought we were trying to solve was that browsers were dumb, and the idea was that we wanted to enable browsers to take free-form questions from the user and answer them. It seems to me that if the browser doesn't have any special support, then this use case is not met. The question we should be discussing is not should it work? (because it already does), but rather, should it validate? No, the question is what problem are we solving?. Talking about RDFa, RDF, eRDF, Microformats, and so forth doesn't answer this question. The question should it validate is the question do we want to solve the problem and is this the right solution, which is a question we can't answer without actually knowing what the problem is. So far, all I really know is that the problem is apparently obvious. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fuzzbot (Firefox RDFa semantics processor)
Ian Hickson wrote: The question we should be discussing is not should it work? (because it already does), but rather, should it validate? No, the question is what problem are we solving?. Talking about RDFa, RDF, eRDF, Microformats, and so forth doesn't answer this question. The question should it validate is the question do we want to solve the problem and is this the right solution, which is a question we can't answer without actually knowing what the problem is. So far, all I really know is that the problem is apparently obvious. My understanding of the use-case, based on discussions so far, is: - Allow authors to embed annotations in HTML documents such that RDF triples can be unambiguously extracted from human-readable data without duplicating the data, and thus ensuring that the machine-readable data and the human-readable data remain in sync. The disconnect you're facing is that the proposers of RDFa consider the ability to encode RDF triples to be a goal, while you consider RDF triples to be a solution to a (as-yet-undetermined) higher-level problem. They take RDF as a given, while you do not. They have already solved some problems with RDF and wish only to adapt this generalized solution to work in HTML, while you wish to re-solve all of these problems from the ground up. Would you agree with this analysis? If this is accurate, then it's difficult to see how continued discussion on this topic can be productive.
Re: [whatwg] Fuzzbot (Firefox RDFa semantics processor)
On Sun, 11 Jan 2009, Martin Atkins wrote: The disconnect you're facing is that the proposers of RDFa consider the ability to encode RDF triples to be a goal, while you consider RDF triples to be a solution to a (as-yet-undetermined) higher-level problem. They take RDF as a given, while you do not. Agreed. They have already solved some problems with RDF and wish only to adapt this generalized solution to work in HTML, while you wish to re-solve all of these problems from the ground up. I don't necessarily wish to resolve the problems -- if they have existing good solutions, I'm all in favour of reusing them. I just want to know what those problems are that we're solving, so that we can make sure that the solutions we're adopting are in fact solving the problems we want to solve. It would be irresponsible to add features without knowing why. If this is accurate, then it's difficult to see how continued discussion on this topic can be productive. Well presumably if the RDF and RDFa communities have already solved some problems, it will be possible for them to tell us what those problems are. That's all I'm asking for. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fuzzbot (Firefox RDFa semantics processor)
Ian Hickson wrote: They have already solved some problems with RDF and wish only to adapt this generalized solution to work in HTML, while you wish to re-solve all of these problems from the ground up. I don't necessarily wish to resolve the problems -- if they have existing good solutions, I'm all in favour of reusing them. I just want to know what those problems are that we're solving, so that we can make sure that the solutions we're adopting are in fact solving the problems we want to solve. It would be irresponsible to add features without knowing why. I would assume that our resident proponents are already satisfied that their higher-level problem have been solved, and this is why they're frustrated that you won't just let them map their existing solutions into HTML all in one fell swoop. I'm not sure I'd put myself into the RDF proponent bucket, but I do know one use-case of RDF that I've encountered frequently so I'll post it as a starting point. The FOAF schema for RDF[0] addresses the problem of making personal profile data machine-readable along with some of the relationships between people. From the outside looking in, it seems that the goal they set themselves was to make machine-readable the sort of information you find on a social networking site. One problem this can solve is that an agent can, given a URL that represents a person, extract some basic profile information such as the person's name along with references to other people that person knows. This can further be applied to allow a user who provides his own URL (for example, by signing in via OpenID) to bootstrap his account from existing published data rather than having to re-enter it. Google Social Graph API[1] apparently makes use of FOAF (when serialized as XML) as one of the sources of data so that given a URL that represents a person it can return a list of URLs that represent friends of that person. The Google Profiles application[2] makes use of the output of the Social Graph API to suggest URLs that a user might want to list on his profile page, so the user only needs to fill in a couple of URLs by hand. So, to distill that into a list of requirements: - Allow software agents to extract profile information for a person as often exposed on social networking sites from a page that represents that person. There is a number of existing solutions for this: * FOAF in RDF serialized as XML, Turtle, RDFa, eRDF, etc * The vCard format * The hCard microformat * The PortableContacts protocol[3] * Natural Language Processing of HTML documents - Allow software agents to determine who a person lists as their friends given a page that represents that person. Again, there are competing solutions: * FOAF in RDF serialized as XML, Turtle, RDFa, eRDF, etc * The XFN microformat[4] * The PortableContacts protocol[3] * Natural Language Processing of HTML documents --- Assuming that the above is a convincing problem domain, now let's add in the following requirement: - Allow the above to be encoded without duplicating the data in both machine-readable and human-readable forms. Now our solution list is reduced to (assuming we consider both requirements together): * FOAF in RDF serialized as RDFa or eRDF * The hCard microformat + the XFN microformat * Natural Language Processing of HTML documents All three of the above options address the use-cases as I stated them -- the Social Graph API apparently uses all three if you're willing to consider a MySpace-specific screen-scraper as Natural Language Processing -- so what would be the advantages of the first solution? * Existing RDF-based systems can use an off-the-shelf RDFa or eRDF parser and get the same data model (RDF triples of FOAF predicates) that they were already getting from the XML and Turtle RDF serializations, reducing the amount of additional work that must be done to consume this format. * FOAF has an extensive vocabulary that's based on fields that have been observed on social networking sites, while hCard is built on vCard which has a more constrained scope intended for the sort of entries you'd expect to find in an address book. * FOAF has been adopted -- usually in the RDF-XML serialization -- by some number of social networking sites (e.g. LiveJournal) so they are presumably already somewhat familiar with the FOAF vocabulary and may therefore be able to adopt it more easily in the RDFa or eRDF serializations. Though there are of course also some disadvantages: * Some sites are already publishing XFN and/or hCard so consuming software would need to continue to support these in addition to FOAF-in-HTML-somehow, which is more work than supporting only XFN and hCard. (In other words, XFN/hCard already work today) * RDFa requires extensions to the HTML language, while XFN, hCard and NLP do
Re: [whatwg] Fuzzbot (Firefox RDFa semantics processor)
On Sun, 11 Jan 2009, Martin Atkins wrote: One problem this can solve is that an agent can, given a URL that represents a person, extract some basic profile information such as the person's name along with references to other people that person knows. This can further be applied to allow a user who provides his own URL (for example, by signing in via OpenID) to bootstrap his account from existing published data rather than having to re-enter it. So, to distill that into a list of requirements: - Allow software agents to extract profile information for a person as often exposed on social networking sites from a page that represents that person. - Allow software agents to determine who a person lists as their friends given a page that represents that person. - Allow the above to be encoded without duplicating the data in both machine-readable and human-readable forms. Is this the sort of thing you're looking for, Ian? Yes, the above is perfect. (I cut out the bits that weren't really the problem from the quote above -- the above is what I'm looking for.) The most critical part is allow a user who provides his own URL to bootstrap his account from existing published data rather than having to re-enter it. The one thing I would add would be a scenario that one would like to be able to play out, so that we can see if our solution would enable that scenario. For example: I have an account on social networking site A. I go to a new social networking site B. I want to be able to automatically add all my friends from site A to site B. There are presumably other requirements, e.g. site B must not ask the user for the user's credentials for site A (since that would train people to be susceptible to phishing attacks). Also, site A must not publish the data in a manner that allows unrelated users to obtain privacy-sensitive data about the user, for example we don't want to let other users determine relationships that the user has intentionally kept secret [1]. It's important that we have these scenarios so that we can check if the solutions we consider are actually able to solve these problems, these scenarios, within the constraints and requirements we have. [1] http://w2spconf.com/2008/papers/s3p2.pdf -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fuzzbot (Firefox RDFa semantics processor)
Manu Sporny ha scritto: Calogero Alex Baldacchino wrote: That is, choosing a proper level of integration for RDF(a) support into a web browser might divide success from failure. I don't know what's the best possible level, but I guess the deepest may be the worst, thus starting from an external support through out plugins, or scripts to be embedded in a webbapp, and working on top of other feature might work fine and lead to a better, native support by all vendors, yet limited to an API for custom applications There seems to be a bit of confusion over what RDFa can and can't do as well as the current state of the art. We have created an RDFa Firefox plugin called Fuzzbot (for Windows, Linux and Mac OS X) that is a very rough demonstration of how an browser-based RDFa processor might operate. If you're new to RDFa, you can use it to edit and debug RDFa pages in order to get a better sense of how RDFa works. The concern is about every kind of metadata with respect to their possible uses; but, while it's been stated that Microforamts (for instance) don't require any purticular support by UAs (thus they're backward compatible), RDFa would be a completely new feature, thus html5 specification should say what UAs are espected to do with such new attributes. Shall UAs just accept them and expose an API to extract triples, so that a web application can build a query mechanism upon such an API? This might work fine, and fulfill small-scale scenarios, such as organization-wise data modelling and interchanging, as suggested by Charls McCathieNevile; this can also be accomplished by an external plugin. Shall UAs (browsers) also provide an interface to view bare triples (as does Fuzzbot), as a kind of debugging tool? As above. Shall UAs (browsers) also provide metadata-based features, such as a query interface to look for content in a local history? This is a wider scale application, and also a use case where problems may arise. From this angle, metadata can't be assumed as reliable apriori (instead, their reliability is uncertain), nor can users be deemed capable to understand the problem and filter out wrong/misused/abused metadata (in general). This is the scenario were spammy metadata may become an issue. For instance, some code like, div typeof=foaf:Person p property=foaf:name content=Manu SpornyWe sell a href=http://www.cheatingcarseller.com; rel=foaf:homepagecars/a /p /div would produce the following triples, _:bnode0 rdf:type http://xmlns.com/foaf/0.1/Person _:bnode0 foaf:homepage http://www.cheatingcarseller.com _:bnode0 foaf:name Manu Sporny (this is exactly what Fuzzbot outputs) thus, a metadata-based search feature might output a link to a metadata-spammy site when queried for Manu Sporny. That is, cheating a metadata-based bot by the mean of fake metadata can be very easy. Metadata-based features, but this is true for most of xml-related technologies (such as RDF/RDFa), work fine if properly used. Unluckily, things must be used properly to work fine is not the basic principle of the web (and this is specially true for html and related technologies), which instead has always been about people will mess everything up, but UAs will work fine as well, that is robustness before all, as far as possible. For what concerns html serialization, in particular, I'd consider some code like, p typeof=cal:Vevent I'm holding span property=cal:summary one last summer Barbecue !-- /span --, to meet friends and have a party before the end of holidays on span property=cal:dtstart content=2007-09-16T16:00:00-05:00 datatype=xsd:dateTime September 16th at 4pm /span. /p (taken from http://www.w3.org/TR/2008/REC-rdfa-syntax-20081014/ and purposedly modified) which is rendered properly, but produces, _:bnode1 rdf:type http://www.w3.org/2002/12/cal/icaltzd#Vevent _:bnode1 cal:dtstart 2007-09-16T16:00:00-05:00 _:bnode1 cal:summary one last summer Barbecue , to meet friends and have a party before the end of holidays on span xmlns:cal=http://www.w3.org/2002/12/cal/icaltzd#; xmlns:foaf=http://xmlns.com/foaf/0.1/; xmlns:xsd=http://www.w3.org/2001/XMLSchema#; xmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns#; datatype=xsd:dateTime datatype=xsd:dateTime content=2007-09-16T16:00:00-05:00 property=cal:dtstartSeptember 16th at 4pm/span (taken from Fuzzbot keeping namespace declarations in the root element; without xmlns:* attributes all triples are lost) which is not the desired result. Perhaps it might work better as an xml feature on a strict xml parser (aborting with an error because of a missing end tag), even considering RDFa relies on namespaces (thus, adding RDFa attributes to HTML5 spec would require some features from xml extensibility to be added to html serialization). But RDFa in an XHTML document might look like rdfa:about, rdfa:property, rdfa:content, and
Re: [whatwg] Fuzzbot (Firefox RDFa semantics processor) (was: Trying to work out the problems solved by RDFa)
Calogero Alex Baldacchino wrote: That is, choosing a proper level of integration for RDF(a) support into a web browser might divide success from failure. I don't know what's the best possible level, but I guess the deepest may be the worst, thus starting from an external support through out plugins, or scripts to be embedded in a webbapp, and working on top of other feature might work fine and lead to a better, native support by all vendors, yet limited to an API for custom applications There seems to be a bit of confusion over what RDFa can and can't do as well as the current state of the art. We have created an RDFa Firefox plugin called Fuzzbot (for Windows, Linux and Mac OS X) that is a very rough demonstration of how an browser-based RDFa processor might operate. If you're new to RDFa, you can use it to edit and debug RDFa pages in order to get a better sense of how RDFa works. There is a primer[1] to the semantic web and an RDFa basics[2] tutorial on YouTube for the completely un-initiated. The rdfa.info wiki[3] has further information. (sent to public-r...@w3.org earlier this week): We've just released a new version of Fuzzbot[4], this time with packages for all major platforms, which we're going to be using at the upcoming RDFa workshop at the Web Directions North 2009 conference[5]. Fuzzbot uses librdfa as the RDFa processing back-end and can display triples extracted from webpages via the Firefox UI. It is currently most useful when debugging RDFa web page triples. We use it to ensure that the RDFa web pages that we are editing are generating the expected triples - it is part of our suite of Firefox web development plug-ins. There are three versions of the Firefox XPI: Windows XP/Vista (i386) http://rdfa.digitalbazaar.com/fuzzbot/download/fuzzbot-windows.xpi Mac OS X (i386) http://rdfa.digitalbazaar.com/fuzzbot/download/fuzzbot-macosx-i386.xpi Linux (i386) - you must have xulrunner-1.9 installed http://rdfa.digitalbazaar.com/fuzzbot/download/fuzzbot-linux.xpi There is also very preliminary support for the Audio RDF and Video RDF vocabularies, demos of which can be found on YouTube[6][7]. To try it out on the Audio RDF vocab, install the plugin, then click on the Fuzzbot icon at the bottom of the Firefox window (in the status bar): http://bitmunk.com/media/6566872 There should be a number of triples that show up in the frame at the bottom of the screen as well as a music note icon that shows up in the Firefox 3 AwesomeBar. To try out the Video RDF vocab, do the same at this URL: http://rdfa.digitalbazaar.com/fuzzbot/demo/video.html Please report any installation or run-time issues (such as the plug-in not working on your platform) to me, or on the librdfa bugs page: http://rdfa.digitalbazaar.com/librdfa/trac -- manu [1] http://www.youtube.com/watch?v=OGg8A2zfWKg [2] http://www.youtube.com/watch?v=ldl0m-5zLz4 [3] http://rdfa.info/wiki [4] http://rdfa.digitalbazaar.com/fuzzbot/ [5] http://north.webdirections.org/ [6] http://www.youtube.com/watch?v=oPWNgZ4peuI [7] http://www.youtube.com/watch?v=PVGD9HQloDI -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Fibers are the Future: Scaling Past 100K Concurrent Requests http://blog.digitalbazaar.com/2008/10/21/scaling-webservices-part-2
