W3C home > Mailing lists > Public > public-socialweb@w3.org > May 2015

first user story for SoLiD & schema + v-card feedback

From: <henry.story@bblfish.net>
Date: Sun, 3 May 2015 10:57:58 +0200
Message-Id: <33051378-28CE-414C-8891-F04EFFB0649D@bblfish.net>
To: Social Web Working Group <public-socialweb@w3.org>
Yesterday I put together a description of how the first user story would work with SoLiD:


To do this I had to look at how to fill in some missing relations that were not in the foaf ontology, which I have been using until now because it is a nice example of a grass roots ontology with warts and all - lots of mistakes, but done in the pioneer spirit.

Still some relations were missing so I turned to two ontologies

 (1) Vcard: http://www.w3.org/TR/vcard-rdf/
 (2) schema.org

Luckily Elf who has studied these was here to discuss them with me. 

He helped me understand some weirdnesses of vcard : namely what seems to be the pattern adopted by AS2.0 of having relation have as range the union of the exclusive set of objects and relations. This is what  they call the  property relation machanism: the direct and n-ary example.  I am not  completely convinced by this yet, but I can't see that it does not make sense. ( If we do maintain this way and fail to find a better way to model this, then AS2.0 should also document this in more detail )

 Otherwise vcard has all the benefits of working with an old widely used pre-web  standard, and all the problems of an old slowly developed model that is  more syntactically based  on a business card from pre web days, than on modelling people and things. Eg. it does not make a simple distinction the contact ontology makes  which is that a place can have more than one address. (Eg, where I am living  here is a small appartment in Paris, but there are two  addresses for it). It also puts the main job of a person in the center, as if people could not have more than one job.

  Schema.org on the other hand superficially looks really attractive. It has all the relations one would hope for. But then on closer consideration one sees that it would be unuseable for SoLiD as is. 

  Schema.org is trying to help people mark up info on their web pages with the motivation that they can get better results in search engines. For those search engines, any structured info here can help. They can also have all the caches of the web at their disposal, so doing quick lookups through their caches can be done, and at the level at which they look at things statistical reasoning is good enough, given all the data they have, and the quality of answers expected from them.

  But as SoLiD developers we have to end up building applications that have the same quality UIs as well known social networks. These publish very well structure data in JSON, and have JavaScript use this data. We publish our data in Json-LD and also hava JS read the data. The difference is that we need to follow links across web sites. For this to work we need to set standards of quality so that at least when things go wrong, developers can understand what went wrong, make patch requests etc, and also so that our UI scripts can be efficient. We need to run things in small devices and we don't want to have each user crawl the web to do some statistical reasoning to work out what the meaning of a term is. 
  In short: we need the solid modelling that JSon people are used to and also the linkability provided by RDF. 

  So when one looks at the example of schema:Person and translates it to RDF one is pretty schocked to see:

[]  a :Person;
    :address  [
                 a :PostalAddress;
                 :addressLocality "Seattle";
                 :addressRegion "WA";
                 :postalCode "98052";
                 :streetAddress "20341 Whitworth Institute 405 N. Whitworth"    
     :colleague "http://www.xyz.edu/students/alicejones.html",
     :email "mailto:jane-doe@xyz.edu";
     :image <http://json-ld.org/playground/janedoe.jpg>;
     :jobTitle "Professor";
     :name "Jane Doe";
     :telephone "(425) 123-4567";
     :url <http://www.janedoe.com> . 

So the postal address if fine, but the colleague as a link to a string representing a document is a complete no go for SoLiD. This means that SoLiD applications would need to guess now if a string was meant as a URL. How would that function for relative URLs? Would one have to try to dereference each name as a relative URL first before then trying to display it?

Also having relations point to documents that are "people" is of course for the search engines better than not having any information, but it is not something that we can find very helpful in SoLiD. We would like to be able
to jump from one record on one site to another on another site, and point at the right record immediately so that we can continue from there. Otherwise we have to do a lot of guessing, different software will guess differently and there will be no consistency between apps. We can guess from time to time, but doing it all the time is not going to make for good applications.
This is similar to developers working with JSON: time is of the essence, and good structure is very important.

So the question will be: how do you expect people to write such good Linked Data? Well we don't! We expect apps to write linked data using LDP, and we expect people to select apps based on how well they work how intuitive they are etc. We expect the Social Linked Data web to grow so that the apps that are close to the standards work well. And for that we need to be clear on standards, and not be wishy washy at every step. Because if you create a wishy washy standard, then in any case there will always be a wishy washy way to implement the wishy washy standard, so that you'll have the same problem but now in the confusing wishy washy space where you won't even be able to argue clearly.

This is a major reason why hash urls are very important to us.
( sorry for not having explained it earlier )


Social Web Architect
Received on Sunday, 3 May 2015 08:58:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:26:17 UTC