Pintoch added a comment.
Ok, I think I still don't understand it fully, but I trust you do and won't
stand in the way ^^
TASK DETAIL
https://phabricator.wikimedia.org/T266344
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Pintoch
Cc: Abbe98, Pin
Abbe98 added a comment.
> If it is in the document served by WikibaseManifest, then as a tool author
I have the same problem as currently: if I wanted to make sure that all of my
tool's configuration can be derived from the contents of the WikibaseManifest,
then whenever I need to introduce
Pintoch added a comment.
> For OpenRefine(and other tools) the benefit would be that RDF ontologies
can be extended very easily so that tools can define their own (namespaced)
properties.
Where would those namespaced properties be published?
- If it is in the document served by Wiki
Abbe98 added a comment.
> So, even if we are assuming that the WikibaseManifest extension serves its
information by following some particular ontology, the tool-specific
information will not be available there. That means we cannot make it possible
to just set up a Wikibase instance in OpenR
Pintoch added a comment.
Thanks for reviving this thread I had forgotten about ^^
I don't think I fully understand your vision here, because it's not clear to
me what problem we would solve by using an ontology in this case.
To me, the main problem is that the information OpenRefine
Abbe98 added a comment.
I'm interested in working on this across OpenRefine, the WikibaseManifest
extension and "TIB's" reconciliation service but I wonder if this work wouldn't
benefit from being migrated to a proper vocabulary for describing APIs and
knowledge graphs. Like Hydra and DCAT o
Aklapper added a project: Wikibase - Automated Configuration Detection
(WikibaseManifest).
Aklapper removed a subscriber: Wikibase - Automated Configuration Detection
(WikibaseManifest).
Restricted Application added a project: Wikidata.
TASK DETAIL
https://phabricator.wikimedia.org/T266344
EM
