Re: "Microsoft Access" for RDF?

Perhaps something interesting here
https://github.com/jmvanel/semantic_forms




--
Jean-Claude Moissinac


2015-02-23 10:34 GMT+01:00 Stian Soiland-Reyes <
soiland-reyes@cs.manchester.ac.uk>:

> On 21 February 2015 at 20:38, Michael Brunnbauer <brunni@netestate.de>
> wrote:
>
> > I admit that what you sketch here is better than what I have sketched
> with
> > named graphs. But it seems to require a very sophisticated editor or a
> > very sophisticated user.
>
> Agreed that the editor needs to be more clever than three text fields
> with auto-complete. If a non-RDF user is to be making RDF, at a
> triple-level, then the editor must be guiding the user towards the
> basic Linked Data principles rather than be a glorified vim. :)
>
>
> > I was talking about an editor where the user can
> > add triples with arbitrary properties.
>
> .. and arbitrary properties/classes should include ones the user make
> up on the spot and relate it to existing properties/classes.
>
> Kingsley was talking about the sentences analogy, and I think we
> should keep this in mind. While you shouldn't normally write a whole
> book using your own terminology, it's very common to introduce at
> least SOME terminology that you specify or clarify for the scope of
> the text (e.g. the document, graph, dataset).
>
> It could be something as in a triple (a sentence), show something as
> simple as a little [+] button next to the property or class to
> specialize it and use this instead in that triple. (making it
> available for other triples)
>
> Perhaps Kingsley's approach have some mechanism for specializing or
> introducing new properties?
>
>
> > So I would prefer the solution with named graphs that can be implemented
> > easily. Yes, the additional information will be very vague without
> context
> > but it will at least be there.
>
>
> I wouldn't dismiss the named graphs-per-triple approach - although to
> me it sounds overkill (perhaps one named graph per transaction).
>
> However starting to encode relations between those named graphs to
> make them sequential (and thus encode some hidden semantic meaning) to
> me feels a bit like trickery - your user isn't really making RDF
> statements the way we commonly find it in Linked Data world - he's
> making some kind of custom graph-ordering-structure that is just
> represented in RDF.
>
> Using named graphs for provenance is however very much best practice -
> so if you just track the provenance of when triples were inserted and
> one of your views is to view the graph or statements about a subject
> in that order (present it as "Insertion order" or something), then you
> are good - you are not tricking the user anymore. You thus won't need
> to implement "Move up" buttons as you should not rewrite history. :)
>
> --
> Stian Soiland-Reyes, eScience Lab
> School of Computer Science
> The University of Manchester
> http://soiland-reyes.com/stian/work/
> http://orcid.org/0000-0001-9842-9718
>
>