Re: "Microsoft Access" for RDF?

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

Received on Monday, 23 February 2015 09:35:21 UTC