Chunks syntax: "@" prefix in links and reserved chunk types

[tidoust]

Looking at Introduction to chunks and rules, I see that a @ prefix is envisioned for terms with special meanings.

The syntax allows links to be expressed as a compact form, meaning that:

dog kindof mammal

... is the same as

kindof {
  subject dog
  object mammal
}

This attaches special meanings to the subject and object properties. Shouldn't they be prefixed with @? In other words, shouldn't that rather be

kindof {
  @subject dog
  @object mammal
}

Same question with ISO 8601 date-time strings. The iso8601 chunk type seems to be automatically created. Shouldn't it be prefixed with @ so as not to override another iso8601 chunk type that people may want to create with their own meaning? What about individual properties of that chunk type?

[draggett]

@ is currently reserved for use within rules for terms that the rule engine needs to deal with specially. This is needed as the use of @ terms in goals and rules interferes with retrieving or storing chunks involving these terms. I therefore would prefer to avoid allowing the use of @ in other modules.

[draggett]

In regards to Links, the short form is just a syntactic abbreviation for the longer form, and subject and object are conventions that can be utilised by rulesets and graph algorithms.

[draggett]

In regards to ISO8601 dates, the corresponding chunk would only be created when the chunk ID is dereferenced and doesn't already exist.

[tidoust]

Perhaps I don't have the right mental model but the use of the @ prefix does not seem entirely consistent to me.

The description of the chunks syntax suggests that names prefixed with @ will have a specific meaning, and that I'm free to use any other name anyway I see fit. However, there are some unprefixed names that have meanings too:

• property names: source, object, and iso6801 properties.
• chunk types: rule and iso6801.

For instance, if I want to reason about chunks I created with a month property whose value is a 0-based integer (because why not), won't iso6801 chunks that I did not explicitly create with month properties and that use 1-based integer come in the way?

[draggett]

I introduce @ primarily for use within rule conditions and actions, but also for named contexts. There is a need to be able to distinguish properties that have special meaning from the properties that may occur in a chunk you want to match to. Precluding @ in chunks other than in rules in the rules module seemed like a general way of doing so.

Learning new skills often starts with a declarative representation that is later compiled into rules. We thus need a way to express rules using regular property names that are then mapped to the @ form when compiling to the rules module. The chunk type rule only takes on the specific meaning when used for chunks in the rules module. As a result, I think it makes sense to avoid having to use @rule for rule chunks in the rules module.

I would prefer to avoid @ names where practical. This isn't an interoperability barrier, as there is a clear means to map RDF URIs to chunk names when integrating with external information.

My suggestion is to draft the spec to include some conventions for names such as subject, object, iso8601, lang, dir, etc. and to document the question as to whether the spec should avoid all such conventions in favour of requiring the use of @names.

[draggett]

Another perspective is for someone who doesn't speak English well and uses her own language for names. She understands and accepts that terms starting with @ are reserved and they generally use terms from English.

That suggests, that indeed it would be better to use @subject and @object for mapping Links into Chunks. Another example is context chains for things that are true in given context, but not necessarily outside of that context. The same argument applies for using @context to name the context rather than a term without the initial @.