I'm looking for an RDF schema for a Todo list, similar to what schema.org has for a lot of things. The options on schema.org seem incomplete for a TodoMVC implementation.
Any tips? #rdf #schemaorg #todomvc
@ylebre not sure, but there's a suggestion that maybe schema.org's Action might work https://github.com/schemaorg/schemaorg/issues/1818
and
@noeldemartin appears to use purl lifecycle in his #solid to-do app https://github.com/NoelDeMartin/solid-focus/tree/master/src/models/soukai https://vocab.org/lifecycle/schema
@dougholton @noeldemartin thanks for this!
schema:Action feels a bit odd to me. It kind of fits, but also seems to be written with a different use case in mind.
For interoperability, it makes sense to align with @noeldemartin.
For a tutorial, having a schema that is an odd fit would be confusing for anyone new to Linked Data.
I dislike the idea of having a custom schema, but it would be a lot clearer to start with. And end the tutorial with an interop step, replacing it with schema:Action?
@ylebre @dougholton If the tutorial is for beginners, I'd just choose a vocab and use the same one for everything. We used schema:Action for the Hello World examples simply because schema.org is the most popular ontology and has nice documentation. I'm using it for my app as well for the same reasons, but as I said it's not final.
By the way, check this out if you haven't seen it: https://www.w3.org/DesignIssues/BagOfChips.html
@ylebre @dougholton I'm aware that choosing a vocab is one of the biggest roadblocks for beginners, but recently I've started thinking that it's not as important as I thought. I think when in doubt, you should just choose one that "looks right", or make your own if it doesn't exist, and move on.
Eventually, we should have a way to make apps interoperable with different vocabs, otherwise it's not realistic to think that developers will just choose "the right vocab" every time.
@noeldemartin @dougholton My concern is this: getting something up and running with a custom schema or an ill-fitting one is easy.
Making a poor choice does not matter in the early stages, until interoperability becomes important. So the data would need a way forward, have some kind of upgrade path, to become interoperable at a later stage.
As long as there is a good way forward, the choice in the beginning won't matter as much.