GoodRelations vs. Google RDFa vs. Open Graph vs. hProduct/hListing: Using GoodRelations in 10 Triples
Dear all: Some people think that the GoodRelations ontology for e-commerce (http://purl.org/goodrelations/) is powerful, but complex. I think it is important for everybody in the community to know that GoodRelations can be as simple (or simpler) than any more lightweight approach for product markup, as long as you compare the same level of granularity. Below, please find an example of offering a car for sales in just ten (!) triples. Of course, you can do more with GoodRelations than just encoding a price and carrying the semantics of the product itself in a string. The important message in here is that simple chunks of data are as simple in GoodRelations as they are in hProduct/hListing microformats, Google's RDFa vocabulary, or the Open Graph product markup. The key difference is that GoodRelations has a much more extensible and, in my biased ;-) judgement: cleaner, conceptual model so that IF you have more granular data available, THEN you can expose it, and make your products more findable on the Web. For example, GoodRelations distinguishes between products and product models / datasheets. That allows for powerful linking between individual items and rich technical specifications from the manufacturer's page. The Open Graph approach seems to use a plain topic semantics, which mixes items, datasheets, and offers. Please keep that in mind and spread the word. Here is the markup. Best wishes Martin Turtle/N3: = @prefix foo: http://www.example.com/xyz# . @prefix gr: http://purl.org/goodrelations/v1# . @prefix xsd: http://www.w3.org/2001/XMLSchema# . @prefix rdfs: http://www.w3.org/2000/01/rdf-schema# . foo:company a gr:BusinessEntity; gr:legalName Hepp Space Ventures Inc.; gr:offers foo:offering. foo:offering a gr:Offering; rdfs:label Volkswagen Station Wagon, 4WD, 400 $@en; rdfs:description I sell my old Volkswagen Station Wagon, 4WD, for 400 $@en; gr:hasPriceSpecification [ a gr:UnitPriceSpecification; gr:hasCurrencyValue 400^^xsd:string; gr:hasCurrency USD^^xsd:string. ]. RDFa: div xmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns#; xmlns:rdfs=http://www.w3.org/2000/01/rdf-schema#; xmlns=http://www.w3.org/1999/xhtml; xmlns:gr=http://purl.org/goodrelations/v1#; xmlns:foo=http://www.example.com/xyz#; xmlns:xsd=http://www.w3.org/2001/XMLSchema#; div about=http://www.example.com/xyz#company; typeof=gr:BusinessEntity div property=gr:legalName content=Hepp Space Ventures Inc./div div rel=gr:offers div about=http://www.example.com/xyz#offering; typeof=gr:Offering div property=rdfs:label content=Volkswagen Station Wagon, 4WD, 400 $ xml:lang=en/div div property=rdfs:description content=I sell my old Volkswagen Station Wagon, 4WD, for 400 $ xml:lang=en/div div rel=gr:hasPriceSpecification div typeof=gr:UnitPriceSpecification div property=gr:hasCurrency content=USD datatype=xsd:string/div div property=gr:hasCurrencyValue content=400 datatype=xsd:string/div /div /div /div /div /div /div RDF/XML: === ?xml version=1.0? rdf:RDF xmlns:gr=http://purl.org/goodrelations/v1#; xmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns#; xmlns:foo=http://www.example.com/xyz#; xmlns:xsd=http://www.w3.org/2001/XMLSchema#; xmlns:rdfs=http://www.w3.org/2000/01/rdf-schema#; gr:BusinessEntity rdf:about=http://www.example.com/xyz#company; gr:legalNameHepp Space Ventures Inc./gr:legalName gr:offers gr:Offering rdf:about=http://www.example.com/xyz#offering; rdfs:label xml:lang=enVolkswagen Station Wagon, 4WD, 400 $/rdfs:label rdfs:description xml:lang=enI sell my old Volkswagen Station Wagon, 4WD, for 400 $/rdfs:description gr:hasPriceSpecification gr:UnitPriceSpecification gr:hasCurrencyValue rdf:datatype=http://www.w3.org/2001/XMLSchema#string;400/gr:hasCurrencyValue gr:hasCurrency rdf:datatype=http://www.w3.org/2001/XMLSchema#string;USD/gr:hasCurrency /gr:UnitPriceSpecification /gr:hasPriceSpecification /gr:Offering /gr:offers /gr:BusinessEntity /rdf:RDF -- -- martin hepp e-business web science research group universitaet der bundeswehr muenchen e-mail: h...@ebusiness-unibw.org phone: +49-(0)89-6004-4217 fax: +49-(0)89-6004-4620 www: http://www.unibw.de/ebusiness/ (group) http://www.heppnetz.de/ (personal) skype: mfhepp twitter: mfhepp Check out GoodRelations for E-Commerce on the Web of Linked Data! = Project page: http://purl.org/goodrelations/ Resources for developers: http://www.ebusiness-unibw.org/wiki/GoodRelations Webcasts: Overview - http://www.heppnetz.de/projects/goodrelations/webcast/ How-to - http://vimeo.com/7583816 Recipe for Yahoo SearchMonkey: http://www.ebusiness-unibw.org/wiki/GoodRelations_and_Yahoo_SearchMonkey Talk at the Semantic Technology Conference 2009: Semantic Web-based E-Commerce: The GoodRelations Ontology
Re: GoodRelations vs. Google RDFa vs. Open Graph vs. hProduct/hListing: Using GoodRelations in 10 Triples
Apologies - There were a few minor bugs in the initial markup: - I forgot the business function. - The datatype for the price was xsd:string instead of xsd:float. - The legal name had no language tag. The correct examples are at http://ebusiness-unibw.org/pipermail/goodrelations/2010-May/000215.html On 03.05.10 10:38, Martin Hepp (UniBW) wrote: Dear all: Some people think that the GoodRelations ontology for e-commerce (http://purl.org/goodrelations/) is powerful, but complex. I think it is important for everybody in the community to know that GoodRelations can be as simple (or simpler) than any more lightweight approach for product markup, as long as you compare the same level of granularity. Below, please find an example of offering a car for sales in just ten (!) triples. Of course, you can do more with GoodRelations than just encoding a price and carrying the semantics of the product itself in a string. The important message in here is that simple chunks of data are as simple in GoodRelations as they are in hProduct/hListing microformats, Google's RDFa vocabulary, or the Open Graph product markup. The key difference is that GoodRelations has a much more extensible and, in my biased ;-) judgement: cleaner, conceptual model so that IF you have more granular data available, THEN you can expose it, and make your products more findable on the Web. For example, GoodRelations distinguishes between products and product models / datasheets. That allows for powerful linking between individual items and rich technical specifications from the manufacturer's page. The Open Graph approach seems to use a plain topic semantics, which mixes items, datasheets, and offers. Please keep that in mind and spread the word. Here is the markup. Best wishes Martin -- -- martin hepp e-business web science research group universitaet der bundeswehr muenchen e-mail: h...@ebusiness-unibw.org phone: +49-(0)89-6004-4217 fax: +49-(0)89-6004-4620 www: http://www.unibw.de/ebusiness/ (group) http://www.heppnetz.de/ (personal) skype: mfhepp twitter: mfhepp Check out GoodRelations for E-Commerce on the Web of Linked Data! = Project page: http://purl.org/goodrelations/ Resources for developers: http://www.ebusiness-unibw.org/wiki/GoodRelations Webcasts: Overview - http://www.heppnetz.de/projects/goodrelations/webcast/ How-to - http://vimeo.com/7583816 Recipe for Yahoo SearchMonkey: http://www.ebusiness-unibw.org/wiki/GoodRelations_and_Yahoo_SearchMonkey Talk at the Semantic Technology Conference 2009: Semantic Web-based E-Commerce: The GoodRelations Ontology http://www.slideshare.net/mhepp/semantic-webbased-ecommerce-the-goodrelations-ontology-1535287 Overview article on Semantic Universe: http://www.semanticuniverse.com/articles-semantic-web-based-e-commerce-webmasters-get-ready.html Tutorial materials: ISWC 2009 Tutorial: The Web of Data for E-Commerce in Brief: A Hands-on Introduction to the GoodRelations Ontology, RDFa, and Yahoo! SearchMonkey http://www.ebusiness-unibw.org/wiki/Web_of_Data_for_E-Commerce_Tutorial_ISWC2009
Re: GoodRelations vs. Google RDFa vs. Open Graph vs. hProduct/hListing: Using GoodRelations in 10 Triples
On 3 May 2010, at 09:38, Martin Hepp (UniBW) wrote: Dear all: Some people think that the GoodRelations ontology for e-commerce (http://purl.org/goodrelations/) is powerful, but complex. [snip] Turtle/N3: = @prefix foo: http://www.example.com/xyz# . @prefix gr: http://purl.org/goodrelations/v1# . @prefix xsd: http://www.w3.org/2001/XMLSchema# . @prefix rdfs: http://www.w3.org/2000/01/rdf-schema# . foo:company a gr:BusinessEntity; gr:legalName Hepp Space Ventures Inc.; gr:offers foo:offering. foo:offering a gr:Offering; rdfs:label Volkswagen Station Wagon, 4WD, 400 $@en; rdfs:description I sell my old Volkswagen Station Wagon, 4WD, for 400 $@en; gr:hasPriceSpecification [ a gr:UnitPriceSpecification; gr:hasCurrencyValue 400^^xsd:string; gr:hasCurrency USD^^xsd:string. ]. Hi Martin, it does not seem to complex to me. I wonder if the following could make it even simpler though: First I think, why not make the currency a literal? foo:offering a gr:Offering; rdfs:label Volkswagen Station Wagon, 4WD, 400 $@en; rdfs:description I sell my old Volkswagen Station Wagon, 4WD, for 400 $@en; gr:hasPriceSpecification [ a gr:UnitPriceSpecification; gr:value 400^^gr:USD; ] . When you have a relation from a string to a value, you have a literal. monetary values are good examples it seems to me of this. It would remove at least three of your URL usages, as you had to specify the xsd:string twice, and also the type of the currency. Also in your example you could put the company in a different file, and refer to it by reference. Then your example would just be foo:offering a gr:Offering; is gr:offers of foo:company; rdfs:label Volkswagen Station Wagon, 4WD, 400 $@en; rdfs:description I sell my old Volkswagen Station Wagon, 4WD, for 400 $@en; gr:hasPriceSpecification [ a gr:UnitPriceSpecification; gr:value 400^^gr:USD; ] . now we are down to 7 relations.
Re: GoodRelations vs. Google RDFa vs. Open Graph vs. hProduct/hListing: Using GoodRelations in 10 Triples
Hi Henry,
Thanks for your feedback!
I wonder if the following could make it even simpler though:
First I think, why not make the currency a literal?
foo:offering a gr:Offering;
rdfs:label Volkswagen Station Wagon, 4WD, 400 $@en;
rdfs:description I sell my old Volkswagen Station Wagon, 4WD, for 400
$@en;
gr:hasPriceSpecification
[ a gr:UnitPriceSpecification;
gr:value 400^^gr:USD;
] .
When you have a relation from a string to a value, you have a literal. monetary
values are good
examples it seems to me of this. It would remove at least three of your URL
usages, as you had
to specify the xsd:string twice, and also the type of the currency.
There are several reasons for using the current GoodRelations pattern.
The most important one is that GoodRelations represents all point values
internally as intervals, in order to support reasoning over ranges with
simple RDFS-style reasoners. As for prices, that has been an explicit
request from the hotel domain.
So gr:hasCurrencyValue is an rdfs:subPropertyOf gr:hasMaxCurrencyValue
AND of gr:hasMinCurrencyValue. This gives a nice coherent model for
point values and intervals, without the need for a SPARQL endpoint and
either a bit of RDFS-style reasoning or a bit of SPARQL query expansion.
Example:
# 3..4 USD per kilogram, e.g. depending on the size of the potatoes
foo:price a gr:UnitPriceSpecification ;
gr:hasCurrency USD^^xsd:string ;
gr:hasMinCurrencyValue 3.0^^xsd:float ;
gr:hasMaxCurrencyValue 4.0^^xsd:float ;
gr:hasUnitOfMeasurement KGM^^xsd:string ;
gr:valueAddedTaxIncluded true^^xsd:boolean .
# 4 USD per kilogram
foo:price a gr:UnitPriceSpecification ;
gr:hasCurrency USD^^xsd:string ;
gr:hasCurrencyValue 4.0^^xsd:float ;
gr:hasUnitOfMeasurement KGM^^xsd:string ;
gr:valueAddedTaxIncluded true^^xsd:boolean .
Both will work with the following query:
# find something that has a price or upper price limit of less than 4
USD / kg
SELECT ?offer WHERE
{
?offer a gr:Offering .
?offer gr:hasPriceSpecification ?p .
?p gr:hasMaxCurrencyValue ?v .
?p gr:hasCurrency USD^^xsd:string .
?p gr:UnitOfMeasurement KGM^^xsd:string .
FILTER (?p = 4)
}
The important message is that, without any domain-specific tweak of the
GoodRelations vocabulary, you can model things as simple as this
foo:offering a gr:Offering;
rdfs:label Volkswagen Station Wagon, 4WD, 400 $@en;
rdfs:comment I sell my old Volkswagen Station Wagon, 4WD, for 400
$@en;
gr:hasBusinessFunction gr:Sell;
gr:hasPriceSpecification
[ a gr:UnitPriceSpecification;
gr:hasCurrencyValue 400^^xsd:float;
gr:hasCurrency USD^^xsd:string. ].
and as fine-granular as this:
# Boat Rental: 24 USD / 6 hours for 0-3 days, 75 USD per day for any
longer rental
foo:company a gr:BusinessEntity ;
gr:legalName Hepp Space Ventures, Inc.@en ;
gr:offers foo:boat_offer.
foo:boat_offer a gr:Offering ;
rdfs:label Boat rental@en ;
rdfs:comment We rent out boats@en ;
gr:hasBusinessFunction gr:LeaseOut ;
gr:hasPriceSpecification foo:rental_price1, foo:rental_price2 .
foo:rental_price1 a gr:UnitPriceSpecification ;
gr:hasCurrency USD^^xsd:string ;
# 24 USD per 6 hours = 4 USD / hour
gr:hasCurrencyValue 4^^xsd:float ;
gr:hasUnitOfMeasurement HUR^^xsd:string ;
gr:billingIncrement 6^^xsd:float
gr:valueAddedTaxIncluded true^^xsd:boolean ;
gr:hasEligibleQuantity [ a gr:QuantitativeValueInteger ;
gr:hasUnitOfMeasurement DAY^^xsd:string ;
gr:hasMinValueInteger 0^^xsd:int ;
gr:hasMaxValueInteger 3^^xsd:int . ].
foo:rental_price2 a gr:UnitPriceSpecification ;
gr:hasCurrency USD^^xsd:string ;
gr:hasCurrencyValue 75^^xsd:float ;
gr:hasUnitOfMeasurement DAY^^xsd:string ;
gr:valueAddedTaxIncluded true^^xsd:boolean ;
gr:hasEligibleQuantity [ a gr:QuantitativeValueInteger ;
gr:hasUnitOfMeasurement DAY^^xsd:string ;
gr:hasMinValueInteger 4^^xsd:int . ].
And both use the same set of conceptual elements, and will basically
trigger the very same SPARQL queries. That is a major difference to any
other conceptual approach for product / offer data on the Web - to keep
the simple things simple while supporting the very complex cases off the
box.
Also in your example you could put the company in a different file, and refer
to it by
reference.
Yes, I agree. In particular, in RDFa one will use the rev attribute to
do that.
Best
Martin
--
--
martin hepp
e-business web science research group
universitaet der bundeswehr muenchen
e-mail:h...@ebusiness-unibw.org
phone: +49-(0)89-6004-4217
fax: +49-(0)89-6004-4620
www:http://www.unibw.de/ebusiness/ (group)
http://www.heppnetz.de/ (personal)
skype: mfhepp
twitter: mfhepp
Re: GoodRelations vs. Google RDFa vs. Open Graph vs. hProduct/hListing: Using GoodRelations in 10 Triples
FYI - This may also be of interest for anybody of you working on linked data for e-commerce. Best Martin Hepp Original Message Subject: More examples of modeling price information with GoodRelations Date: Mon, 03 May 2010 17:47:48 +0200 From: Martin Hepp (UniBW) martin.h...@ebusiness-unibw.org Reply-To: martin.h...@ebusiness-unibw.org Organization: http://www.heppnetz.de To: goodrelations goodrelati...@ebusiness-unibw.org Dear all: I just completed a new GoodRelations recipe that describes how GoodRelations can be used to model price information in more detail, e.g. - quantity discounts, - seasonal discounts and special offers, - billing increments, - price ranges, - combining flat and metered price components (25 USD / day plus 1 USD per mile), and - cancellation policies. Please check http://www.ebusiness-unibw.org/wiki/GoodRelationsPricing Best wishes Martin Hepp -- -- martin hepp e-business web science research group universitaet der bundeswehr muenchen e-mail: h...@ebusiness-unibw.org phone: +49-(0)89-6004-4217 fax: +49-(0)89-6004-4620 www: http://www.unibw.de/ebusiness/ (group) http://www.heppnetz.de/ (personal) skype: mfhepp twitter: mfhepp Check out GoodRelations for E-Commerce on the Web of Linked Data! = Project page: http://purl.org/goodrelations/ Resources for developers: http://www.ebusiness-unibw.org/wiki/GoodRelations Webcasts: Overview - http://www.heppnetz.de/projects/goodrelations/webcast/ How-to - http://vimeo.com/7583816 Recipe for Yahoo SearchMonkey: http://www.ebusiness-unibw.org/wiki/GoodRelations_and_Yahoo_SearchMonkey Talk at the Semantic Technology Conference 2009: Semantic Web-based E-Commerce: The GoodRelations Ontology http://www.slideshare.net/mhepp/semantic-webbased-ecommerce-the-goodrelations-ontology-1535287 Overview article on Semantic Universe: http://www.semanticuniverse.com/articles-semantic-web-based-e-commerce-webmasters-get-ready.html Tutorial materials: ISWC 2009 Tutorial: The Web of Data for E-Commerce in Brief: A Hands-on Introduction to the GoodRelations Ontology, RDFa, and Yahoo! SearchMonkey http://www.ebusiness-unibw.org/wiki/Web_of_Data_for_E-Commerce_Tutorial_ISWC2009
rdf/json
All, Is there an RDF+JSON serialization of RDF, I see mention by Openlink, Talis, RDFQuery etc but not much else. Primarily, is there a spec? a working group? any work being done to standardise? Increasingly more convinced that rdf+json will be mission critical very soon, hence the question. Best, Nathan
Re: rdf/json
The spec is here: http://n2.talis.com/wiki/RDF_JSON_Specification But I don't know about your other questions. -Ross. On Mon, May 3, 2010 at 12:25 PM, Nathan nat...@webr3.org wrote: All, Is there an RDF+JSON serialization of RDF, I see mention by Openlink, Talis, RDFQuery etc but not much else. Primarily, is there a spec? a working group? any work being done to standardise? Increasingly more convinced that rdf+json will be mission critical very soon, hence the question. Best, Nathan
Re: rdf/json
Davide Palmisano wrote: On 5/3/10 6:25 PM, Nathan wrote: All, Hi Nathan, Is there an RDF+JSON serialization of RDF, I see mention by Openlink, Talis, RDFQuery etc but not much else. Primarily, is there a spec? a working group? any work being done to standardise? if you mean inside W3C, I think that the answer is still not, but for sure JSON serialization will be a topic to be discussed here[1]. [1] http://www.w3.org/2009/12/rdf-ws/ Thanks, that's what I needed - noting the Topics: ... possible new serialization formats (eg, Atom, Turtle, or JSon serializations) ... That'll do, Cheers Nathan
Re: rdf/json
Perhaps this has already been suggested, but the linked-data-api folks have an overview of json serializations for rdf [1] that might be of some interest. //Ed [1] http://code.google.com/p/linked-data-api/wiki/JSONFormats
replacing email with atom and foaf+ssl
In the early days of Atom, people were speaking of using it to replace e-mail. This is in fact easy to do, we just need to try it out. 1. The problem. --- Before explaining the solution, it is important to understand the problem. Currently Atom works like a public mailing list: everyone can read everybody's published email/post/entry. The advantage over mailing lists, is that emails automatically have global identifiers, and that the content does not need to be shoved around global networks, as spam has to be currently. People GET the entry when they want to. What we want is to be able to narrow this down, so that one can publish (email) to only a select number of people: to one's friends for example, or just to one person. Ie we want to do the same with Atom as we do with email. This requires two things: - A way of notifying someone or a group of a new post for them - A way of allowing software to access a atom entry in one simple click 2. The Solution --- 2.1 RESTful Identity and Authentication --- foaf+ssl gives us WebIds, global identifiers tied to a public key, which allows one click authentication. This works in all browsers. There is more here: http://esw.w3.org/Foaf%2Bssl/FAQ You can try some early demos out by going to http://webid.myxwiki.org/ for example or any of the list of Identity Providers http://esw.w3.org/Foaf%2Bssl/IDP Without foaf+ssl this is not really possible. Getting a username/password for each of one's friends web servers would be impossibly complex, tedious and insecure. OpenId is close, but still too complex, though it can also be made to work nicely with foaf+ssl. 2.2 A ping mechanism It just requires one new relation to be added to a foaf file. A link to a simple form, which could be a atompub:Collection / sioc:Container [1]. I went into this in great detail in a recent post where I cover what I know of the pinging mechanism history, and show how this can be simplified further. http://markmail.org/message/kzsg3qntovmqzbje Writing such a pinging mechansim is really really easy. Adding a relation to a foaf is also easy, as we can see from the recent adoption by Facebook, which is rdfa enabling all its web pages. 2.3 Usage - When you want to publish an atom entry to someone, you would just need one of their WebIds, and give access to only that WeBId for that entry. (A good GUI would speak of this in a human way of course) How would you get that WebId? Well if you have a blog for them, you have their atom ID which can be used to find a webid. Or they could just give it to you at a party on a card. Or it could be linked to from one of your friends foaf file When your reader access it, he just connects to your server with https, the server asks the client for the X509 certificate, which can be sent. On authentication the Entry is returned. That's all there is to it. 3. Result - As a result we would have a system that would be pure p2p, RESTful email equivalent. If A sends B a message, only A and B (and routers along the way) need to know about that communication. Nobody else. With email they are routed all over the place, for all kinds of people to observe. Furthermore one would have built in SSL security in as a default. Finally it is really easy to add client cert support to any application, as this is completely standard based. Any thoughts? Henry [1] http://rdfs.org/sioc/spec/ Social Web Architect http://bblfish.net/
Re: [foaf-protocols] replacing email with atom and foaf+ssl
Story Henry wrote: In the early days of Atom, people were speaking of using it to replace e-mail. This is in fact easy to do, we just need to try it out. 1. The problem. --- Before explaining the solution, it is important to understand the problem. Currently Atom works like a public mailing list: everyone can read everybody's published email/post/entry. The advantage over mailing lists, is that emails automatically have global identifiers, and that the content does not need to be shoved around global networks, as spam has to be currently. People GET the entry when they want to. What we want is to be able to narrow this down, so that one can publish (email) to only a select number of people: to one's friends for example, or just to one person. Ie we want to do the same with Atom as we do with email. This requires two things: - A way of notifying someone or a group of a new post for them - A way of allowing software to access a atom entry in one simple click 2. The Solution --- 2.1 RESTful Identity and Authentication --- foaf+ssl gives us WebIds, global identifiers tied to a public key, which allows one click authentication. This works in all browsers. There is more here: http://esw.w3.org/Foaf%2Bssl/FAQ You can try some early demos out by going to http://webid.myxwiki.org/ for example or any of the list of Identity Providers http://esw.w3.org/Foaf%2Bssl/IDP Without foaf+ssl this is not really possible. Getting a username/password for each of one's friends web servers would be impossibly complex, tedious and insecure. OpenId is close, but still too complex, though it can also be made to work nicely with foaf+ssl. 2.2 A ping mechanism It just requires one new relation to be added to a foaf file. A link to a simple form, which could be a atompub:Collection / sioc:Container [1]. I went into this in great detail in a recent post where I cover what I know of the pinging mechanism history, and show how this can be simplified further. http://markmail.org/message/kzsg3qntovmqzbje Writing such a pinging mechansim is really really easy. Adding a relation to a foaf is also easy, as we can see from the recent adoption by Facebook, which is rdfa enabling all its web pages. 2.3 Usage - When you want to publish an atom entry to someone, you would just need one of their WebIds, and give access to only that WeBId for that entry. (A good GUI would speak of this in a human way of course) How would you get that WebId? Well if you have a blog for them, you have their atom ID which can be used to find a webid. Or they could just give it to you at a party on a card. Or it could be linked to from one of your friends foaf file When your reader access it, he just connects to your server with https, the server asks the client for the X509 certificate, which can be sent. On authentication the Entry is returned. That's all there is to it. 3. Result - As a result we would have a system that would be pure p2p, RESTful email equivalent. If A sends B a message, only A and B (and routers along the way) need to know about that communication. Nobody else. With email they are routed all over the place, for all kinds of people to observe. Furthermore one would have built in SSL security in as a default. Finally it is really easy to add client cert support to any application, as this is completely standard based. Any thoughts? Henry, Good call, I've been thinking about this a lot recently and there is certainly a huge amount of scope. Things I'm certain of: - FOAF+SSL is needed - HTTP should be the interface - all communications should be handled RESTfully - Resources should be Web Access Controlled (via ACL+WebID) - The receive flow should be: notification of new message, GET message Thing(s) I'm unsure of: - Atom(/Pub) vs LinkedData Linked Data can represent anything we want, surely to use linked data rather than Atom would allow the scope of this to be so much more, allowing any kind of message to be sent. Sioc:Container and Items together with the additional sioc type extensions would appear to cover 99% of scenarios. Considerations of SPARUL, SPARQL and SPARQL+Pubsubhubbub for custom notification streams. However, Atom(/Pub) is already here, defined, widely accepted and would allow a quick implementation without too much work, and you could ensure that each message could be handled due to having set parameters in Atom (whereas in linked data it could be any ontology with no guaranteed presence of rdfs:label or suchlike) Further, Atom(/Pub) would add in much scope for current work on the likes of activitystrea.ms to be incorporated / made interoperable etc. (and possibly OData/GData..?) Side: By defining a standardized HTTP RESTful messaging system
Semantic Elephants: Versioning, URIs, UniqueIds, owl:sameAs, Managing Coreference
All, I analyzed some past threads and teased out and summarized three distinct modeling issues. 1. Overloading OWL sameAshttp://ontologydesignpatterns.org/wiki/Community:Overloading_OWL_sameAs: sameAs is being used in the linked data community in a way that is inconsistent with its semantics 2. Proliferation of URIs, Managing Coreferencehttp://ontologydesignpatterns.org/wiki/Community:Proliferation_of_URIs%2C_Managing_Coreference: How to avoid or manage two negative consequences to the current proliferation of new URIs being minted for the same things. Specifically: 1. it is hard to find when two things should be the same 2. even if you can find the links, prolific use of owl:sameAs will create computational problems. 3. Versioning and URIshttp://ontologydesignpatterns.org/wiki/Community:Versioning_and_URIs: When and whether to make new URIs for different versions of things. I added them to the Catalog of Modeling Issueshttp://ontologydesignpatterns.org/wiki/Community:Mainin the Ontology Design Pattern Wiki http://ontologydesignpatterns.org/wiki. Click on the links for more details. What is the Catalog of Modeling Issues?http://lists.w3.org/Archives/Public/public-lod/2010Apr/0214.htmlhttp://lists.w3.org/Archives/Public/public-lod/2010Apr/0214.html Below is a bit of background on the history of this discussion. Michael PS The individuals in the CC: of this email were directly involved in the original discussions. *Background:* In May 2008, I kicked off a discussion with the subject A Semantic Elephant describing the unnecessary and costly proliferation of URIs and owl:sameAs links. This discussion evolved to be mostly about managing co-reference. Intitially private, this discussion was moved to the W3C Semantic Web Discussion Listhttp://lists.w3.org/Archives/Public/semantic-web/at Tim Berners-Lee's request. See: Managing Co-reference (Was: A Semantic Elephant?)http://lists.w3.org/Archives/Public/semantic-web/2008May/0081.html. The original discussion also evolved into a discussion about owl:sameAs per se, which has been a recurring topic on various lists over the years. Aldo Gangemi provided a concise summary on May 16, 2008http://lists.w3.org/Archives/Public/semantic-web/2008May/0126.html. In October 2008, I started a closely related discussion focused more on challenges with Versioning and URIs. It was under the subject: URIs and Unique IDshttp://lists.w3.org/Archives/Public/semantic-web/2008Oct/0192.html. From all this, I teased out the three distinct but closely related modeling isssues listed above. For each I created a detailed summary of the issues and topics that were discussed Michael
Re: [foaf-protocols] replacing email with atom and foaf+ssl
On 3 May 2010, at 21:22, Nathan wrote: Story Henry wrote: [snip 2. The Solution --- 2.1 RESTful Identity and Authentication --- foaf+ssl gives us WebIds, global identifiers tied to a public key, which allows one click authentication. This works in all browsers. There is more here: http://esw.w3.org/Foaf%2Bssl/FAQ You can try some early demos out by going to http://webid.myxwiki.org/ for example or any of the list of Identity Providers http://esw.w3.org/Foaf%2Bssl/IDP Without foaf+ssl this is not really possible. Getting a username/password for each of one's friends web servers would be impossibly complex, tedious and insecure. OpenId is close, but still too complex, though it can also be made to work nicely with foaf+ssl. 2.2 A ping mechanism It just requires one new relation to be added to a foaf file. A link to a simple form, which could be a atompub:Collection / sioc:Container [1]. I went into this in great detail in a recent post where I cover what I know of the pinging mechanism history, and show how this can be simplified further. http://markmail.org/message/kzsg3qntovmqzbje Writing such a pinging mechansim is really really easy. Adding a relation to a foaf is also easy, as we can see from the recent adoption by Facebook, which is rdfa enabling all its web pages. [snip] Henry, Good call, I've been thinking about this a lot recently and there is certainly a huge amount of scope. Things I'm certain of: - FOAF+SSL is needed - HTTP should be the interface - all communications should be handled RESTfully - Resources should be Web Access Controlled (via ACL+WebID) - The receive flow should be: notification of new message, GET message Thing(s) I'm unsure of: - Atom(/Pub) vs LinkedData I am not sure the 'vs' is justfied. Atom is a format, which can be GRDDLed into RDF. See the Atom/OWL work for example: http://bblfish.net/work/atom-owl/2006-06-06/AtomOwl.html Full application of REST leads one inevitably to linked data. RDF provides the semantics for that. (important note, that is still worth repeating: RDF is not a format! proof: the RDFa html markup in the latest Facebook for example http://rdfa.info/2010/04/22/facebook-adopts-rdfa/ ) Linked Data can represent anything we want, surely to use linked data rather than Atom would allow the scope of this to be so much more, allowing any kind of message to be sent. See above. But atom is widely used, widely understood. There is no reason atom cannot join foaf+ssl, so why not work together? Together we can go much further. Sioc:Container and Items together with the additional sioc type extensions would appear to cover 99% of scenarios. Yes, with Atom/Owl they just provide a semantics for Atom xml. The thing is that a lot of blogging clients understand Atom publication protocol. It would be very easy for them to add foaf+ssl support - that would just require at the minimum adding ssl support! Considerations of SPARUL, SPARQL and SPARQL+Pubsubhubbub for custom notification streams. Those are nice. But why use them when they are not needed? They will be useful at some point. Let us use them, where and when they are needed. The time will certainly come for them. But this application does not require them, and it could be really big. But I see you agree with me below... :-) However, Atom(/Pub) is already here, defined, widely accepted and would allow a quick implementation without too much work, and you could ensure that each message could be handled due to having set parameters in Atom (whereas in linked data it could be any ontology with no guaranteed presence of rdfs:label or suchlike) Further, Atom(/Pub) would add in much scope for current work on the likes of activitystrea.ms to be incorporated / made interoperable etc. (and possibly OData/GData..?) Yes. Possibly. I have not followed those that closely, so I can't comment on them. The great thing is that it ties atom very lightly into a global social network, which means that it will be all the more powerful as a result. Side: By defining a standardized HTTP RESTful messaging system with FOAF+SSL and Web Access Control you remove all implementation specific details and make something forwards and backwards compatible, so vendors could easily adopt this whilst remaining in control of backwards compatibility points (routing messages to email, xmpp, sms etc - preferences for notifications of messages from certain sources - prioritization of message deliver messages based on rules). yes. It would be very nicely backward compatible. A very minor tweak, with a huge upside. At the same time it would simplify many types of communication from service to service and encourage adoption of webid's, foaf+ssl. And of Atom itself. :-) All in all: Sounds feasible and pretty much fully spec'd if
Re: [foaf-protocols] replacing email with atom and foaf+ssl
Story Henry wrote: On 3 May 2010, at 21:22, Nathan wrote: Story Henry wrote: [snip 2. The Solution --- 2.1 RESTful Identity and Authentication --- foaf+ssl gives us WebIds, global identifiers tied to a public key, which allows one click authentication. This works in all browsers. There is more here: http://esw.w3.org/Foaf%2Bssl/FAQ You can try some early demos out by going to http://webid.myxwiki.org/ for example or any of the list of Identity Providers http://esw.w3.org/Foaf%2Bssl/IDP Without foaf+ssl this is not really possible. Getting a username/password for each of one's friends web servers would be impossibly complex, tedious and insecure. OpenId is close, but still too complex, though it can also be made to work nicely with foaf+ssl. 2.2 A ping mechanism It just requires one new relation to be added to a foaf file. A link to a simple form, which could be a atompub:Collection / sioc:Container [1]. I went into this in great detail in a recent post where I cover what I know of the pinging mechanism history, and show how this can be simplified further. http://markmail.org/message/kzsg3qntovmqzbje Writing such a pinging mechansim is really really easy. Adding a relation to a foaf is also easy, as we can see from the recent adoption by Facebook, which is rdfa enabling all its web pages. [snip] Henry, Good call, I've been thinking about this a lot recently and there is certainly a huge amount of scope. Things I'm certain of: - FOAF+SSL is needed - HTTP should be the interface - all communications should be handled RESTfully - Resources should be Web Access Controlled (via ACL+WebID) - The receive flow should be: notification of new message, GET message Thing(s) I'm unsure of: - Atom(/Pub) vs LinkedData I am not sure the 'vs' is justfied. Atom is a format, which can be GRDDLed into RDF. See the Atom/OWL work for example: Agreed, more a short bit of focus or clarification on inserting additional meta/linked data in to Atom, but this is an aside.. main question below: The great thing is that it ties atom very lightly into a global social network, which means that it will be all the more powerful as a result. Side: By defining a standardized HTTP RESTful messaging system with FOAF+SSL and Web Access Control you remove all implementation specific details and make something forwards and backwards compatible, so vendors could easily adopt this whilst remaining in control of backwards compatibility points (routing messages to email, xmpp, sms etc - preferences for notifications of messages from certain sources - prioritization of message deliver messages based on rules). yes. It would be very nicely backward compatible. A very minor tweak, with a huge upside. At the same time it would simplify many types of communication from service to service and encourage adoption of webid's, foaf+ssl. And of Atom itself. :-) All in all: Sounds feasible and pretty much fully spec'd if going down the atompub route, perhaps linked data + sparql/sparul/pubsubhubbub is the long term route but I'm quite sure it would take a bit more work to both implement and encourage adoption. Brining the REST and Linked Data communities together is critical though, and can only be a good thing for the future of the web. Thanks for bringing this to the table Henry, Thanks for the feedback, and helping me clarify. My primary question - in order to get on and start prototyping - is what to use as the property to link a webid to the atompub container(s). on second thoughts, I'd like to negate the container(s) above with preference going to a single notification stream per webid / persona which they can subscribe to from a variety of clients and devices. fully agree though, this is something that can be adopted very quickly and will have huge benefits. the costs of adopting are negligible compared to the benefits. any other details needing covered? Best, Nathan
Re: [foaf-protocols] replacing email with atom and foaf+ssl
On 3 May 2010, at 22:02, Nathan wrote: All in all: Sounds feasible and pretty much fully spec'd if going down the atompub route, perhaps linked data + sparql/sparul/pubsubhubbub is the long term route but I'm quite sure it would take a bit more work to both implement and encourage adoption. Brining the REST and Linked Data communities together is critical though, and can only be a good thing for the future of the web. Thanks for bringing this to the table Henry, Thanks for the feedback, and helping me clarify. My primary question - in order to get on and start prototyping - is what to use as the property to link a webid to the atompub container(s). Not sure you need this to start prototyping, though it would certainly be a useful relation. All you need is a link in the foaf to a ping endpoint. And I think we are just waiting for Sebastian Dietzold to publish that. What the publisher needs to do is ping the agents he is sending the 'mail'/entry to. He knows their WebId. All he needs to do is look there to find the ping endpoint, and send a ping. We may need something a little more advanced than ping, but not much. Does that help? on second thoughts, I'd like to negate the container(s) above with preference going to a single notification stream per webid / persona which they can subscribe to from a variety of clients and devices. fully agree though, this is something that can be adopted very quickly and will have huge benefits. the costs of adopting are negligible compared to the benefits. any other details needing covered? Best,
