Re: Terminology definitions ; motivating example

I have ideas about terminology, but as we are all well aware the terrain is confusing, so the following is not my definite take on things, but maybe food for thought.


OCCURRENCE/TOKEN/INSTANCE

I fear that I’m the one who brought up the term "occurrence" because I knew it from the Topic Maps world, but I’d like to retract it and replace it with "instance" for the following reasons:
- type/instance is a well known pair
- the RDF specification talks of instances in the reification vocabulary
- computerists have a pretty immediate grasp of what an instance is and that intuition fits well with what we intend to introduce: a thing that has all the properties of the type, but also some more (which however can not change its type identity), and that thing itself has no subtypes of its own.
Occurence has something going for it, namely that there’s also a verb, "occur", that may help understand its meaning. But it’s also long, hard to type, not very common, so not very usable.
Token is according to plato.stanford.edu rather to be used for physical representations of things (eg the rendering of a triple on a screen or a sheet of paper) and therefore not what we want.


UN/ASSERTED

We have
- asserted
- unasserted
and for both there can be many facets. However, the basic distinction is that asserted facts are considered true in the world we model, and unasserted facts aren’t and that is what counts in application.
For the asserted side of things we already have a range of terminology: "statement", "assertion" and "triple". We sometimes also speak of "facts", but the term is not used in the specs AFAIAA. We should try to not add more terminology on this side.
The unasserted thing can be a theory, some questionable content, an unproven claim, a refuted claim, an older version, or un-endorsed, or tentatively recorded for further consideration, it can even be an accepted fact or well-respected opinion that nonetheless we don’t want to have as an assertion in our data. It’s very hard to find a common name that covers all those aspects (which might explain the longevity of the rather awkward "unasserted assertion" moniker). 
All things considered
- "fact" and "claim" make a nice pair
- "fact" is not a totally new term (but still yet the fourth one)
- "claim" can mean many things (which is good, given the variety of meanings it has to cover).
but I’m not sure yet.


EXAMPLE

I don’t consider myself good with examples. I have that < :Alice :buys :Car > thing that I’ve used quite often and that I find pretty extensible and malleable. The other question is of course WHAT do we want to examplify. 

The basic annotation dimensions w.r.t. content are:
- administrative, like provenance
- qualifying, like timespan of validity
- compositional, which however is the domain of graphs

Then we have multiplicity:
- multiple instances of one type of statement

Then we have the issue of 
- syntax vs interpretation IFF we decide to go there
- referential opacity IFF we decide not to go there
(see my reply to Niklas from today for detail). In other words: we have to deal with this issue anyway, and we have to deal with it in the example to make sure the design we decide on is well understood.

Depending on how we decide to deal with syntax vs interpretation and how we define multiplicity and if we decide to cover all content dimensions we would also have to cover
- graphs (as sets of statements with the same identifier)

Then we have the issue of
- asserted and
- unasserted 
statements (i.e. facts and claims, for example).

TBC...

Thomas



> On 7. Jan 2024, at 17:10, Andy Seaborne <andy@apache.org> wrote:
> 
> In the strawname wiki page, we have some sections.
> 
> Two that we can start on before we get to the details of the strawman proposal are "Motivating example" and "Terminology".
> 
> To make progress, please suggest text definitions for terminology we are using.
> 
> The most important one at the moment is "occurrence" - it's not the only one e.g. "unasserted" It would be useful to collect definitions for terminology in any proposals: "claim", "named triple", "triple term" ...
> 
> For the "Motivating example", can we have proposals - we discussed having one example so let's collect some possibilities and see if the subgroup thinks they make the right points and then create one.
> 
>    Andy
> 
> On 05/01/2024 17:50, Ted Thibodeau Jr wrote:
> > On Jan 4, 2024, at 01:03 PM, Lassila, Ora <ora@amazon.com
> > <mailto:ora@amazon.com>> wrote:
> >>
> >> As we decided today in the WG call, we will use tomorrow’s Semantics
> >> Task Force meeting slot for a discussion of a “broad strokes”
> >> proposal. The general idea is to come up with a proposal that focuses
> >> the direction of our future work; once we agree on the overall
> >> direction (and this is where people can express what they can and
> >> cannot live with, etc.), we can then move on to hammering out the
> >> details and get closer to completion. Or at least in an “ideal world”
> >> this would be the case. ;-)
> >> Even if you are not a member of the Semantics Task Force but are
> >> willing to “roll up your sleeves and get to work”, please consider
> >> attending.
> 
> > Linked from the end of that, there's a wiki page started by
> > AndyS that captures other facets of what we discussed --
> >
> > https://github.com/w3c/rdf-star-wg/wiki/Triple%E2%80%90Edge-subgroup-proposals <https://github.com/w3c/rdf-star-wg/wiki/Triple%E2%80%90Edge-subgroup-proposals>
> >
> > Note that this wiki page's name (and URI) may change, and there
> > is (so far as I can tell) no way for me to permalink to it that
> 
> GH wikis keep rename indirections for awhile - I'm not sure how long for.
> 
> > will persist through such changes, and redirects are not automatic
> > if they're even possible in GitHub Wiki...
> >
> > Be seeing you,
> >
> > Ted
> 
>

Received on Thursday, 11 January 2024 14:09:58 UTC