On 6/6/11 12:27 PM, Martin Hepp wrote:
Hi Kingsley,
thanks - but two important points:
1. GoodRelations is not really in danger, because Google and Yahoo will
continue their support.
It's never in danger since it isn't about syntax :-)
I am not afraid GR might go away for the sake of schema.org.
I don't think you are, or should be afraid of anything bar overloaded
requests exploitation of GR.
2. What is a problems is their unclear message re mixing schema.org elements with RDFa -
some have read this as "if you want to be in our index, don't use RDFa at all",
and this is a REAL problem, because people would have to choose between pleasing G+Y+B or
providing more data for other services.
Yes, but this is them expressing their world view. Even if its a
politically driven modulo "RDFa" message, it ultimately doesn't matter
since it doesn't stop Linked Data injection into the current Web.
I personally think this can be solved by convincing them to polish the wording
so that it is clear you should not use two techniques for the SAME properties
on one page.
I think its is solved by them realizing that the nobody can control the
Web since the train left the station a long time ago. Once hypertext
became network enabled the game changed forever. Of course, most don't
want to believe this reality, so best we let them figure that out in
their own time.
The problem is the naïveté of SEO / Web dev audiences who, in doubt, will dump
SIOC + FOAF + DC in lieu of three properties from schema.org.
Such would be a net loss of structured data.
No, a net gain, and a net loss for those to take people down cul-de-sacs.
BTW - we are yet to publish our own hands on exercise re. RDFa and
Microdata based on GR and in from our findings we understand where
Google and friends are coming from re. simplest route to Linked Data
with SEO in mind. Basically, we found Microdata to be the option that's
going to be most palatable to your typical Web Master. Remember, EAV
triples is much more broadly understood than RDF triples. Adding
de-referencable URIs to the triples mix still doesn't require RDF as
sole vehicle. In short, RDF still doesn't say anything about
de-referencable URIs which simply adds to its confusion quotient re.
Linked Data, too many developers (Web and non Web).
I'll have the schema.org and schema.rdfs.org all mapped out soon. Did it
last time Google dipped their toes into the Linked Data waters, will
just update that work etc..
Kingsley
Martin
On Jun 6, 2011, at 1:11 PM, Kingsley Idehen wrote:
On 6/6/11 11:30 AM, Martin Hepp wrote:
As the three major seach
engines agree on it, it will become a de-facto standard regardless to
wether we like it or not.
Hi,
do not understand why you all hop on schema.org.
It is absolutely unclear whether schema.org will make it, for the simple
reasons that:
1. The schema.org syntax for products is basically the same as the Google
Microdata syntax proposed in November 2011. Of all three options
(hProduct/hListing, GoodRelations in RDFa, Microdata), this was, afaik, the
least popular.
Now, with Google having a market-share of> 80 % in most countries, if people
do not add this to their pages when Google recommends it, why should Yahoo and
Bing joining make a difference? Most sites are optimized for Google when in doubt.
2. On the very same page on which Bing is announcing their rich snippets
support, they state that they will add GoodRelations in RDFa to the crawler.
3. The main bottleneck for the a bit slow adoption of rich meta-data for sites
is
- the ridiculously slow process of whitelisting your site for rich snippets (it
can take months for your page to show actual rich snippets) and
- the fact that they are only unofficially accepting RDFa in snippet-style [1,
2], which makes authoring RDFa patterns and developing shop extensions a lot
easier, because it separates the organization of visible content from the data
structures.
Note: Not every move by the three giants will be a success. I guess that only
50 % of e-commerce sites support e.g. sitemaps.org. Google Wave was also a big
hype but is now dead, and the list of other failures is long.
I really don't get why you are not fighting for an open Web. Schema.org will
not reduce the entrance barriers to rich markup significantly.
RDFa, in particular in 1.1 flavor, is a great, extensible technique, with
tooling etc.
Message is really simple: Bravo to any structured data contribution :-)
Fighting over syntax will ultimately be proven to be a total waste of time re.
Linked Data Structures at InterWeb scales.
Boolean "AND" always trumps "OR".
Google, Yahoo!, and Bing! have actually delivered some good visibility and
credibility for the whole Web as a Global Data Space vision.
As you know, nothing about GR relations graphs are constructable using a
variety of syntaxes. You have a model first and syntaxes for expressing data
for that model, not the other way around :-)
Kingsley
Best
Martin
[1] Hepp, Martin; García, Roberto; Radinger, Andreas: RDF2RDFa: Turning RDF
into Snippets for Copy-and-Paste, Technical Report TR-2009-01, 2009, PDF at
http://www.heppnetz.de/files/RDF2RDFa-TR.pdf
[2] http://www.ebusiness-unibw.org/wiki/RDFaAuthoring#RDFa_in_Snippet_Style
On Jun 6, 2011, at 10:59 AM, Thomas Bandholtz wrote:
For me, schema.org is just another schema. As the three major seach
engines agree on it, it will become a de-facto standard regardless to
wether we like it or not.
Obviously, they decided not to re-use anything as they are sure enough
they will be re-used instead.
What you bring up is called polymorphy in the OO world: Any instance may
be instance of multiple classes. I have a case where the domain experts
are talking about a thesaurus, so everthing is a skos:Concept.
But they have also place names and events.
So far, each place name is label of a skos:Concept. But we also have the
more specific Geonames Ontology, so the place name is as well
gn:officialName which implies that the same instance now has also type
gn:Feature (which is subclass of wgs84:SpatialThing, so the instance is
as well a wgs84:SpatialThing).
Now we have one more player in the open schema world:
the same instance will now become a schema:Place instance as well.
So what?
As far as these schemas are not inconsistent with one another, there is
absolutely no problem. If there are some contradictions, the reasoner
will hopefully detect them and give us a chance to align the schemas
with a good reason.
What is the "purpose" of such multiple class assignment?
Any agent searching the LOD cloud for skos:Concept instances will find
my instance, and the same applies to those agents searching for
gn:Feature or schema:Place instances.
If your instance is not found, you may as well delete it ;-)
I used to dream about schema alignment and re-use for decades, but I
have come to the conclusion: schema diversity is just like
bio-diversity. We do not have to overcome it, it is a protected asset!
Best regards,
Thomas
Am 05.06.2011 13:28, schrieb Hugh Glaser:
Interesting question.
As an an engineer, I was trying to work out if the schema was fit for purpose.
Of course, I was assuming that we agreed on what the purpose was, but that was
a mistake, as it usually is.
I thought that the purpose was that I would have a schema I could then use in
my RDF, that would have a simple correspondence with schemas.org (so I stood a
chance of moving between them), while enabling me to do my Linked Data goodness
(importantly conforming to the first principle).
In particular, I did not think that we were trying to capture the exact meaning
of what they (Schema.org) say.
So my fit for purpose would have (at least):
1) Will the resultant RDF be useable as Linked Data?
2) Can I move between the two notations without loss of (important) information?
The following from Schema.org seems very relevant in the second of these
"Conformance
While we would like all the markup we get to follow the schema, in practice, we expect a lot
of data that does not. We expect schema.org properties to be used with new types. We also
expect that often, where we expect a property value of type Person, Place, Organization or
some other subClassOf Thing, we will get a text string. In the spirit of "some data is
better than none", we will accept this markup and do the best we can."
So what can the RDFS respond to this, with particular reference to (my) purpose
(2)?
As always we must ask what is the role of the schema.
It clearly can't be to police an acceptance of valid RDF documents that have
come from Schema.org - it would reject many things that will become acceptable
to Schema.org.
It clearly can't be to police the publication of RDF documents on their way to
Schema.org - it would restrict too much.
It may be useful to provide inference in a RDF store with schema.rdfs.org RDF
in it.
Essentially, it means not only dropping all the range restrictions, but even
the domains as well, if it is to be fit for (my) purpose (2).
But it then becomes less useful for (my) purpose (1).
Indicating useful restrictions is a good thing to do, to help me get my RDF
right, and help me work out what is in a schema.rdfs.org RDF store, and even
give me more useful inference in the store.
It is just that such use directly conflicts with being useful as a bridge with
Schemas.org.
How to square the circle?
To be useful for the future development of Schemas.org, the more I look the
more I think just dropping all domain and range is the only way forward (does
that go too far for you, Pat? :-) )
However, the schema.rdfs.org does tell me a lot of useful stuff with the
restrictions - is it really the case that more than one description is useful?
That would be horrible or would it?
I suspect that I may need to don a flameproof suit here, as I tread into well
worn paths of knowledge acquisition, but never mind, it's Sunday morning and
raining outside :-)
Best
Hugh
On 5 Jun 2011, at 07:37, Thomas Bandholtz wrote:
Am 04.06.2011 17:35, schrieb Pat Hayes:
Far as I can see, one could simply delete every range-string triple. Nothing
would break in the RDFS by doing this, and AFIKS nothing is gained from having
these range assertions.
Deleting every range assertion would not express what they want to say:
"many properties have 'expected types'. This means that the value of the
property can itself be an embedded item ... But this is not a
requirement—it's fine to include just regular
text or a URL." [1]
They do not expect just anything, but a certain type or a literal
(denoting an "informal" instance of this type).
Sounds like
schema:someProperty rdfs:range [ owl:unionOf (schema:Thing rdfs:Literal ) ];
What funny kind of OWL flavor or profile might this be?
Note that they do not use owl:ObjectProperty nor owl:DatatypeProperty
but simply rdf:Property, so it might be just fine. Good old RDFS!
Some comments from the OWL police?
Thomas
[1] http://schema.org/docs/gs.html#schemaorg_expected
Pat
On Jun 4, 2011, at 4:39 AM, Hugh Glaser wrote:
Sure does rock.
As you know, I never venture into ontology definition, to avoid displaying my
ignorance, but now and then... :-)
Suggestion:
The RDFS will (I think!) perpetuate the classic problem (being a natural
translation), in that there are lots of range strings.
For example:
schema:currenciesAccepted a rdf:Property;
rdfs:label "Currencies Accepted"@en;
rdfs:comment "The currency accepted (in ISO 4217 currency format)."@en;
rdfs:domain schema:LocalBusiness;
rdfs:range xsd:string;
rdfs:isDefinedBy<http://schema.org/currenciesAccepted>;
.
and
schema:headline a rdf:Property;
rdfs:label "Headline"@en;
rdfs:comment "Headline of the article"@en;
rdfs:domain schema:CreativeWork;
rdfs:range xsd:string;
rdfs:isDefinedBy<http://schema.org/headline>;
.
And even productID
I count 53 "rdfs:range xsd:string" and 8 "rdfs:range [ owl:unionOf (xsd:decimal
xsd:string) ]" of this kind.
As I say, I think that means that to conform, I can't have a Resource as Range.
So it is institutionalising a Bad Thing, simply because schema.org says that, for example,
"productID" is "text".
Of course, people who use http://schema.rdfs.org/ probably will use Resources
for places, currencies, etc, (as they should) so maybe the RDFS needs to
reflect this?
Won't try and suggest...
Best
Hugh
On 3 Jun 2011, at 22:06, Michael Hausenblas wrote:
http://schema.rdfs.org
... is now available - we're sorry for the delay ;)
Cheers,
Michael
--
Dr. Michael Hausenblas, Research Fellow
LiDRC - Linked Data Research Centre
DERI - Digital Enterprise Research Institute
NUIG - National University of Ireland, Galway
Ireland, Europe
Tel. +353 91 495730
http://linkeddata.deri.ie/
http://sw-app.org/about.html
--
Hugh Glaser,
Intelligence, Agents, Multimedia
School of Electronics and Computer Science,
University of Southampton,
Southampton SO17 1BJ
Work: +44 23 8059 3670, Fax: +44 23 8059 3045
Mobile: +44 75 9533 4155 , Home: +44 23 8061 5652
http://www.ecs.soton.ac.uk/~hg/
------------------------------------------------------------
IHMC (850)434 8903 or (650)494 3973
40 South Alcaniz St. (850)202 4416 office
Pensacola (850)202 4440 fax
FL 32502 (850)291 0667 mobile
phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
--
Thomas Bandholtz
Principal Consultant
innoQ Deutschland GmbH
Halskestr. 17
D-40880 Ratingen, Germany
Mail: thomas.bandho...@innoq.com
Mobile: +49 178 4049387
Phone: +49 228 9288490
Fax: +49 228 9288491
http://www.innoq.com/de/themen/linked-data
--
Thomas Bandholtz
Principal Consultant
innoQ Deutschland GmbH
Halskestr. 17
D-40880 Ratingen, Germany
Mail: thomas.bandho...@innoq.com
Mobile: +49 178 4049387
Phone: +49 228 9288490
Fax: +49 228 9288491
http://www.innoq.com/de/themen/linked-data
--
Regards,
Kingsley Idehen
President& CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen
--
Regards,
Kingsley Idehen
President& CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen
