Open
Description
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?
Metadata
Assignees
Labels
No labels
Activity
draggett commentedon Jun 3, 2020
@ 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 commentedon Jun 3, 2020
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 commentedon Jun 3, 2020
In regards to ISO8601 dates, the corresponding chunk would only be created when the chunk ID is dereferenced and doesn't already exist.
tidoust commentedon Jun 4, 2020
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:source
,object
, and iso6801 properties.rule
andiso6801
.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 withmonth
properties and that use 1-based integer come in the way?draggett commentedon Jun 4, 2020
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 commentedon Jun 15, 2020
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 @.