solid-spec
solid-spec copied to clipboard
move to schema.org?
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 throughfoaf: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 )
- link person to a person with
- 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 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.
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.
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.
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