I agree with your assertion of D: that not all inscriptions are marks.
I disagree with E. A mark can most certainly be a letter or combination of
letters. Have you ever noticed the letter "P" on an American coin? It's a
mint mark representing Philadelphia. The "SC" characters on a Roman coin
I think that I agree To be clearer about the inheritance that we’re
discussing:
* A) All Marks are Symbolic Objects
* B) All Linguistic Objects are Symbolic Objects
* C) All Inscriptions are Linguistic Objects
* D) All Inscriptions are Marks
* E) No Marks which are not
All,
In this homework http://www.cidoc-crm.org/Issue/ID-426-pxxx-holds-or-supports
there is the question of whether holds or supports should be a super-property
of p56 bears feature, or whether it should be distinct.
The proposed scope note included:
This property is similar to P56 bears
Dear Robert,
Yes, that is a good question!
For a very long time, we had no feedback to this part f the CRM.
Be careful not to inherit things upstream. If a Mark is also a
Linguistic Object, then it is in particular an Inscription.
But a Mark needs not be an Inscriptions.
However, we must
Brixhe, C. 2012. Timbres amphoriques de Pamphylie. Alexandria.
or
Tzochev, C. 2016. Agora XXXVII. Amphora Stamps from Thasos. Princeton.
Daria Hookk
Senior Researcher of
the dept. of archaeology of
Eastern Europe and Siberia of
the State Hermitage Museum,
PhD, ICOMOS member
E-mail:
Dear all,
about signes or symbols.
I have good example but for the moment difficult to propose some book in
English. I continue to search.
http://www.kroraina.com/alan/olhovskij.html#4
With kind regards,
Daria Hookk
Senior Researcher of
the dept. of archaeology of
Eastern Europe and Siberia of
Dear all,
I’m happy with the changes (modulo one typo, below), but would propose also
that there should be clarification about the inclusion of “short texts” in a
class that does not inherit from Linguistic Object. It seems strange to me that
Mark would include “Made by RS in 1780”, when that
I agree:-)
On 1/17/2020 11:16 AM, Carlo Meghini at ISTI CNR wrote:
Works very well for me, I’d sharpen it a bit by replacing
"A class is associated with an open set of real life instances, known as the
extension of the class”.
by
“In any interpretation, or possible world, a class is
On 1/17/2020 2:29 PM, Athanasios Velios wrote:
Hello,
During the discussions at the Linked Conservation Data consortium a
question has come up:
I have a metal sculpture on the seafront which is battered by the sea
for decades. The production of the corrosion layer is a S17 Physical
Dear All,
There were questions about the level of abstraction of E37 Mark.
Therefore I rewrite, following the relevant discussions when this class
was defined. The argument was that it should directly link to the codes
that are used in museum documentation for (registered) marks.
*Old scope
Dear All,
As a general remark, proposing different semantics for avoiding punning
should never be done. It would put syntax over meaning, and that is the
hell of semantic incompatibility since the invention of databases, and
the reason why formal ontologies were invented. Multiple
Yes, if we have different URIs for each version of E5 Event, then this
will complicate matters during implementation in local systems. If one
wants to work out the difference in reasoning rules across the versions
then they would need to refer to the whole document not each individual
class.
So all is well that ends well except
current version button on front page. It is, I think, weird that it points
to 6.2.3. If by current version we mean the latest raw and unfinished
version, then it should be 6.2.7. If we mean the last official community
version (another potential meaning of
>
>
>
> > > I will point out that on the CRM site, there is also an entire
> > > architecture wherein each version has its own overall
> presentation:
> > > e.g.: http://www.cidoc-crm.org/Version/version-6.2.1
> >
> > I think this should be maintained but not used as URIs for
Dear all,
This very interesting conversation was up to now focusing on CRMbase.
But what about the extensions family ? Often pointing from one extension
to antoher ?
One major point for having machine actionable, consistent ontologies is
to have a mechanism to point to the versions of each
Hello,
During the discussions at the Linked Conservation Data consortium a
question has come up:
I have a metal sculpture on the seafront which is battered by the sea
for decades. The production of the corrosion layer is a S17 Physical
Genesis. In conservation documentation I would like to
My underlying assumption would be that the default thing served up would
be html, but you could reach the other representation consistently
through adding an appropriate ending or whatever would be most
suitable... but that people looking at the html should have a shiny red
button type clue
Hi Robert,
Yes it is really quite nice actually. A hidden gem as it were.
About why it doesn't exist past 6.2.2, it's a bit odd. I would have said it
is because it is only made for official release versions (like 6.2.1) but I
see that it has been made for other non official versions. Perhaps it
>
>
>
> Links would certainly be useful but the web server's content negotiation
> mechanism should be enough to deliver the right format to the client, is
> this what you mean?
>
>
My underlying assumption would be that the default thing served up would be
html, but you could reach the other
Hi George,
On 17.01.20 10:47, George Bruseker wrote:
> I will point out that on the CRM site, there is also an entire architecture
> wherein each version has its own overall presentation: e.g.:
> http://www.cidoc-crm.org/Version/version-6.2.1
Wow, that is a really useful format, I didn't know it
For the appearance/presentation of the whole ontology, it is an html
representation of the main document that we create. This seems fine.
Would it be useful to be able to provide links explicitly at the top of
this document to click over to encodings? This way somehow we can better
consolidate
Dear all,
It seems a very fruitful discussion. Can I add some other 'complications'
into it.
Starting from what Detlev proposes:
> > For formal specifications such as ontologies, there is a widely adopted
> pattern for change management which goes like this:
> >
> >
22 matches
Mail list logo
