That’d be great! I’ve actually been working for a while in a
dev branch adding new features, and finding ontologies is still one of the main pain points. I’ll add descriptions (already implemented) and due dates to the next version, and I wouldn’t mind changing the ontologies because there won’t be a 1.0 stable version yet.
You can check out the ontologies I’m using at the moment here: https://github.com/NoelDeMartin/solid-focus/blob/dev/docs/README.md#data-schema
Great, I’m checking them out now!
It’s strange for me to use foaf:name for a Task or a List… I thought it was reserved for a Person, a friend of a friend.
@NoelDeMartin It won’t be a problem at all for us to have our ontologist put something together for this app. It will be a few weeks though because he is a contractor and we are currently waiting for the budget stuff to finalize. As soon as he’s back on the job I’ll let you know and we can continue from there!
Yes I agree it’s very strange, but quite frankly I know almost nothing about how to use proper ontologies and property names :/. I’m of course open to suggestions thou :D.
For example, it was hard enough finding an ontology that had something like “tasks”, so I ended up with these two: http://vocab.org/lifecycle/schema and https://www.w3.org/ns/prov but I didn’t find anything on how they name the tasks/activities so I just assumed foaf:name was ok because I’ve seen it used in many examples (yes, they were probably only examples about persons).
The only ontology I’ve found that makes sense to me is schema.org, but it didn’t have anything about tasks. I hope that I’ll be able to fix this with the help of the community :D. I was focusing on implementing the code first, but for sure before having a stable version of the app I’ll try to have this sorted out.
I’m working on an app that also uses tasks, so I’ve been trying to work out how to make it interoperable with Focus.
It seems what is needed is:
- look up the Pod to store data in using pim:storage, because it might be somewhere other than the profile doc, e.g. for performance or bandwidth reasons
- look up the container to store tasks in using type registration. If there is no container specified, then suggest a default and let user override it
If my app then does the same, then we’ll both be able to find the tasks wherever they are.
I pieced this together from:
Corrections are welcome.
However, it’s not clear that the type registry is a final solution for interoperability between apps. I’m not sure how it fits with: Blog post: Shaping Linked Data apps
Yeah, basically what I do for reading/creating tasks is read the containers indicated by
pim:storage and I create a “Workspace” to store the tasks inside. This workspace is basically an
ldp:Container with the
lifecycle:TaskGroup type. You can see the schema of the data here, but it’s possible that it’ll change given that I’ve had some issues defining the types as you can see in the last comments on this thread.
I’ve just released a new version with some updates:
- Improved UX.
- Implemented the ability to edit and delete Workspaces, Lists and Tasks.
- Added Task scheduling and descriptions.
- Added markdown support for task names and descriptions.
- Added tasks sidepanel.
- Added soukai dependency to manage data persistence.
- Improved documentation (including a schema of the RDF ontologies that have been used).
- Refactored data schema.
@Smag0 I’ve updated the schema and I’m using
rdfs:label for task names, thanks for the heads up :).