solid-spec icon indicating copy to clipboard operation
solid-spec copied to clipboard

move to schema.org?

Open bblfish opened this issue 9 years ago • 4 comments

In issue #22 I suggest documenting ontologies we use. We should also consider if one existing ontology would help us solve a lot of our decisions. schema.org is much more complete than most others, and deals with the kinds of problems we would find useful. Dan Brickley, Google, MS and other search engines. The vocabularies are much more complete than foaf for example.

  • we have a schema:Person class that resembles the foaf:Person a lot but has many more relations. It can
    • link person to a person with schema:knows
    • link a person to an organisation schema:worksFor - this can't be done in foaf other than through foaf:workplaceHomePage, which points to a homepage not a person.
    • link a person or a contact point to a telephone number via schema:telephone ( as timbl's contact ontology does )
  • It has https://schema.org/Event for events.
  • ...

The schema.org ontology is designed to not allow much inferencing, and we don't use much anyway. It's a bit of a pitty for some useful inverse functional properties such as foaf:mbox that do allow us to make good cases about indirect identifiers. But we can then still use that one when needed, as well as foaf:blog, foaf:openid, etc...

In schema.org one needs to always specify the types of the objects, as the relations are not strong enough to allow one to infer the types from them.

I think one can also use them correctly with hash uris. One just has to note that schema.org only tells people to use the schema:url relation instead of the JSON-LD @id tag, which means that in effect people using this who don't understand http-range-14 are not saying anything false, just something vague. For example as I pointed out on the Social Web WG a normal user who only cares to be well placed on search results and not to write a distributed social web will write:

{
  "@context": {
     "schema": "https://schema.org/"
  },
  "schema:url": "http://bblfish.net/",
  "schema:knows":  { "schema:url": "http://www.w3.org/People/Berners-Lee/" }
}

But SoLiD apps could complement that by writing something much more precise and efficient for Linked Data crawlers

{
  "@context": {
     "schema": "https://schema.org/"
  },
  "@id": "http://bblfish.net/#me",
  "schema:knows":  { 
     "@id": "http://www.w3.org/People/Berners-Lee/card#i" 
   }
}

The first graph represents the following turtle:

[] schema:url <http://bblfish.net/>
   shema:knows [ schema:url <http://www.w3.org/People/Berners-Lee/> ] .

The second graph the following

<http://bblfish.net/#me> schema:knows <http://www.w3.org/People/Berners-Lee/card#i> .

Both graphs say something true. The first one just says the person whose "url" is "http://bblfish.net/" knows the person whose "url" is "http://www.w3.org/People/Berners-Lee/", which just a pretty vague relation which may mean something like the location of the document. The second graph is precise, and much more easily useable by a machine. ( a lot less searching and guessing for it to do). Any client must be able to switch to the vague one anyway, when for example a fragemnt link does not connect for some reason. When that happens, it might require user intervention to fix the link, or interpretation by the user, which weakens the result, and slows down the task of automation.

bblfish avatar May 06 '15 10:05 bblfish

@bblfish maybe we could discuss it during next Social IG: Vocabulary TF meeting? I see many similarities between schema.org and microformats.org and pattern you propose here could help with aligning with both.

elf-pavlik avatar May 31 '15 09:05 elf-pavlik

I think this is always going to be app dependent, whether that's on the server (a customized version of Solid lets say) or client side, and so no need to have specific expectations - "hardcoding". I would suggest that apps take some caution to do their own mapping (if not already part of the vocab) between some well-known/popular vocabs in order to handle the data as best as they can.

csarven avatar Dec 15 '15 22:12 csarven

The question is wether we can come to some agreement ourselves when building apps to use similar vocabularies. I think at least having a table somewhere of vocabs used, and intentions to move would be good.

bblfish avatar Dec 15 '15 23:12 bblfish

Some interesting thoughts: http://blog.sgo.to/2015/09/vocabulary-negotiation.html

Also materialized inference IMO could also work pretty well in many cases. If human will not read the data, even repeating different predicates with same value shouldn't consume to much of a bandwidth.

Last but not least I would happily see more attention on basic inference futures in http://rdfjs.org

elf-pavlik avatar Dec 15 '15 23:12 elf-pavlik